androidobjdump

A. 如何定位android NDK開發中遇到的錯誤法

Android NDK定義：
Android NDK 是在SDK前面又加上了「原生」二字，即Native Development Kit，因此又被Google稱為「NDK」。眾所周知，Android程序運行在Dalvik虛擬機中，NDK允許用戶使用類似C / C++之類的原生代碼語言執行部分程序。
常見的NDK類型異常會導致程序錯誤：
NDK編譯生成的。so文件作為程序的一部分，在運行發生異常時同樣會造成程序崩潰。
不同於Java代碼異常造成的程序崩潰，在NDK的異常發生時，程序在Android設備上都會立即退出，即通常所說的閃退，而不會彈出「程序xxx無響應，是否立即關閉」之類的提示框。
NDK是使用C/C++來進行開發的，熟悉C/C++的程序員都知道，指針和內存管理是最重要也是最容易出問題的地方，稍有不慎就會遇到諸如內存無效訪問、無效對象、內存泄露、堆棧溢出等常見的問題。
在程序的某個位置釋放了某個內存空間，而後在程序的其他位置試圖訪問該內存地址，這就會產生無效地址錯誤。
發現並解決NDK錯誤：
ndk-stack。
這個命令行工具包含在NDK工具的安裝目錄，和ndk-build及其他常用的一些NDK命令放在一起。根據Google官方文檔，NDK從r6版本開始提供ndk-stack命令。
使用addr2line和objmp命令。
這個方法適用於那些不滿足於上述ndk-stack的簡單用法，在NDK中自帶了適用於各個操作系統和CPU架構的工具鏈，其中就包含了這兩個命令，只不過名字稍有變化，可以在NDK目錄的toolchains目錄下找到。
注意：以上提到的方法，只適合在開發測試期間，如果應用或游戲已經上線，而用戶經常反饋說崩潰、閃退，指望用戶收集信息定位問題幾乎是不可能的。這個時候，就需要用其他的手段來捕獲崩潰信息。

B. android下有沒有objmp的方法

你好，有的，方法如下：
1. NDK的toolchain里應該有可以運行於本地的arm eabi的objmp，

可以把so文件adb pull到計算機上，用NDK里的這個看

2. 找找objmp for arm

如果我的回答沒幫助到您，請繼續追問。

C. 如何調試分析Android中發生的tombstone

Android中較容易出現以下三類問題:Force close / ANR / Tombstone

前兩者主要是查看當前的進程或者系統框架層的狀態和堆棧就基本可以分析出來，本文主要討論一下tombstone的情況。

tombstone一般是由Dalvik錯誤、狀態監視調試器、C層代碼以及libc的一些問題導致的。

當
系統發生tombstone的時候，kernel首先會上報一個嚴重的警告信號（signal）,上層接收到之後，進程的調試工具會把進程中當時的調用棧
現場保存起來，並在系統創建了data/tombstones目錄後把異常時的進程信息寫在此目錄裡面，開發者需要通過調用棧來分析整個調用流程來找出出
問題的點。

基本工具：

prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin

在分析的時候仔細讀取匯編會獲得更多有用的異常發生時的信息。

1.arm-eabi-addr2line 將類似libxxx.so 0x00012345的調用棧16進制值翻譯成文件名和函數名

arm-eabi-addr2line -e libxxx.so 0x00012345

2.arm-eabi-nm 列出文件的符號信息

arm-eabi-nm -l -C -n -S libdvm.so > dvm.data

3.arm-eabi-objmp 列出文件的詳細信息

arm-eabi-objmp -C -d libc.so > libc.s

通過以上工具的分析 ，我們可以得到較完整的調用棧以及調用邏輯的匯編碼。

然後需要結合ARM架構及ARM匯編的知識（有些情況下可能需要使用gdb）

來分析出現tombstone的原因，以下是本人遇到過的一些tombstone的情況：

1.無效的函數指針：指針為NULL或者已經被重新賦值

