android調試列印
① 如何將Android底層庫列印調試信息到logcat中查看
Android開發中,所的有輸出都在logcat中 包含System.out輸出和printStackTrace()輸出都在Logcat中,Android開發,建議使用android提供的Log工具類來列印信息。
找到Logcat視圖的方式:
Eclipse 點擊 Window
Show View會出來一個對話框
點擊Ok按鈕時，會在控制台窗口出現LogCat視窗
android.util.Log常用的方法有以下5個：Log.v()Log.d()Log.i()Log.w()以及Log.e()。根據首字母對應VERBOSE，DEBUG,INFO,WARN，ERROR。
1、Log.v 的調試顏色為黑色的，任何消息都會輸出，這里的旅鄭羨v代表verbose啰嗦的意思，平時使用就是Log.v("","");
2、Log.d的輸出顏色是藍色的，僅輸出debug調試的意思，但他會輸出上層的信息，過濾起來可以通過DDMS的Logcat標簽來選擇.
3、Log.i的輸出為綠色，一般提示性的消息information，它不會輸出Log.v和Log.d的信息，但會顯示i、w和e的信息
4、Log.w的意思為橙色，可以看作為warning警告，一般需要我們注意優化Android代碼，同時選擇它後拆拍還會輸出Log.e的信息。
5、Log.e為紅色，可以想到error錯誤，叢搭這里僅顯示紅色的錯誤信息，這些錯誤就需要認真的分析，查看棧的信息了。
② Android-NDK：JNI本地文件中怎麼調試列印輸出到LOGCAT
加入頭文件
#include <android/log.h>
函數__android_log_print(ANDROID_LOG_INFO,LOG_TAG,TITLE)
第一個參數ANDROID_LOG_INFO（還有ANDROID_LOG_ERROR等），表示什麼類型
的輸出，上面的函數相當於android的java代碼的Log.i(LOG_TAG,TITLE),第二個參數就是logcat里的tag，第三個就是列印的內容。具體的請到log.h中自己查看。
Android之NDK開發
一、NDK產生的背景
Android平台從誕生起，就已經支持C、C++開發。眾所周知，Android的SDK基於Java實現，這意味著基於Android SDK進行開發的第三方應用都必須使用Java語言。但這並不等同於「第三方應用只能使用Java」。在Android SDK首次發布時，Google就宣稱其虛擬機Dalvik支持JNI編程方式，也就是第三方應用完全可以通過JNI調用自己的C動態庫，即在Android平台上，「Java+C」的編程方式是一直都可以實現的。
不過，Google也表示，使用原生SDK編程相比Dalvik虛擬機也有一些劣勢，Android SDK文檔里，找不到任何JNI方面的幫助。即使第三方應用開發者使用JNI完成了自己的C動態鏈接庫（so）開發，但是so如何和應用程序一起打包成apk並發布？這裡面也存在技術障礙。比如程序更加復雜，兼容性難以保障，無法訪問Framework API，Debug難度更大等。開發者需要自行斟酌使用。
於是NDK就應運而生了。NDK全稱是Native Development Kit。
NDK的發布，使「Java+C」的開發方式終於轉正，成為官方支持的開發方式。NDK將是Android平台支持C開發的開端。
二、為什麼使用NDK
1.代碼的保護。由於apk的java層代碼很容易被反編譯，而C/C++庫反匯難度較大。
2.可以方便地使用現存的開源庫。大部分現存的開源庫都是用C/C++代碼編寫的。
3.提高程序的執行效率。將要求高性能的應用邏輯使用C開發，從而提高應用程序的執行效率。
4.便於移植。用C/C++寫得庫可以方便在其他的嵌入式平台上再次使用。
三、NDK簡介
1.NDK是一系列工具的集合
NDK提供了一系列的工具，幫助開發者快速開發C（或C++）的動態庫，並能自動將so和java應用一起打包成apk。這些工具對開發者的幫助是巨大的。
NDK集成了交叉編譯器，並提供了相應的mk文件隔離CPU、平台、ABI等差異，開發人員只需要簡單修改mk文件（指出「哪些文件需要編譯」、「編譯特性要求」等），就可以創建出so。
NDK可以自動地將so和Java應用一起打包，極大地減輕了開發人員的打包工作。
2.NDK提供了一份穩定、功能有限的API頭文件聲明
Google明確聲明該API是穩定的，在後續所有版本中都穩定支持當前發布的API。從該版本的NDK中看出，這些API支持的功能非常有限，包含有：C標准庫（libc）、標准數學庫（libm）、壓縮庫（libz）、Log庫（liblog）。
③ android ndk調試C++ 代碼怎麼列印異常信息
1 用常規方法建立或導入java工程。
2 在工程所在目錄下建立jni目錄，所有的c++代碼和mk文件都放在這個目錄下。
3 從sample目錄里拷貝Android.mk和Application.mk到jni目錄下並修改相應內容。
4 如果包含多個c++模塊，那麼修改Application.mk的APP_MODULES欄位，例：
APP_MODULES = freetype myapp2
同時建立freetyp.mk, myapp2.mk，修改android.mk為：
LOCAL_PATH := $(call my-dir)
include $(LOCAL_PATH)/freetype.mk
include $(LOCAL_PATH)/myapp2.mk
也就是說：android.mk里可以包含多個模塊的mk文件。
5 如果要使用c++庫函數，在Application.mk里加上
APP_STL := stlport_shared
在android.mk里加上：（注意不用手工添加stlport頭文件目錄）
LOCAL_STATIC_LIBRARIES += libstlport_shared.so
另外java代碼里所有打包進apk的模塊都要手工load，否則要異常：(不像windows是自動load)
System.loadLibrary("stlport_shared");
System.loadLibrary("freetype");
System.loadLibrary("myapp2");
5 把java工程改成c++混合工程：file->new->other->c/c++->convert to a c/c++ project。
我覺得你肯定很忙的呢，是不！今天12點多回答的題，要21點才會審批啊，審批個不通過算了。
④ android adb logcat怎麼列印過濾正在調試的包的信息
如何過濾adb logcat輸出 本文介紹如何在 shell 命令行中過濾 adb logcat 輸出的幾個小技巧。 開發當中經常看到別人的 log 如洪水般瞬間刷滿了屏幕，對自己有用的信息都被淹沒了，影響心情也影響效率。下面是幾個我所知道的過濾方法。 1. 只顯示需要的輸出，白名單 最方便的當然是通過管道使用 grep 過濾了，這樣可以使用 grep 強大的正則表達式匹配。簡單的匹配一行當中的某個字元串，例如 MyApp： adb logcat grep MyApp adb logcat grep -i myapp #忽略大小寫。 adb logcat grep --color=auto -i myapp #設置匹配字元串顏色。更多設置請查看 grep 幫助。 進階一點可以使用 grep 的正則表達式匹配。例如上一個例子會匹配一行中任意位置的 MyApp，可以設置為僅匹配 tag。默認的 log 輸出如下，如果修改過輸出格式相應的表達式也要修改。 I/CacheService( 665): Preparing DiskCache for all thumbnails. 可以看出 tag 是一行開頭的第三個字元開始，根據這點寫出表達式： adb logcat grep "^..MyApp" 根據這個格式也可以設置只顯示某個優先順序的 log，再匹配行首第一個字元即可。例如僅顯示 Error 級別 tag 為 MyApp 的輸出： adb logcat grep "^E.MyApp" 當然也可以匹配多個，使用 分割多個匹配表達式，要加轉義符。例如要匹配 tag 為 MyApp 和 MyActivity 的輸出： adb logcat grep "^..MyApp\^..MyActivity" adb logcat grep -E "^..MyApp^..MyActivity" #使用 egrep 無須轉義符 2. 過濾不需要的輸出，黑名單 還是使用 grep，用法也跟上面的一樣，加一個 -v 即可。例如要過濾 tag 為 MyApp 和 MyActivity 的輸出： adb logcat grep -v "^..MyApp\^..MyActivity" adb logcat grep -vE "^..MyApp^..MyActivity" #使用 egrep 無須轉義符 3. 顯示同一個進程的所有輸出 有時一個程序裡面的 tag 有多個，需要輸出該程序（同一個 PID）的所有 tag；僅使用 tag 過濾有時也會漏掉一些錯誤信息，而一般錯誤信息也是和程序同一個 PID。還是通過 grep 實現，思路是先根據包名找到 pid 號，然後匹配 pid。寫成 shell 腳本如下，參數是程序的 java 包名（如 com.android.media）。 查看源代碼列印幫助 1 #!/bin/bash 2 packageName=$1 3 pid=`adb shell ps grep $packageName awk '{print $2}'` 4 adb logcat grep --color=auto $pid 4. 從當前開始顯示 logcat 有緩存，如果僅需要查看當前開始的 log，需要清空之前的。 adb logcat -c && adb logcat 5. 過濾 log 文件 有時需要分析 log 文件，過濾 log 文件還是使用 grep。例如 log 文件為 myapp.log，要匹配 tag 為 MyApp 和 MyActivity 的輸出，然後輸出到 newmyapp.log： cat myapp.log grep "^..MyApp\^..MyActivity" > newmyapp.log Windows 下推薦使用 Notepad++，一個免費強大的記事本，支持正則表達式查找替換。可以高亮顯示匹配內容，也可以刪除不需要的內容。 以上的技巧主要用到了 grep，其實 logcat 本身也有過濾功能，可以根據 tag、優先順序過濾 log，具體請參考 Android 官方文檔 Reading and Writing Logs。如果喜歡使用圖形界面，請參考 Using DDMS，DDMS 裡面的 logcat 也可以同樣過濾。 android的logcat詳細用法 Android日誌系統提供了記錄和查看系統調試信息的功能。日誌都是從各種軟體和一些系統的緩沖區中記錄下來的，緩沖區可以通過 logcat 命 令來查看和使用. 使用logcat命令 你可以用 logcat 命令來查看系統日誌緩沖區的內容: [adb] logcat [<option>] ... [<filter-spec>] ... 請查看Listing of logcat Command Options ，它有對logcat命 令有詳細的描述 . 你也可以在你的電腦或運行在模擬器/設備上的遠程adb shell端來使用logcat命 令，也可以在你的電腦上查看日誌輸出。 $ adb logcat 你也這樣使用： # logcat 過濾日誌輸出 每一個輸出的Android日誌信息都有一個標簽和它的優先順序. 日誌的標簽是系統部件原始信息的一個簡要的標志。（比如：「View」就 是查看系統的標簽）. 優先順序有下列集中，是按照從低到高順利排列的: V — Verbose (lowest priority) D — Debug I — Info W — Warning E — Error F — Fatal S — Silent (highest priority, on which nothing is ever printed) 在運行logcat的時候在前兩列的信息中你就可以看到 logcat 的標簽列表和優先順序別,它是這樣標出的:<priority>/<tag> . 下面是一個logcat輸出的例子,它的優先順序就似乎I,標簽 就是ActivityManage: I/ActivityManager( 585): Starting activity: Intent { action=android.intent.action...} 為了讓日誌輸出能體現管理的級別,你還可以用過濾器來控制日誌輸出,過濾器可以幫助你描述 系統的標簽等級. 過濾器語句按照下面的格式描tag:priority ... , tag 表 示是標簽,priority 是表示標簽的報告的最低等級. 從上面的tag的中可以得到日誌的優先順序. 你可以在過濾器中多次寫tag:priority . 這些說明都只到空白結束。下面有一個列子，例子表示支持所有的日誌信息，除了那些標簽 為」ActivityManager」和優先順序為」Info」以上的和標簽為」 MyApp」和優先順序為」 Debug」以上的。 小等級,優先權報告為tag. adb logcat ActivityManager:I MyApp:D *:S 上面表達式的最後的元素 *:S ,，是設置所有的標 簽為」silent」，所有日誌只顯示有」View」 and 「MyApp」的，用 *:S 的另一個用處是 能夠確保日誌輸出的時候是按照過濾器的說明限制的，也讓過濾器也作為一項輸出到日誌中. 下面的過濾語句指顯示優先順序為warning或更高的日誌信息: adb logcat *:W 如果你電腦上運行logcat ，相比在遠程adbshell端，你還可以 為環境變數ANDROID_LOG_TAGS :輸入一個參數來設置默認的過濾 export ANDROID_LOG_TAGS="ActivityManager:I MyApp:D *:S" 需要注意的是ANDROID_LOG_TAGS 過濾器如果 通過遠程shell運行logcat 或 用adb shell logcat 來 運行模擬器/設備不能輸出日誌. 控制 日誌輸出格式 日誌信息包括了許多元數據域包括標簽和優先順序。可以修改日誌的輸出格式，所以可以顯示出特 定的元數據域。可以通過 -v 選項得到格式化輸出日誌的相關信息. brief — Display priority/tag and PID of originating process (the default format). process — Display PID only. tag — Display the priority/tag only. thread — Display process:thread and priority/tag only. raw — Display the raw log message, with no other metadata fields. time — Display the date, invocation time, priority/tag, and PID of the originating process. long — Display all metadata fields and separate messages with a blank lines. 當啟動了logcat ，你可以通過-v 選 項來指定輸出格式: [adb] logcat [-v <format>] 下面是用 thread 來產生的日誌格式: adb logcat -v thread 需要注意的是你只能-v 選項來規定輸出格式 option. 查看 可用日誌緩沖區 Android日誌系統有循環緩沖區，並不是所有的日誌系統都有默認循環緩沖區。為了得到 日誌信息，你需要通過-b 選項來啟動logcat 。如果要使用循環緩沖區，你需要查看剩餘的 循環緩沖期: radio — 查看緩沖區的相關的信息. events — 查看和事件相關的的緩沖區. main — 查看主要的日誌緩沖區 -b 選項使用方法: [adb] logcat [-b <buffer>] 下面的例子表示怎麼查看日誌緩沖區包含radio 和 telephony信息: adb logcat -b radio 查看 stdout 和stderr 在默認狀態下，Android系統有stdout 和 stderr (System.out和System.err ) 輸出到/dev/null ， 在運行Dalvik VM的進程中，有一個系統可以備份日誌文件。在這種情況下，系統會用stdout 和stderr 和 優先順序 I.來記錄日誌信息 通過這種方法指定輸出的路徑，停止運行的模擬器/設備，然後通過用setprop 命 令遠程輸入日誌 $ adb shell stop $ adb shell setprop log.redirect-stdio true $ adb shell start 系統直到你關閉模擬器/設備前設置會一直保留，可以通過添加/data/local.prop 可 以使用模擬器/設備上的默認設置 Logcat命令列表 Option Description -b <buffer> 載入一個可使用的日誌緩沖區供查看，比如event 和radio . 默認值是main 。具體查看Viewing Alternative Log Buffers. -c 清楚屏幕上的日誌. -d 輸出日誌到屏幕上. -f <filename> 指定輸出日誌信息的<filename> ， 默認是stdout . -g 輸出指定的日誌緩沖區，輸出後退出. -n <count> 設置日誌的最大數目<count> .， 默認值是4，需要和 -r 選 項一起使用。 -r <kbytes> 每<kbytes> 時 輸出日誌，默認值為16，需要和-f 選 項一起使用. -s 設置默認的過濾級別為silent. -v <format> 設置日誌輸入格式，默認的是brief 格 式，要知道更多的支持的格式，參看Controlling Log Output Format .
⑤ android真機調試logcat文件在哪
在撥號界面輸入*#*#2846579#*#* ，然後系統會自動彈出一個菜單，選擇工程菜單，進入後，點擊背景設置，然後選擇log設置，將默認的好老正設置成開啟狀態，然後手機可能會自動重啟，如果不自動重啟，請手動重啟。重啟之後就行了。
http://stackoverflow.com/questions/6941710/unable-to-open-log-device-dev-log-main-no-such-file-or-directory
Dial this: *#*#2846579#*#*
Service menu will appear.
Go to 「ProjectMenu」 ->含氏 「Background Setting」 -> 「Log Setting」 //Log設置中，設置LOG開關為開。
Open 「Log switch」 and set it to ON. // 設置log級別為Verbose
Open 「Log level setting」 and set the log level you wish.
Reboot the phone.
之後重啟手機友悔就OK啦。
⑥ android調試輸出log列印信息到本地文件
在android開發中，Eclipse或者AndroidStudio調試時列印的信息很多，或者某些log字數超過Eclipse一行的字數限制，這個時候Eclipse就傻傻地把超出一行的log省略掉了，給我們開發中帶來不方便。或者在進行黑盒測試時，為了更加方便的找到錯誤信息，我們可以把log信息使用命令行查看或者直接輸出到本地。
下面是命令的格式：
⑦ 如何使用android中的logcat調試程序
1，開發方式，在eclipse中的windows中的show View中的other ，然後，打開other對話框，選擇android中稿掘模，找到logcat即可。在狀態欄或者散碧右側可以找到logcat的圖標。
2，使用方法，可以使用Log.i("exp",e.toString());這樣的方式來給自己的應用大bug信息。
3，然後，查看logcat中的tag，和text描述。就可以查鍵緩看到錯誤產生的原因了。
4，當然這只是最簡單的使用，一般調試信息非常的多，我們可能只是希望看到我們想看到信息，這個時候，可以使用filter過濾一下信息。選擇logcat的組面板上的+信息。
5，在這里我們可以對於tag賦值，然後查看使用到的log信息，這樣過濾到的信息，就是你正在調試的信息。
⑧ 2018-02-02小米手機調試AndroidStudio程序列印不出logcat
問題橋肢如下：手機連接正常。進程為24053。沒有dead，以前可以。
解決辦法：
由於手機關閉了日誌記錄器緩沖區大小。如果日誌太多，那就設置大一點敏返世緩沖區世慎。
問題解決！
⑨ android 中我在代碼中為了調試寫了system.out.print()輸出項，但是在控制台的什麼地方可以查看到這個輸出
1、進入android中，會看到圖示的system.out.print()輸褲肢出項。
⑩ 手機調試Android程序出異常時不列印堆棧信息
列印堆棧是調試的常用方法，一般在系統異常時，我們可以將異常情況下的堆棧列印出來，這樣十分方便錯誤查找。實際上還有另外一個非常有用的功能：分析代碼的行為。android代碼太過龐大復雜了，完全的靜態分析經常是無從下手，因此通過列印堆棧的動態分析也十分必要。
Android列印堆棧的方法，簡單歸類一下
1. zygote的堆棧mp
實際上這個可以同時mp java線程及native線程的堆棧，對於java線程，java堆棧和native堆棧都可以得到。
使用方法很簡單，直接在adb shell或串口中輸入：
[plain] view plain
kill -3 <pid>
輸出的trace會保存在 /data/anr/traces.txt文件中。這個需要注意，如果沒有 /data/anr/這個目錄或/data/anr/traces.txt這個文件，需要手工創建一下，並設置好讀寫許可權。
如果需要在代碼中，更容易控制堆棧的輸出時機，可以用以下命令獲取zygote的core mp:
[java] view plain
Process.sendSignal(pid, Process.SIGNAL_QUIT);
原理和命令行是一樣的。
不過需要注意兩點：
adb shell可能會沒有許可權，需要root。
android 4.2中關閉了native thread的堆棧列印，詳見 dalvik/vm/Thread.cpp的mpNativeThread方法：
[cpp] view plain
dvmPrintDebugMessage(target,
"\"%s\" sysTid=%d nice=%d sched=%d/%d cgrp=%s\n",
name, tid, getpriority(PRIO_PROCESS, tid),
schedStats.policy, schedStats.priority, schedStats.group);
mpSchedStat(target, tid);
// Temporarily disabled collecting native stacks from non-Dalvik
// threads because sometimes they misbehave.
//dvmDumpNativeStack(target, tid);
Native堆棧的列印被關掉了！不過對於大多數情況，可以直接將這個注釋打開。
2. debuggerd的堆棧mp
debuggerd是android的一個daemon進程，負責在進程異常出錯時，將進程的運行時信息mp出來供分析。debuggerd生 成的coremp數據是以文本形式呈現，被保存在 /data/tombstone/ 目錄下(名字取的也很形象，tombstone是墓碑的意思)，共可保存10個文件，當超過10個時，會覆蓋重寫最早生成的文件。從4.2版本開 始，debuggerd同時也是一個實用工具：可以在不中斷進程執行的情況下列印當前進程的native堆棧。使用方法是:
[plain] view plain
debuggerd -b <pid>
這可以協助我們分析進程執行行為，但最最有用的地方是：它可以非常簡單的定位到native進程中鎖死或錯誤邏輯引起的死循環的代碼位置。
3. java代碼中列印堆棧
Java代碼列印堆棧比較簡單， 堆棧信息獲取和輸出，都可以通過Throwable類的方法實現。目前通用的做法是在java進程出現需要注意的異常時，列印堆棧，然後再決定退出或挽救。通常的方法是使用exception的printStackTrace()方法：
[java] view plain
try {
...
} catch (RemoteException e) {
e.printStackTrace();
...
}
當然也可以只列印堆棧不退出，這樣就比較方便分析代碼的動態運行情況。Java代碼中插入堆棧列印的方法如下：
[java] view plain
Log.d(TAG,Log.getStackTraceString(new Throwable()));
4. C++代碼中列印堆棧
C++也是支持異常處理的，異常處理庫中，已經包含了獲取backtrace的介面，Android也是利用這個介面來列印堆棧信息的。在Android的C++中，已經集成了一個工具類CallStack，在libutils.so中。使用方法：
[cpp] view plain
#include <utils/CallStack.h>
...
CallStack stack;
stack.update();
stack.mp();
使用方式比較簡單。目前Andoid4.2版本已經將相關信息解析的很到位，符號表查找，demangle，偏移位置校正都做好了。
[plain] view plain
5. C代碼中列印堆棧
C代碼，尤其是底層C庫，想要看到調用的堆棧信息，還是比較麻煩的。 CallStack肯定是不能用，一是因為其實C++寫的，需要重新封裝才能在C中使用，二是底層庫反調上層庫的函數，會造成鏈接器循環依賴而無法鏈接。 不過也不是沒有辦法，可以通過android工具類CallStack實現中使用的unwind調用及符號解析函數來處理。
這里需要注意的是，為解決鏈接問題，最好使用dlopen方式，查找需要用到的介面再直接調用，這樣會比較簡單。如下為相關的實現代碼，只需要在要 列印的文件中插入此部分代碼，然後調用getCallStack()即可，無需包含太多的頭文件和修改Android.mk文件：
[cpp] view plain
#define MAX_DEPTH 31
#define MAX_BACKTRACE_LINE_LENGTH 800
#define PATH "/system/lib/libcorkscrew.so"
typedef ssize_t (*unwindFn)(backtrace_frame_t*, size_t, size_t);
typedef void (*unwindSymbFn)(const backtrace_frame_t*, size_t, backtrace_symbol_t*);
typedef void (*unwindSymbFreeFn)(backtrace_symbol_t*, size_t);
static void *gHandle = NULL;
static int getCallStack(void){
ssize_t i = 0;
ssize_t result = 0;
ssize_t count;
backtrace_frame_t mStack[MAX_DEPTH];
backtrace_symbol_t symbols[MAX_DEPTH];
unwindFn unwind_backtrace = NULL;
unwindSymbFn get_backtrace_symbols = NULL;
unwindSymbFreeFn free_backtrace_symbols = NULL;
// open the so.
if(gHandle == NULL) gHandle = dlopen(PATH, RTLD_NOW);
// get the interface for unwind and symbol analyse
if(gHandle != NULL) unwind_backtrace = (unwindFn)dlsym(gHandle, "unwind_backtrace");
if(gHandle != NULL) get_backtrace_symbols = (unwindSymbFn)dlsym(gHandle, "get_backtrace_symbols");
if(gHandle != NULL) free_backtrace_symbols = (unwindSymbFreeFn)dlsym(gHandle, "free_backtrace_symbols");
if(!gHandle ||!unwind_backtrace ||!get_backtrace_symbols || !free_backtrace_symbols ){
ALOGE("Error! cannot get unwind info: handle:%p %p %p %p",
gHandle, unwind_backtrace, get_backtrace_symbols, free_backtrace_symbols );
return result;
}
count= unwind_backtrace(mStack, 1, MAX_DEPTH);
get_backtrace_symbols(mStack, count, symbols);
for (i = 0; i < count; i++) {
char line[MAX_BACKTRACE_LINE_LENGTH];
const char* mapName = symbols[i].map_name ? symbols[i].map_name : "<unknown>";
const char* symbolName =symbols[i].demangled_name ? symbols[i].demangled_name : symbols[i].symbol_name;
size_t fieldWidth = (MAX_BACKTRACE_LINE_LENGTH - 80) / 2;
if (symbolName) {
uint32_t pc_offset = symbols[i].relative_pc - symbols[i].relative_symbol_addr;
if (pc_offset) {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s+%u)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName, pc_offset);
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName);
}
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s",
i, symbols[i].relative_pc, fieldWidth, mapName);
}
ALOGD("%s", line);
}
free_backtrace_symbols(symbols, count);
return result;
}
對sched_policy.c的堆棧調用分析如下,注意具體是否要列印，在哪裡列印，還可以通過pid、uid、property等來控制一下，這樣就不會被淹死在trace的汪洋大海中。
[plain] view plain
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00010e82 /system/lib/libutils.so (androidSetThreadPriority+61)
D/SchedPolicy( 1350): #03 pc 00068104 /system/lib/libandroid_runtime.so (android_os_Process_setThreadPriority(_JNIEnv*, _jobject*, int, int)+7)
D/SchedPolicy( 1350): #04 pc 0001e510 /system/lib/libdvm.so (dvmPlatformInvoke+112)
D/SchedPolicy( 1350): #05 pc 0004d6aa /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+417)
D/SchedPolicy( 1350): #06 pc 00027920 /system/lib/libdvm.so
D/SchedPolicy( 1350): #07 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
D/SchedPolicy( 1350): #08 pc 00060c30 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+271)
D/SchedPolicy( 1350): #09 pc 0004cd34 /system/lib/libdvm.so
D/SchedPolicy( 1350): #10 pc 00049382 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #11 pc 00065e52 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #12 pc 0001435e /system/lib/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+57)
D/SchedPolicy( 1350): #13 pc 00016f5a /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+513)
D/SchedPolicy( 1350): #14 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #15 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #16 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #17 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #18 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #19 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #20 pc 0000dac4 /system/lib/libc.so (pthread_create+160)
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00016f26 /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+461)
D/SchedPolicy( 1350): #03 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #04 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #05 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #06 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #07 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #08 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #09 pc 0000dac4 /system/lib/libc.so (pthread_create+160)
6. 其它堆棧信息查詢