手機traces文件夾是什麼

A. 手機里有一個traces文件夾，是什麼文件

應用程序錯誤信息反饋文件夾。
當應用程序發生ANR
(Application
is
Not
Responding)
錯誤時，系統會自動將問題點的code
stack
list
寫在這個文件內，你直接用cat
命令就可以看它的內容。

B. 如何讀懂和分析android的logcat以及stack traces

一般在平時工作中，基本上很多代碼可以在eclipse+ndk進行調試，但如果需要用到具體的硬體設備，如媒體播放設備無法模擬的情況下，只能上硬體(盒子或手機)上進行調試。此時唯一的調試手段就是logcat產生log信息進行分析問題了。
什麼時候會有Log文件的產生 ?一般在如下幾種情況會產生log文件 。
1、程序異常退出 uncaused exception
2、程序強制關閉 Force Closed (簡稱FC)
3、程序無響應 Application No Response(簡稱ANR),一般主線程超過5秒么有處理就會ANR
4、手動生成
進入控制台輸入：logcat命令即可進行輸出
第一部分
1、分析工具介紹
a、cat /proc/meminfo 顯示基本的內存信息
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 285184 kB
MemFree: 106360 kB
Buffers: 0 kB
Cached: 60036 kB
SwapCached: 0 kB
Active: 98160 kB
Inactive: 49100 kB
Active(anon): 87260 kB
Inactive(anon): 288 kB
Active(file): 10900 kB
Inactive(file): 48812 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 87240 kB
Mapped: 26500 kB
Shmem: 324 kB
Slab: 13340 kB
SReclaimable: 1672 kB
SUnreclaim: 11668 kB
KernelStack: 2160 kB
PageTables: 5600 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 142592 kB
Committed_AS: 1065600 kB
VmallocTotal: 417792 kB
VmallocUsed: 137700 kB
VmallocChunk: 254980 kB
重點關注這下面幾個值：
MemTotal: 285184 kB //總計物理內存的大小
MemFree: 106360 kB //可用內存有多少
Buffers: 0 kB //磁碟緩存內存的大小
Cached: 60036 kB
# free
free
total used free shared buffers
Mem: 285184 178884 106300 0 0
Swap: 0 0 0
Total: 285184 178884 106300
在linux中有這么一種思想，內存不用白不用，因此它盡可能的cache和buffer一些數據，以方便下次使用。
但實際上這些內存也是可以立刻拿來使用的。
所以空閑內存=free+buffers+cached=total-used
還有幾個命令可使用：
/proc/meminfo 機器的內存使用信息
/proc/pid/maps pid為進程號，顯示當前進程所佔用的虛擬地址。
/proc/pid/statm 進程所佔用的內存
b、查看進程信息
------ CPU INFO (top -n 1 -d 1 -m 30 -t) ------
能夠實時顯示系統中各個進程的資源佔用狀況，類似於 Windows 的任務管理器
c、android提供的一些操作工具
------ PROCRANK (procrank) ------
------ PROCMEM (procmem) ------
------ SHOWMAP (showmap) ------
... 就不一一列舉了，有興趣的朋友可以去看看
這此工具的代碼位於android的 /system/extras
d、虛擬內存的查看工具
------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
------ VMALLOC INFO (/proc/vmallocinfo) ------
2、時間信息,也是我們主要分析的信息
格式如下：
------ SYSTEM LOG (logcat -b system -v time -d *:v) ------
$:logcat -b system -v time -d *:v
01-02 08:00:02.570 I/SystemServer( 957): Notification Manager
01-02 08:00:02.570 I/SystemServer( 957): Device Storage Monitor
01-02 08:00:02.580 I/SystemServer( 957): Location Manager
01-02 08:00:02.580 I/SystemServer( 957): Search Service
01-02 08:00:02.590 I/SystemServer( 957): DropBox Service
01-02 08:00:02.590 I/SystemServer( 957): Wallpaper Service
3、虛擬機信息,包括進程的,線程的跟蹤信息,這是用來跟蹤進程和線程具體點的好地方 。
------ VM TRACES JUST NOW (/data/anr/traces.txt.bugreport: 2011-01-15 16:49:02) ------
------ VM TRACES AT LAST ANR (/data/anr/traces.txt: 2011-01-15 16:49:02) ------
格式如下 ：
----- pid 1516 at 1970-01-02 08:03:07 -----
Cmd line: com.ipanel.join.appstore
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x4001f188 self=0xd028
| sysTid=1516 nice=0 sched=3/0 cgrp=[fopen-error:2] handle=-1345017744
第二部分
如何分析log信息
1、查找錯誤信息的關鍵字眼
"error" "failxx" "E/" 等的錯誤信息
將這些問題先行解決掉
2、動態庫死機
查看類似的「Build fingerprint:」這些關鍵字
I/DEBUG ( 692): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 692): Build fingerprint: 'generic/generic/generic:2.3.1/GRH78/eng.userdev-rd6-input.20120221.113348:eng/test-keys'
I/DEBUG ( 692): pid: 694, tid: 694 >>> /system/bin/mediaserver <<<
I/DEBUG ( 692): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000input mole init -->
010
對於這此信息，可以查看動態庫的分析：
http://blog.csdn.net/andyhuabing/article/details/7074979
3、解決java拋異常的問題解決
E/UsbObserver( 957): java.lang.NullPointerException
E/UsbObserver( 957): at com.android.server.UsbObserver.init(UsbObserver.java:131)
E/UsbObserver( 957): at com.android.server.UsbObserver.<init>(UsbObserver.java:65)
E/UsbObserver( 957): at com.android.server.ServerThread.run(SystemServer.java:419)
I/SystemServer( 957): UI Mode Manager Service
這個直接找到java代碼，分析其實現即可解決
4、ANR問題
搜索「ANR」關鍵詞，快速定位到關鍵事件信息 。
定位到關鍵的事件信息如下:
I/dalvikvm( 1014): Wrote stack traces to '/data/anr/traces.txt'
I/Process ( 957): Sending signal. PID: 1124 SIG: 9

