During the past two days, I checked the android compilation and rootfs preparation procedures, and accidentally found it in build/tools/-ADBs!
ADBs is a command line tool written in Python. Using the three tools ADB, addr2line, and objdump, you may be able to guess after reading these three tools, ADBs is used to analyze applications, especially crash problems related to function libraries :)
The specific code will not be looked at much. It is nothing more than the setting of some runtime environments.
Let's take a look at how to use it:
1. Set the android_product_out environment variable.
Android_product_out = "[your_path]/mydroid/out/target/product/generic", because ADBs needs to use the compiled symbols, You need to compile the entire android source, get the symbols file consistent with your debugging environment
2. Run ADBs directly.
ADBs logcat
I specially prepared a crash JNI testing program. The result is as follows:
I/debug (170 ): **************************************** ********
I/debug (170): Build fingerprint: 'tmous/htc_pyramid/pyramid: 2.3.4/grj22/125597.1: User/release-keys'
I/debug (170): PID: 20715, TID: 20727 >>> [your product name] <
I/debug (170): Signal 11 (SIGSEGV), Code 1 (segv_maperr), fault ADDR deadbaad
....
I/debug (170): SCR 80000010
I/debug (170 ):
I/debug (170): #00 execle/[your_path]/mydroid/bionic/libc/unistd/exec. C: 84
I/debug (170): #01 tmalloc_small.clone.10 <-tmalloc_small/[your_path]/mydroid/bionic/libc/bionic/dlmalloc. C: 3896
I/debug (170): #02 get_malloc_leak_info/[your_path]/mydroid/bionic/libc/bionic/malloc_debug_common.c: 168
./Prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/ARM-Eabi-objdump: '/[your_path]/xxxxxx
./Prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-addr2line: '[your_path]/xxxxxx
I/debug (170): #03 (unknown)
I/debug (170): #04 dvmplatforminvoke dexdatamap. C: 0
I/debug (170 ):
Here we can see that ADBs provides useful information in the black body, that is, some address to the specific program function name and the number of rows are converted, so that we can easily locate the problem.
To give you a clearer picture, the following is the crash information displayed simply using logcat:
17:18:40 from 11 to 02. 438: INFO/debug (170 ): **************************************** ********
11-02 17:18:40. 438: INFO/debug (170): Build fingerprint: 'tmous/htc_pyramid/pyramid: 2.3.4/grj22/125597.1: User/release-keys'
11-02 17:18:40. 448: INFO/debug (170): PID: 20715, TID: 20727 >>> [your product name] <
11-02 17:18:40. 448: INFO/debug (170): Signal 11 (SIGSEGV), Code 1 (segv_maperr), fault ADDR deadbaad
...
11-02 17:18:40. 448: INFO/debug (170): SCR 80000010
11-02 17:18:40. 618: INFO/debug (170): #00 PC 000161c8/system/lib/libc. So (_ libc_android_abort)
11-02 17:18:40. 618: INFO/debug (170): #01 PC 00013bf0/system/lib/libc. So (dlfree)
11-02 17:18:40. 618: INFO/debug (170): #02 PC 00014a72/system/lib/libc. So (free)
11-02 17:18:40. 618: INFO/debug (170): #03 PC route 664e [your crash app name]
11-02 17:18:40. 618: INFO/debug (170): #04 PC 00011e74/system/lib/libdvm. So
11-02 17:18:40. 618: INFO/debug (170): code around PC:
11-02 17:18:40. 618: INFO/debug (170): afd161a8 2c006824 e028d1fb b13213db c064f8df
Http://blog.csdn.net/melody_lu123/article/details/6929292