2.strlen崩潰：導致不完全的棧信息，棧被破壞
3.FILE操作：因為stdio並非線程安全的，多線程操作時，容易出現異常。

D. 如何定位Android NDK開發中遇到的錯誤

利用Android NDK開發本地應用時，幾乎所有的程序員都遇到過程序崩潰的問題，但它的崩潰會在logcat中列印一堆看起來類似天書的堆棧信息，讓人舉足無措。單靠添加一行行的列印信息來定位錯誤代碼做在的行數，無疑是一件令人崩潰的事情。在網上搜索「Android NDK崩潰」，可以搜索到很多文章來介紹如何通過Android提供的工具來查找和定位NDK的錯誤，但大都晦澀難懂。下面以一個實際的例子來說明，如何通過兩種不同的方法，來定位錯誤的函數名和代碼行。

首先，來看看我們在hello-jni程序的代碼中做了什麼（有關如何創建或導入工程，此處略），下面代碼中：在JNI_OnLoad()的函數中，即so載入時，調用willCrash()函數，而在willCrash()函數中， std::string的這種賦值方法會產生一個空指針錯誤。這樣，在hello-jni程序載入時就會閃退。我們記一下這兩個行數：在61行調用了willCrash()函數；在69行發生了崩潰。

下面我們來看看發生崩潰（閃退）時系統列印的logcat日誌：

如果你看過logcat列印的NDK錯誤的日誌就會知道，我省略了後面很多的內容，很多人看到這么多密密麻麻的日誌就已經頭暈腦脹了，即使是很多資深的Android開發者，在面對NDK日誌時也大都默默地選擇了無視。

其實，只要你細心的查看，再配合Google 提供的工具，完全可以快速地准確定位出錯的代碼位置，這個工作我們稱之為「符號化」。需要注意的是，如果要對NDK錯誤進行符號化的工作，需要保留編譯過程中產生的包含符號表的so文件，這些文件一般保存在$PROJECT_PATH/obj/local/目錄下。

第一種方法：ndk-stack

這個命令行工具包含在NDK工具的安裝目錄，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的電腦上，其位置是/android-ndk-r9d/ndk-stack。根據Google官方文檔，NDK從r6版本開始提供ndk-stack命令，如果你用的之前的版本，建議還是盡快升級至最新的版本。使用ndk –stack命令也有兩種方式

實時分析日誌

在運行程序的同時，使用adb獲取logcat日誌，並通過管道符輸出給ndk-stack，同時需要指定包含符號表的so文件位置；如果你的程序包含了多種CPU架構，在這里需求根據錯誤發生時的手機CPU類型，選擇不同的CPU架構目錄，如：

當崩潰發生時，會得到如下的信息：

我們重點看一下#03和#04，這兩行都是在我們自己生成的libhello-jni.so中的報錯信息，因此會發現如下關鍵信息：

回想一下我們的代碼，在JNI_OnLoad()函數中（第61行），我們調用了willCrash()函數；在willCrash()函數中（第69行），我們製造了一個錯誤。這些信息都被准確無誤的提取了出來！是不是非常簡單？

先獲取日誌再分析

這種方法其實和上面的方法沒有什麼大的區別，僅僅是logcat日誌獲取的方式不同。可以在程序運行的過程中將logcat日誌保存到一個文件，甚至可以在崩潰發生時，快速的將logcat日誌保存起來，然後再進行分析，比上面的方法稍微靈活一點，而且日誌可以留待以後繼續分析。

第二種方法：使用addr2line和objmp命令

這個方法適用於那些不滿足於上述ndk-stack的簡單用法，而喜歡刨根問底的程序員們，這兩個方法可以揭示ndk-stack命令的工作原理是什麼，盡管用起來稍微麻煩一點，但可以稍稍滿足一下程序員的好奇心。

先簡單說一下這兩個命令，在絕大部分的Linux發行版本中都能找到他們，如果你的操作系統是Linux，而你測試手機使用的是Intel x86系列，那麼你使用系統中自帶的命令就可以了。然而，如果僅僅是這樣，那麼絕大多數人要絕望了，因為恰恰大部分開發者使用的是Windows，而手機很有可能是armeabi系列。

