Android 平台调试

注意：使用 adb 和 setprop 参数一起调试 Android 的某些方面。请注意，在 Android 操作系统的 O 版本之前，属性名称的长度上限为 32 个字符。也就是说，要创建一个包含应用名称的 wrap 属性，您需要截断该名称以使其符合字符数限制。在 Android O 及更高版本中，此字符数上限值要大得多，应该不需要截断。

本页面介绍了与崩溃转储有关的基本信息（可以在 logcat 输出中找到）。 其他页面更详细地介绍了如何诊断原生代码崩溃问题，通过 dumpsys 了解系统服务状况，查看本机内存、网络和 RAM 使用情况，使用 AddressSanitizer 检测原生代码中的内存错误，评估性能问题（包括 systrace），以及使用 GNU 调试程序 (GDB) 和其他调试工具。

崩溃转储

当动态链接的可执行文件启动时，系统会注册多个信号处理程序，这些处理程序会在出现崩溃时将基本崩溃转储写入 logcat，并将更详细的“tombstone”文件写入 /data/tombstones/。 tombstone 是一个包含与崩溃进程相关的额外数据的文件。需要特别指出的是，它包含对以下内容进行的堆栈跟踪：崩溃进程中的所有线程（而不只是捕捉到信号的线程）、完整的内存映射，以及所有打开的文件描述符的列表。

在 Android 8.0 之前，崩溃由  debuggerd 和  debuggerd64 守护进程处理。在 Android O 和更高版本中， crash_dump32和  crash_dump64 是根据需要生成的。

崩溃转储程序仅在未连接任何其他内容时才可连接。这意味着，在使用 strace 或 gdb 等工具时，将无法进行崩溃转储。

输出示例（已去除时间戳和无关信息）：

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***Build fingerprint: 'Android/aosp_angler/angler:7.1.1/NYC/enh12211018:eng/test-keys'Revision: '0'ABI: 'arm'pid: 17946, tid: 17949, name: crasher  >>> crasher <<

输出的最后一行提供了完整 tombstone 在磁盘上的位置。

假设您有可用的未剥离二进制文件，则可以将堆栈粘贴到 development/scripts/stack 中，从而获取更详细的展开信息（包含行号信息）：

提示：为方便起见，如果您已运行 lunch，stack 将自动包含在您的 $PATH 中，因此您无需提供完整路径。

                  development/tools/stack    
输出示例（基于上述 logcat 输出）：
    
