高通android平台源码 (2011-03-28 10:56)

本文提供了一步式教程,指导如何从CodeAurora获取Android高通源码,包括克隆仓库、初始化和同步代码流程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


分类:  Android


https://www.codeaurora.org/gitweb/quic/la/

MSM/QSD Android Enablement Project

To clone a repository

git clone git://codeaurora.org/ + project path.

To clone the entire platform, install repo, and run:

repo init -u git://codeaurora.org/platform/manifest.git
repo sync
Code Aurora Forum

Search: 


ProjectDescriptionOwnerLast Change



















Android高通源码下载

  (2010-07-14 15:38:10)
标签: 

it

分类: Android

#!/bin/sh
########################################
# Create ~/Android_src directory
# Create ~/bin directory
########################################
 sudo ln -snf /bin/bash /bin/sh 
 if [ -z $(which curl ) ] ; then
    sudo apt-get -y --force-yes --reinstall install curl
 fi
 test -d ~/bin || mkdir ~/bin
 
 test -e ~/bin/repo || curl http://android.git.kernel.org/repo > ~/bin/repo
 test -x ~/bin/repo || chmod a+x ~/bin/repo
 
 test -d ~/Android_src || mkdir ~/Android_src
cd ~/Android_src

################################################################################

# repo init -u git://codeaurora.org/platform/manifest.git -b [branch] -m [manifest]

###############################################################################
~/bin/repo init -u git://codeaurora.org/platform/manifest.git -b carrot.cupcake -m M7201JSDCBALYA6380.xml

~/bin/repo sync