在NDK中自帶了適用於各個操作系統和CPU架構的工具鏈，其中就包含了這兩個命令，只不過名字稍有變化，你可以在NDK目錄的toolchains目錄下找到他們。以我的Mac電腦為例，如果我要找的是適用於armeabi架構的工具，那麼他們分別為arm-linux-androideabi-addr2line和arm-linux-androideabi-objmp；位置在下面目錄中，後續介紹中將省略此位置：

假設你的電腦是Windows系統，CPU架構為mips，那麼你要的工具可能包含在一下目錄中：

接下來就讓我們來看看如何使用這兩個工具，下面具體介紹。

找到日誌中的關鍵函數指針

其實很簡單，就是找到backtrace信息中，屬於我們自己的so文件報錯的行。

首先要找到backtrace信息，有的手機會明確列印一行backtrace（比如我們這次使用的手機），那麼這一行下面的一系列以「#兩位數字 pc」開頭的行就是backtrace信息了。有時可能有的手機並不會列印一行backtrace，那麼只要找到一段以「#兩位數字 pc 」開頭的行，就可以了。

其次要找到屬於自己的so文件報錯的行，這就比較簡單了。找到這些行之後，記下這些行中的函數地址。

使用addr2line查找代碼位置

執行如下的命令，多個指針地址可以在一個命令中帶入，以空格隔開即可

結果如下：

從addr2line的結果就能看到，我們拿到了我們自己的錯誤代碼的調用關系和行數，在hello-jni.cpp的69行和61行（另外兩行因為使用的是標准函數，可以忽略掉），結果和ndk-stack是一致的，說明ndk-stack也是通過addr2line來獲取代碼位置的。

使用objmp獲取函數信息

通過addr2line命令，其實我們已經找到了我們代碼中出錯的位置，已經可以幫助程序員定位問題所在了。但是，這個方法只能獲取代碼行數，並沒有顯示函數信息，顯得不那麼「完美」，對於追求極致的程序員來說，這當然是不夠的。下面我們就演示一下怎麼來定位函數信息。

首先使用如下命令導出函數表：

在生成的asm文件中查找剛剛我們定位的兩個關鍵指針00004fb4和00004f58：

從這兩張圖可以清楚的看到（要注意的是，在不同的NDK版本和不同的操作系統中，asm文件的格式不是完全相同，但都大同小異，請大家仔細比對），這兩個指針分別屬於willCrash()和JNI_OnLoad()函數，再結合剛才addr2line的結果，那麼這兩個地址分別對應的信息就是：

相當完美，和ndk-stack得到的信息完全一致！

Testin崩潰分析如何幫開發者發現NDK錯誤

以上提到的方法，只適合在開發測試期間，如果你的應用或游戲已經上線，而用戶經常反饋說崩潰、閃退，指望用戶幫你收集信息定位問題幾乎是不可能的。這個時候，我們就需要用其他的手段來捕獲崩潰信息。

目前業界已經有一些公司推出了崩潰信息收集的服務，通過嵌入SDK，在程序發生崩潰時收集堆棧信息，發送到雲服務平台，從而幫助開發者定位錯誤信息。在這方面，國內的Testin和國外的crittercism都可以提供類似服務。

Testin從1.4版本開始支持NDK的崩潰分析，其最新版本已升級到1.7。當程序發生NDK錯誤時，其內嵌的SDK會收集程序在用戶手機上發生崩潰時的堆棧信息（主要就是上面我們通過logcat日誌獲取到的函數指針）、設備信息、線程信息等，SDK將這些信息上報至Testin雲服務平台，在平台進行唯一性的處理、並可以自定義時段進行詳盡的統計分析，從多維度展示程序崩潰的信息和嚴重程度；最新版本還支持用戶自定義場景，方便開發者定位問題所在。