Reading native crash info from stdin03-02 23:53:49.477 17951 17951 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***03-02 23:53:49.477 17951 17951 F DEBUG   : Build fingerprint: 'Android/aosp_angler/angler:7.1.1/NYC/enh12211018:eng/test-keys'03-02 23:53:49.477 17951 17951 F DEBUG   : Revision: '0'03-02 23:53:49.477 17951 17951 F DEBUG   : ABI: 'arm'03-02 23:53:49.478 17951 17951 F DEBUG   : pid: 17946, tid: 17949, name: crasher  >>> crasher <<<03-02 23:53:49.478 17951 17951 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc03-02 23:53:49.478 17951 17951 F DEBUG   :     r0 0000000c  r1 00000000  r2 00000000  r3 0000000003-02 23:53:49.478 17951 17951 F DEBUG   :     r4 00000000  r5 0000000c  r6 eccdd920  r7 0000007803-02 23:53:49.478 17951 17951 F DEBUG   :     r8 0000461a  r9 ffc78c19  sl ab209441  fp fffff92403-02 23:53:49.478 17951 17951 F DEBUG   :     ip ed01b834  sp eccdd800  lr ecfa9a1f  pc ecfd693e  cpsr 600e003003-02 23:53:49.491 17951 17951 F DEBUG   :03-02 23:53:49.491 17951 17951 F DEBUG   : backtrace:03-02 23:53:49.492 17951 17951 F DEBUG   :     #00 pc 0004793e  /system/lib/libc.so (pthread_mutex_lock+1)03-02 23:53:49.492 17951 17951 F DEBUG   :     #01 pc 0001aa1b  /system/lib/libc.so (readdir+10)03-02 23:53:49.492 17951 17951 F DEBUG   :     #02 pc 00001b91  /system/xbin/crasher (readdir_null+20)03-02 23:53:49.492 17951 17951 F DEBUG   :     #03 pc 0000184b  /system/xbin/crasher (do_action+978)03-02 23:53:49.492 17951 17951 F DEBUG   :     #04 pc 00001459  /system/xbin/crasher (thread_callback+24)03-02 23:53:49.492 17951 17951 F DEBUG   :     #05 pc 00047317  /system/lib/libc.so (_ZL15__pthread_startPv+22)03-02 23:53:49.492 17951 17951 F DEBUG   :     #06 pc 0001a7e5  /system/lib/libc.so (__start_thread+34)03-02 23:53:49.492 17951 17951 F DEBUG   :     Tombstone written to: /data/tombstones/tombstone_06Reading symbols from /huge-ssd/aosp-arm64/out/target/product/angler/symbolsRevision: '0'pid: 17946, tid: 17949, name: crasher  >>> crasher <<  ScopedPthreadMutexLocker   bionic/libc/private/ScopedPthreadMutexLocker.h:27  0001aa1b  readdir+10                 bionic/libc/bionic/dirent.cpp:120  00001b91  readdir_null+20            system/core/debuggerd/crasher.cpp:131  0000184b  do_action+978              system/core/debuggerd/crasher.cpp:228  00001459  thread_callback+24         system/core/debuggerd/crasher.cpp:90  00047317  __pthread_start(void*)+22  bionic/libc/bionic/pthread_create.cpp:202 (discriminator 1)  0001a7e5  __start_thread+34          bionic/libc/bionic/clone.cpp:46 (discriminator 1)
    
注意：某些系统库是使用 LOCAL_STRIP_MODULE := keep_symbols 编译的，可直接提供可用的回溯，而不会像未剥离版本那样占用较大的空间。
    
您也可以 stack 整个 tombstone。示例：
    
                  stack < FS/data/tombstones/tombstone_05    
如果您刚刚在当前目录中解压过错误报告，这将非常有用。要详细了解如何诊断原生代码崩溃和 tombstone，请参阅诊断原生代码崩溃。
    
从正在运行的进程获取堆栈跟踪/tombstone
    
您也可以使用 debuggerd 工具从正在运行的进程获取堆栈转储。 在命令行中，使用进程 ID (PID) 调用 debuggerd，以将完整的 tombstone 转储至 stdout。要确切获取进程中每个线程的堆栈，请添加 -b 或 --backtrace 标记。
    

                                                                                                  







更多相关文章
	

    

  1. Android 应用进程保活APP常驻内存研究方案
  2. Android进程间通信（IPC）机制Binder简要介绍和学习计划
  3. android利用异常打印调用堆栈信息
  4. Android中画bitmap的简单示例
  5. Android反射机制技术的使用示例
  6. android 中怎样能够清除activity堆栈，也就是退出整个应用
  7. android倒计时控件示例
  8. Android Gradle Release Version 2.4 增加多进程并行编译，经测试
  9. Android部分控件示例汇总



随机推荐
	

    

  1. 
JAVA使用JDBC连接MySQL数据库
    2. 

  2. 
如何在VB.net中进行备份和恢复mysql数据
    3. 

  3. 
win7下Django的MySql安装，问题解决方案
    4. 

  4. 
Hibernate不尊重MySQL auto_increment主
    5. 

  5. 
关于Mysql的图形化管理工具sqlyog的注册
    6. 

  6. 
Laravel和PHP：返回特殊格式的JSON
    7. 

  7. 
mysql大表更新sql的优化策略（转）
    8. 

  8. 
mysql 5.5 zip配置安装
    9. 

  9. 
mysql数据库utf-8编码
    10. 

  10. 
机智的MySQL优化器 --- is null
    11.