指定哪個java包出問題
E/ActivityManager( 957): ANR in com.ipanel.join.appstore
進程號為957發生了如下錯誤：com.ipanel.join.appstore 包下面 Broadcast問題
ANR原因：
E/ActivityManager( 957): Reason: Broadcast of Intent { act=android.appwidget.action.APPWIDGET_UPDATE cmp=com.ipanel.join.appstore/.widget.SmallWidget1 (has extras) }
這是ANR的堆棧調用文件
I/dalvikvm( 1014): Wrote stack traces to '/data/anr/traces.txt'
通過上面的log信息分析，應該是接收一個廣播消息時超時了
我們再分析虛擬機信息 ，打開/data/anr/traces.txt,可有通過adb pull /data/anr/traces.txt .
這里每一段都是一個線程 ，當然我們還是看線程號為1的主線程了。通過分析發現關鍵問題是這樣：
搜索「DALVIK THREADS」關鍵詞，快速定位到本應用程序的虛擬機信息日誌
----- pid 1516 at 1970-01-02 08:03:07 -----
Cmd line: com.ipanel.join.appstore
DALVIK THREADS:
。。。
at com.ipanel.join.appstore.widget.AbsSmallWidget.getRemoteViews(AbsSmallWidget.java:56)
其實從這句話：
at org.apache.harmony.luni.platform.OSNetworkSystem.connect(Native Method)
基本上確認是 socket ->connect 連接超時了，導致主線程5s內沒有響應從而產生ANR錯誤。默認的connect連接timeout時間是75s
其實解決辦法就是利用非阻塞方式進行連接即可。
從CPU佔用率上也可以看出是在kernel中執行堵塞住了
E/ActivityManager( 957): 75% TOTAL: 4.7% user + 70% kernel
5、執行DexOpt錯誤
W/dalvikvm( 1803): DexOpt: --- END 'SettingsProvider.apk' --- status=0x000a, process failed
E/dalvikvm( 1803): Unable to extract+optimize DEX from '/system/app/SettingsProvider.apk'
。。。。android.app.ActivityThread.installProvider(ActivityThread.java:3557)