從用戶手機上報的堆棧信息，Testin為NDK崩潰提供了符號化的功能，只要將我們編譯過程中產生的包含符號表的so文件上傳，就可以自動將函數指針地址定位到函數名稱和代碼行數。符號化之後，看起來就和我們前面在本地測試的結果是一樣的了，一目瞭然。而且使用這個功能還有一個好處：這些包含符號表的so文件，在每次開發者編譯之後都會改變，很有可能我們發布之後就已經變了，因為開發者會修改程序。在這樣的情況下，即使我們拿到了崩潰時的堆棧信息，那也無法再進行符號化了。我們可以將這些文件上傳到Testin進行符號化的工作，Testin會為我們保存和管理不同版本的so文件，確保信息不會丟失。

E. 如何調試分析android中發生的tombstone

1.arm-eabi-addr2line 將類似libxxx.so 0x00012345的調用棧16進制值翻譯成文件名和函數名
arm-eabi-addr2line -e libxxx.so 0x00012345
2.arm-eabi-nm 列出文件的符號信息
arm-eabi-nm -l -C -n -S libdvm.so > dvm.data
3.arm-eabi-objmp 列出文件的詳細信息
arm-eabi-objmp -C -d libc.so > libc.s
通過以上工具的分析 ，我們可以得到較完整的調用棧以及調用邏輯的匯編碼。
然後需要結合ARM架構及ARM匯編的知識（有些情況下可能需要使用gdb）
來分析出現tombstone的原因，以下是本人遇到過的一些tombstone的情況：
1.無效的函數指針：指針為NULL或者已經被重新賦值
2.strlen崩潰：導致不完全的棧信息，棧被破壞
3.FILE操作：因為stdio並非線程安全的，多線程操作時，容易出現異常。

F. 如何定位Android NDK開發中遇到的錯誤

NDK編譯生成的.so文件作為程序的一部分，在運行發生異常時同樣會造成程序崩潰。不同於Java代碼異常造成的程序崩潰，在NDK的異常發生時，程序在Android設備上都會立即退出，即通常所說的閃退，而不會彈出「程序xxx無響應，是否立即關閉」之類的提示框。

NDK是使用C/C++來進行開發的，熟悉C/C++的程序員都知道，指針和內存管理是最重要也是最容易出問題的地方，稍有不慎就會遇到諸如內存無效訪問、無效對象、內存泄露、堆棧溢出等常見的問題，最後都是同一個結果：程序崩潰。例如我們常說的空指針錯誤，就是當一個內存指針被置為空（NULL）之後再次對其進行訪問；另外一個經常出現的錯誤是，在程序的某個位置釋放了某個內存空間，而後在程序的其他位置試圖訪問該內存地址，這就會產生一個無效地址錯誤。常見的錯誤類型如下：

初始化錯誤

訪問錯誤

數組索引訪問越界

指針對象訪問越界

訪問空指針對象

訪問無效指針對象

迭代器訪問越界

內存泄露

參數錯誤

堆棧溢出

類型轉換錯誤

數字除0錯誤

利用Android NDK開發本地應用的時候，幾乎所有的程序員都遇到過程序崩潰的問題，但它的崩潰會在logcat中列印一堆看起來類似天書的堆棧信息，讓人舉足無措。單靠添加一行行的列印信息來定位錯誤代碼做在的行數，無疑是一件令人崩潰的事情。在網上搜索「Android NDK崩潰」，可以搜索到很多文章來介紹如何通過Android提供的工具來查找和定位NDK的錯誤，但大都晦澀難懂。下面以一個實際的例子來說明，首先生成一個錯誤，然後演示如何通過兩種不同的方法，來定位錯誤的函數名和代碼行。

首先，看我們在hello-jni程序的代碼中做了什麼（有關如何創建或導入工程，此處略），看下圖：在JNI_OnLoad()的函數中，即so載入時，調用willCrash()函數，而在willCrash()函數中，std::string的這種賦值方法會產生一個空指針錯誤。這樣，在hello-jni程序載入時就會閃退。我們記一下這兩個行數：在61行調用了willCrash()函數；在69行發生了崩潰。