----- pid 3735 at 2025-03-10 07:31:20.568105135+0800 ----- Cmd line: com.qti.qcc Build fingerprint: 'Redmi/flame/flame:15/AQ3A.241213.002/OS2.0.1.0.VGUCNXM:user/release-keys' ABI: 'arm64' Build type: optimized Debug Store: 1,0,234197305:: suspend all histogram: Sum: 475us 99% C.I. 3us-114us Avg: 18.269us Max: 114us DALVIK THREADS (33): "main" prio=5 tid=1 Native | group="main" sCount=1 ucsCount=0 flags=1 obj=0x71f24e28 self=0xb400007687008380 | sysTid=3735 nice=4 cgrp=foreground sched=0/0 handle=0x78728e5d28 | state=S schedstat=( 307450004 369887764 709 ) utm=16 stm=14 core=4 HZ=100 | stack=0x7ff3066000-0x7ff3068000 stackSize=8188KB | held mutexes= native: #00 pc 00086530 /apex/com.android.runtime/lib64/bionic/libc.so (syscall+32) (BuildId: 2b99d298050dea54c059527099734757) native: #01 pc 00060ea4 /apex/com.android.runtime/lib64/bionic/libc.so (__futex_wait_custom_ex+164) (BuildId: 2b99d298050dea54c059527099734757) native: #02 pc 000719d0 /apex/com.android.runtime/lib64/bionic/libc.so (NonPI::MutexLockWithTimeout+592) (BuildId: 2b99d298050dea54c059527099734757) native: #03 pc 0005e1a8 /system_ext/lib64/libqccdme.so (ipth_ReadNode.cfi+44) (BuildId: 24be08bcb4ed0c0bbc801d0743a6019e) native: #04 pc 00011380 /system_ext/lib64/libqcc.so (Java_com_qualcomm_qti_innodme_DMEFacade_doMtreeGetNative.cfi+232) (BuildId: 3e09c58f2855164f938aa85d2e1c0be7) at com.qualcomm.qti.innodme.DMEFacade.doMtreeGetNative(Native method) at com.qualcomm.qti.innodme.DMEFacade.mtreeGetNative(DMEFacade.java:245) at com.qualcomm.qti.qdma.filedelivery.RequestAcceptPolicy.updateQDMAFileSession(RequestAcceptPolicy.java:1106) - locked <0x0e97cb75> (a java.lang.Class<com.qualcomm.qti.qdma.filedelivery.RequestAcceptPolicy>) at com.qualcomm.qti.qdma.filedelivery.RequestAcceptPolicy.updateQDMAFileSession(RequestAcceptPolicy.java:1041) - locked <0x0e97cb75> (a java.lang.Class<com.qualcomm.qti.qdma.filedelivery.RequestAcceptPolicy>) at com.qualcomm.qti.qdma.transfer.QDM
最新发布
03-27
<think>好的,用户想分析Android应用的崩溃日志,特别是涉及到libqcc和libc的线程状态以及原生方法调用堆栈的信息。首先,我需要回忆一下Android崩溃日志的基本结构和常见分析方法。根据用户提供的引用内容,特别是引用[1]和引用[2],Android 8.0之后使用crash_dump工具生成崩溃日志,而内核崩溃可以通过串口log或last_kmsg来获取信息。不过用户的问题是关于应用崩溃的,所以重点可能在native层的崩溃,比如C/C++代码或第三方库的问题。 首先,用户提到的libqcc和libc库。libc是标准的C库,常见于系统底层操作,而libqcc可能是某个第三方库或厂商自定义的库,比如高通相关的组件。需要确认这两个库在崩溃时的调用栈情况。 接下来,分析崩溃日志的步骤。通常,Android的崩溃日志会包含信号信息(如SIGSEGV、SIGABRT)、寄存器状态、堆栈跟踪等。对于native崩溃,需要使用ndk-stack工具或addr2line来将地址转换为可读的代码行。此外,需要符号表(so文件带调试符号的版本)来正确解析堆栈。 用户需要解析线程状态和原生方法调用堆栈,可能需要检查崩溃时的线程状态,比如哪个线程导致了崩溃,是否有死锁或其他并发问题。对于libc的错误,常见的原因包括内存访问错误(空指针、越界)、堆损坏等。而libqcc的问题可能需要查看该库的文档或源码,了解其可能引发的异常情况。 引用[2]中提到,如果是内核死机,会有kernel crash的栈信息,但用户的问题属于应用层崩溃,所以应关注应用本身的native代码或依赖的库。需要检查崩溃日志中的backtrace,确定崩溃发生在哪个函数,以及参数和寄存器的值,帮助定位问题。 此外,可能需要检查是否有内存泄漏、资源竞争等问题。对于多线程环境,需确认是否有正确的同步机制。如果崩溃发生在JNI调用中,还需要检查JNI代码是否正确处理了异常和内存管理。 总结分析步骤:1. 获取完整的崩溃日志;2. 使用工具解析堆栈;3. 定位到具体的库和代码行;4. 结合代码和日志信息分析原因;5. 检查内存和线程相关问题。同时,参考用户提供的引用,特别是关于crash_dump和last_kmsg的信息,但应用崩溃更多使用logcat和ndk-stack。</think>### Android崩溃日志分析步骤 #### 1. **识别关键线程状态** 在崩溃日志中查找`libqcc`和`libc`相关线程,重点关注以下字段: - **信号类型**:例如`SIGSEGV`(段错误)表明内存非法访问,`SIGABRT`表示主动终止[^1] - **寄存器值**:如`pc`(程序计数器)指向崩溃时的指令地址,`lr`(链接寄存器)保存返回地址 - **线程堆栈**:查看`backtrace`字段,定位崩溃调用链 示例日志片段: ``` signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) r0 00000000 r1 00000001 r2 00000000 r3 00000000 r4 00000000 r5 00000000 r6 00000000 r7 00000000 pc a1b2c3d4 /system/lib/libqcc.so (functionA+0x123) ``` #### 2. **解析原生堆栈** 使用`ndk-stack`工具解析地址: ```bash adb logcat | ndk-stack -sym /path/to/symbols ``` - 符号文件需匹配崩溃时的`.so`文件版本 - 解析后输出示例: ``` #00 pc 0001c3d4 /system/lib/libqcc.so (functionA+123) #01 pc 0000a1b2 /system/lib/libc.so (pthread_create+56) ``` #### 3. **分析libc相关崩溃** 常见libc错误模式: - **空指针解引用**:`pc`指向地址`0x0`附近 - **堆损坏**:`malloc`/`free`调用栈中出现异常 - **线程竞争**:`pthread`相关函数调用异常 #### 4. **定位libqcc问题** 针对高通组件库的特殊分析: - 检查是否涉及**传感器**、**蓝牙**或**电源管理**模块 - 验证JNI调用是否遵守规范(如未正确同步Java/Native内存) - 使用`addr2line`精确定位: ```bash aarch64-linux-android-addr2line -e libqcc.so a1b2c3d4 ``` #### 5. **多线程状态比对** 在日志中搜索`"name: Thread-"`字段,检查: - 是否存在**死锁**(多个线程持有互斥锁) - **资源竞争**(多个线程同时操作共享内存) - **线程优先级倒置**(高优先级线程等待低优先级线程) --- ###
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值