E/SystemServer( 1803): at android.app.ActivityThread.getProvider(ActivityThread.java:3356)
從上面的列印看，是在解壓或優化extract+optimize DEX的apk文件時出錯了
1、沒有出現magic number錯誤，這個原因與原子操作無關(這是一快速的加鎖和解鎖的輕量級操作函數)
2、執行dexopt出錯
查明是伺服器硬碟沒空間了，導致引導文件系統的時候沒有空間進行解壓而失敗
6、系統啟動後默認其妙或隨機死機情況
出現這種錯誤：
12-01 08:11:56.027: WARN/SharedBufferStack(312): waitForCondition(LockCondition) timed out (identity=19, status=0). CPU may be pegged. trying again.
12-01 08:11:57.315: WARN/SharedBufferStack(312): waitForCondition(LockCondition) timed out (identity=19, status=0). CPU may be pegged. trying again.
12-01 08:11:59.318: WARN/SharedBufferStack(312): waitForCondition(LockCondition) timed out (identity=19, status=0). CPU may be pegged. trying again.
12-01 08:12:03.332: WARN/SharedBufferStack(312): waitForCondition(LockCondition) timed out (identity=19, status=0). CPU may be pegged. trying again.
12-01 08:12:05.329: WARN/SharedBufferStack(312): waitForCondition(LockCondition) timed out (identity=19, status=0). CPU may be pegged. trying again.
12-01 08:12:07.216: WARN/KeyCharacterMap(312): No keyboard for id 0
12-01 08:12:07.216: WARN/KeyCharacterMap(312): Using default keymap: /system/usr/keychars/qwerty.kcm.bin

C. 夜神安卓模擬器啟動游戲停止運行怎麼回事

問題的存在是具有多面性的哦，但是為了更好的幫助你，

請按照如下操作，操作後把生成文件傳給聯系的官方客服人員（Q群：385408454）。

①右鍵模擬器快捷方式，打開文件位置，進入到模擬器安裝文件夾。
②在模擬器安裝文件夾找到debugReport.bat文件雙擊運行，運行後會提示該文件大概運行3分鍾，運行完畢，文件會提示按任意鍵退出，此時點擊任意按鍵退出該界面。
③在當前文件夾中找到traces.txt文件，發送給客服人員，並把報錯圖片一同發送給客服人員即可。

D. android backtrace 怎麼確定oat文件的出錯位置

列印堆棧是調試的常用方法，一般在系統異常時，我們可以將異常情況下的堆棧列印出來，這樣十分方便錯誤查找。實際上還有另外一個非常有用的功能：分析代碼的行為。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);

E. C盤里Intel_Bluetooth_Traces是什麼文件夾，佔用空間會原來越大

這個好像是某個驅動程序的文件，你可以打開360安全衛士，點擊功能大全，找到「系統盤瘦身」工具，它是一款專門的C盤清理工具，安全方便

F. Android系統的系統日誌有哪幾個文件,這些文件中包含什麼內容

手機的android log（main_log、events_log、kernel_log），mainlog記錄手機android上層app以及framework相關活動的log，比如app列印的log。

eventslog主要是ActivityManager、powerManager等相關的log；Kernellog則主要是驅動相關的log。

Modem log，主要是通話相關的，比如信號強弱、連接網路等。netlog，查看網路鏈接情況，抓取網路包等。其它有data/anr 目錄下的traces/tombstones等，分析死機、重啟。

mainlog，查看應用申請什麼許可權，一般不會開放。

(6)手機traces文件夾是什麼擴展閱讀：

系統日誌的價值

系統日誌策略可以在故障剛剛發生時就向你發送警告信息，系統日誌幫助你在最短的時間內發現問題。

系統日誌是一種非常關鍵的組件，因為系統日誌可以讓你充分了解自己的環境。這種系統日誌信息對於決定故障的根本原因或者縮小系統攻擊范圍來說是非常關鍵的，因為系統日誌可以讓你了解故障或者襲擊發生之前的所有事件。

為虛擬化環境制定一套良好的系統日誌策略也是至關重要的，因為系統日誌需要和許多不同的外部組件進行關聯。良好的系統日誌可以防止你從錯誤的角度分析問題，避免浪費寶貴的排錯時間。

另外一種原因是藉助於系統日誌，管理員很有可能會發現一些之前從未意識到的問題，在幾乎所有剛剛部署系統日誌的環境當中。

使用系統日誌產品當中包含的其他特性，包括向監控團隊自動發送報警通知等功能。系統日誌基於警報類型或者准確的警報消息，系統日誌可以通過觸發特定操作來完成。

系統日誌通過簡單地設定這些警報，你將會在自己的環境中處於更加主動的位置，因為你可以在事故變得更加嚴重之前得到通知。