下面來看看發生崩潰（閃退）時系統列印的logcat日誌：

[plain] view plain

************************************************

Buildfingerprint:'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys'

pid:32607,tid:32607,name:xample.hellojni>>>com.example.hellojni<<<

signal11(SIGSEGV),code1(SEGV_MAPERR),faultaddr00000000

backtrace:

#00pc00023438/system/lib/libc.so

#01pc00004de8/data/app-lib/com.example.hellojni-2/libhello-jni.so

#02pc000056c8/data/app-lib/com.example.hellojni-2/libhello-jni.so

#03pc00004fb4/data/app-lib/com.example.hellojni-2/libhello-jni.so

#04pc00004f58/data/app-lib/com.example.hellojni-2/libhello-jni.so

#05pc000505b9/system/lib/libdvm.so

#06pc00068005/system/lib/libdvm.so

#07pc000278a0/system/lib/libdvm.so

#08pc0002b7fc/system/lib/libdvm.so

#09pc00060fe1/system/lib/libdvm.so

#10pc0006100b/system/lib/libdvm.so

#11pc0006c6eb/system/lib/libdvm.so

#12pc00067a1f/system/lib/libdvm.so

#13pc000278a0/system/lib/libdvm.so

#14pc0002b7fc/system/lib/libdvm.so

#15pc00061307/system/lib/libdvm.so

#16pc0006912d/system/lib/libdvm.so

#17pc000278a0/system/lib/libdvm.so

#18pc0002b7fc/system/lib/libdvm.so

#19pc00060fe1/system/lib/libdvm.so

#20pc00049ff9/system/lib/libdvm.so

#21pc0004d419/system/lib/libandroid_runtime.so

#22pc0004e1bd/system/lib/libandroid_runtime.so

#23pc00001d37/system/bin/app_process

#24pc0001bd98/system/lib/libc.so

#25pc00001904/system/bin/app_process

stack:

beb12340012153f8

beb1234400054290

beb1234800000035

beb1234cbeb123c0[stack]

……

如果你看過logcat列印的NDK錯誤時的日誌就會知道，我省略了後面很多的內容，很多人看到這么多密密麻麻的日誌就已經頭暈腦脹了，即使是很多資深的Android開發者，在面對NDK日誌時也大都默默的選擇了無視。

「符號化」NDK錯誤信息的方法

其實，只要你細心的查看，再配合Google提供的工具，完全可以快速的准確定位出錯的代碼位置，這個工作我們稱之為「符號化」。需要注意的是，如果要對NDK錯誤進行符號化的工作，需要保留編譯過程中產生的包含符號表的so文件，這些文件一般保存在$PROJECT_PATH/obj/local/目錄下。

第一種方法：ndk-stack

這個命令行工具包含在NDK工具的安裝目錄，和ndk-build和其他一些常用的NDK命令放在一起，比如在我的電腦上，其位置是/android-ndk-r9d/ndk-stack。根據Google官方文檔，NDK從r6版本開始提供ndk-stack命令，如果你用的之前的版本，建議還是盡快升級至最新的版本。使用ndk –stack命令也有兩種方式

使用ndk-stack實時分析日誌

在運行程序的同時，使用adb獲取logcat日誌，並通過管道符輸出給ndk-stack，同時需要指定包含符號表的so文件位置；如果你的程序包含了多種CPU架構，在這里需求根據錯誤發生時的手機CPU類型，選擇不同的CPU架構目錄，如：

[plain] view plain

adbshelllogcat|ndk-stack-sym$PROJECT_PATH/obj/local/armeabi

當崩潰發生時，會得到如下的信息：

[plain] view plain

**********Crashmp:**********

Buildfingerprint:'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys'

pid:32607,tid:32607,name:xample.hellojni>>>com.example.hellojni<<<

signal11(SIGSEGV),code1(SEGV_MAPERR),faultaddr00000000

Stackframe#00pc00023438/system/lib/libc.so(strlen+72)

Stackframe#01pc00004de8/data/app-lib/com.example.hellojni-2/libhello-jni.so(std::char_traits<char>::length(charconst*)+20):Routinestd::char_traits<char>::length(charconst*)at/android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229

Stackframe#02pc000056c8/data/app-lib/com.example.hellojni-2/libhello-jni.so(std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string(charconst*,std::allocator<char>const&)+44):Routinebasic_stringat/android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639

Stackframe#03pc00004fb4/data/app-lib/com.example.hellojni-2/libhello-jni.so(willCrash()+68):RoutinewillCrash()at/home/testin/hello-jni/jni/hello-jni.cpp:69

Stackframe#04pc00004f58/data/app-lib/com.example.hellojni-2/libhello-jni.so(JNI_OnLoad+20):RoutineJNI_OnLoadat/home/testin/hello-jni/jni/hello-jni.cpp:61

Stackframe#05pc000505b9/system/lib/libdvm.so(dvmLoadNativeCode(charconst*,Object*,char**)+516)

Stackframe#06pc00068005/system/lib/libdvm.so

Stackframe#07pc000278a0/system/lib/libdvm.so

Stackframe#08pc0002b7fc/system/lib/libdvm.so(dvmInterpret(Thread*,Methodconst*,JValue*)+180)

Stackframe#09pc00060fe1/system/lib/libdvm.so(dvmCallMethodV(Thread*,Methodconst*,Object*,bool,JValue*,std::__va_list)+272)

……（後面略）

我們重點看一下#03和#04，這兩行都是在我們自己生成的libhello-jni.so中的報錯信息，那麼會發現如下關鍵信息：

[plain] view plain

#03(willCrash()+68):RoutinewillCrash()at/home/testin/hello-jni/jni/hello-jni.cpp:69

#04(JNI_OnLoad+20):RoutineJNI_OnLoadat/home/testin/hello-jni/jni/hello-jni.cpp:61

回想一下我們的代碼，在JNI_OnLoad()函數中（第61行），我們調用了willCrash()函數；在willCrash()函數中（第69行），我們製造了一個錯誤。這些信息都被准確無誤的提取了出來！是不是非常簡單？

先獲取日誌，再使用ndk-stack分析

這種方法其實和上面的方法沒有什麼大的區別，僅僅是logcat日誌獲取的方式不同。可以在程序運行的過程中將logcat日誌保存到一個文件，甚至可以在崩潰發生時，快速的將logcat日誌保存起來，然後再進行分析，比上面的方法稍微靈活一點，而且日誌可以留待以後繼續分析。

[plain] view plain

adbshelllogcat>1.log

ndk-stack-sym$PROJECT_PATH/obj/local/armeabi–mp1.log

第二種方法：使用addr2line和objmp命令

這個方法適用於那些，不滿足於上述ndk-stack的簡單用法，而喜歡刨根問底的程序員們，這兩個方法可以揭示ndk-stack命令的工作原理是什麼，盡管用起來稍微麻煩一點，但是可以滿足一下程序員的好奇心。

先簡單說一下這兩個命令，在絕大部分的linux發行版本中都能找到他們，如果你的操作系統是linux，而你測試手機使用的是Intel x86系列，那麼你使用系統中自帶的命令就可以了。然而，如果僅僅是這樣，那麼絕大多數人要絕望了，因為恰恰大部分開發者使用的是Windows，而手機很有可能是armeabi系列。

別急，在NDK中自帶了適用於各個操作系統和CPU架構的工具鏈，其中就包含了這兩個命令，只不過名字稍有變化，你可以在NDK目錄的toolchains目錄下找到他們。以我的Mac電腦為例，如果我要找的是適用於armeabi架構的工具，那麼他們分別為arm-linux-androideabi-addr2line和arm-linux-androideabi-objmp；位置在下面目錄中，後續介紹中將省略此位置：

[plain] view plain

/Developer/android_sdk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/

假設你的電腦是windows，CPU架構為mips，那麼你要的工具可能包含在這個目錄中：

[plain] view plain

D:android-ndk-r9d oolchainsmipsel-linux-android-4.8prebuiltwindows-x86_64in

G. 如何定位Android NDK開發中遇到的錯誤

第一種方法：ndk-stack
這個命令行工具包含在NDK工具的安裝目錄，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的電腦上，其位置是/android-ndk-r9d/ndk-stack。根據Google官方文檔，NDK從r6版本開始提供ndk-stack命令，如果你用的之前的版本，建議還是盡快升級至最新的版本。使用ndk –stack命令也有兩種方式
實時分析日誌
在運行程序的同時，使用adb獲取logcat日誌，並通過管道符輸出給ndk-stack，同時需要指定包含符號表的so文件位置；如果你的程序包含了多種CPU架構，在這里需求根據錯誤發生時的手機CPU類型，選擇不同的CPU架構目錄，如：

當崩潰發生時，會得到如下的信息：

我們重點看一下#03和#04，這兩行都是在我們自己生成的libhello-jni.so中的報錯信息，因此會發現如下關鍵信息：

回想一下我們的代碼，在JNI_OnLoad()函數中（第61行），我們調用了willCrash()函數；在willCrash()函數中（第69行），我們製造了一個錯誤。這些信息都被准確無誤的提取了出來！是不是非常簡單？
先獲取日誌再分析
這種方法其實和上面的方法沒有什麼大的區別，僅僅是logcat日誌獲取的方式不同。可以在程序運行的過程中將logcat日誌保存到一個文件，甚至可以在崩潰發生時，快速的將logcat日誌保存起來，然後再進行分析，比上面的方法稍微靈活一點，而且日誌可以留待以後繼續分析。

第二種方法：使用addr2line和objmp命令
這個方法適用於那些不滿足於上述ndk-stack的簡單用法，而喜歡刨根問底的程序員們，這兩個方法可以揭示ndk-stack命令的工作原理是什麼，盡管用起來稍微麻煩一點，但可以稍稍滿足一下程序員的好奇心。
先簡單說一下這兩個命令，在絕大部分的Linux發行版本中都能找到他們，如果你的操作系統是Linux，而你測試手機使用的是Intel x86系列，那麼你使用系統中自帶的命令就可以了。然而，如果僅僅是這樣，那麼絕大多數人要絕望了，因為恰恰大部分開發者使用的是Windows，而手機很有可能是armeabi系列。
在NDK中自帶了適用於各個操作系統和CPU架構的工具鏈，其中就包含了這兩個命令，只不過名字稍有變化，你可以在NDK目錄的toolchains目錄下找到他們。以我的Mac電腦為例，如果我要找的是適用於armeabi架構的工具，那麼他們分別為arm-linux-androideabi-addr2line和arm-linux-androideabi-objmp；位置在下面目錄中，後續介紹中將省略此位置：

假設你的電腦是Windows系統，CPU架構為mips，那麼你要的工具可能包含在一下目錄中：

接下來就讓我們來看看如何使用這兩個工具，下面具體介紹。
找到日誌中的關鍵函數指針
其實很簡單，就是找到backtrace信息中，屬於我們自己的so文件報錯的行。
首先要找到backtrace信息，有的手機會明確列印一行backtrace（比如我們這次使用的手機），那麼這一行下面的一系列以「#兩位數字 pc」開頭的行就是backtrace信息了。有時可能有的手機並不會列印一行backtrace，那麼只要找到一段以「#兩位數字 pc 」開頭的行，就可以了。

其次要找到屬於自己的so文件報錯的行，這就比較簡單了。找到這些行之後，記下這些行中的函數地址。

使用addr2line查找代碼位置
執行如下的命令，多個指針地址可以在一個命令中帶入，以空格隔開即可

結果如下：

從addr2line的結果就能看到，我們拿到了我們自己的錯誤代碼的調用關系和行數，在hello-jni.cpp的69行和61行（另外兩行因為使用的是標准函數，可以忽略掉），結果和ndk-stack是一致的，說明ndk-stack也是通過addr2line來獲取代碼位置的。

H. 如何定位Android NDK開發中遇到的錯誤

• Android NDK定義

  Android NDK 是在SDK前面又加上了「原生」二字，即Native Development Kit，因此又被Google稱為「NDK」。Android程序運行在Dalvik虛擬機中，NDK允許用戶使用類似C / C++之類的原生代碼語言執行部分程序。

  
  

• NDK作用

1. 代碼保護，由於APK的Java層代碼很容易被反編譯，而C/C++庫反匯難度較大。

2. NDK中調用第三方C/C++庫，因為大部分的開源庫都是用C/C++代碼編寫的。

3. 便於移植，用C/C++寫的庫可以方便地在其他的嵌入式平台上再次使用。

   
   

• 及時發現NDK錯誤

第一種：ndk-stack

1. 這個命令行工具包含在NDK工具的安裝目錄，和ndk-build及其他常用的一些NDK命令放在一起。

2. 例子：假如其位置是/android-ndk-r9d/ndk-stack。根據Google官方文檔，NDK從r6版本開始提供ndk-stack命令，如果用的之前的版本，建議還是盡快升級至最新的版本。

3. 當崩潰發生時，會得到如下的信息：

   

以上提到的方法，只適合在開發測試期間，如果應用或游戲已經上線，而用戶經常反饋說崩潰、閃退，指望用戶收集信息定位問題幾乎是不可能的。這個時候，就需要用其他的手段來捕獲崩潰信息。

I. 如何利用android studio 編譯c code

學習 android 逆向分析過程中，需要學習 Arm 指令，不可避免要編寫一些 test code 並分析其指令，這是這篇文檔的背景。

在目前 android 提供的開發環境里，如果要編寫 c / cpp code， 一般是通過 ndk 開發套件，基本方法就是在
windows 或 linux 發行版上下載 ndk 環境，然後編寫 c / cpp code 然後編寫 Android.mk 文件，最後用
ndk-build 等工具進行編譯，編譯出來的可執行文件再通過 adb push 的方式提交到 devices 或 emulator
運行，如果要分析其指令，需要下載 android 提供的 prebuilts binutils 工具集（如android 源碼的
prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/arm-linux-androideabi/bin/
目錄），如果你在linux上用file命令查看一下這些工具，會發現 ：

root@ubuntu:bin# file objmp
objmp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped

它們是x86架構的，這樣，你要分析devices或emulator里的elf文件，需要adb pull 下來，放在本地的linux環境或者windows里，用上述prebuilt工具分析。

稍微思考一下就會發現上述 ndk
的方式，對我們的需求來說有點太復雜了，我們真正希望的是像在標准linux發行版上那樣，可以用vi/vim等編輯工具寫 c/cpp
code,然後用 gcc /g++ 等編譯工具編譯，然後能直接運行或者用gdb調試，
或者用readelf/objmp等命令查看elf結果和匯編碼。問題變成了：如何在android上實現這一切？

下面的方式是經過本人收集和實際測試證明可行的，我的環境是：

目標機：小米2手機， android4.4.4, miui 6.3.5

本地機： win7

效果：在本地機adb目標機的shell, 然後用vi寫 c/cpp code, 直接在shell上用gcc編譯，用objmp分析指令

實現步驟如下：

1. 首先安裝 busybox apk . 這個app提供了後續需要的 busy vi, busy tar 等工具

2. 下載 adb putty ,http://yunpan.cn/cZ5x9UrDFUDdK （提取碼：e70e）

這個工具用來做終端，這里為什麼不用win7自帶的cmd或者其他增強版如 powerCmd 呢？ 因為用 windows 的 cmd 終端，adb shell 連接上手機後，執行 busybox vi 等命令，會出現亂碼，參考http://www.hu.com/question/20624475， 用這款 adb putty 終端則可以正常使用。

3. 下載 gcc arm,http://yunpan.cn/cZ5YVZzbvJqq4 （提取碼：80b8）