為專案偵錯
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
針對原生程式碼錯誤進行偵錯
如果覺得原生程式碼當機傾印檔或空值標記難以理解,可參閱「Android 平台原生程式碼偵錯」,瞭解入門概念。
如需更完整的常見當機類型目錄及調查方法,請參閱「診斷原生程式碼當機」。
ndk-stack 工具可協助您針對錯誤進行符號化處理。
在 Android Studio 偵錯時,可以按照一般說明文件「為應用程式偵錯」所述的方法操作。如果想使用指令列,可以使用 ndk-gdb 從殼層附加 gdb
或 lldb
。
允許應用程式直接存取空值標記追蹤記錄
從 Android 12 (API 級別 31) 開始,您可以透過 ApplicationExitInfo.getTraceInputStream()
方法以通訊協定緩衝區形式存取應用程式的原生程式碼錯誤空值標記。通訊協定緩衝區使用這個結構定義進行序列化。
在此之前,您只能透過 Android Debug Bridge (ADB) 存取這項資訊。
以下範例說明如何在應用程式中執行這項功能:
ActivityManager activityManager: ActivityManager = getSystemService(Context.ACTIVITY_SERVICE);
MutableList<ApplicationExitInfo> exitReasons = activityManager.getHistoricalProcessExitReasons(/* packageName = */ null, /* pid = */ 0, /* maxNum = */ 5);
for (ApplicationExitInfo aei: exitReasons) {
if (aei.getReason() == REASON_CRASH_NATIVE) {
// Get the tombstone input stream.
InputStream trace = aei.getTraceInputStream();
// The tombstone parser built with protoc uses the tombstone schema, then parses the trace.
Tombstone tombstone = Tombstone.parseFrom(trace);
}
}
對原生記憶體問題進行偵錯
Address Sanitizer (HWASan/ASan)
HWAddress Sanitizer (HWASan) 和 Address Sanitizer (ASan) 與 Valgrind 相似,但在 Android 上的速度明顯更快,表現也更佳。
以下是針對 Android 記憶體錯誤進行偵錯的最佳選項。
Malloc 偵錯
如要全面瞭解 C 程式庫內建的原生記憶體問題偵錯選項,請參閱「Malloc 偵錯」和「使用 libc 回呼追蹤原生記憶體」。
Malloc 掛鉤
如要自行建構工具,Android 的 libc 也可攔截在程式執行期間發生的所有配置/釋放呼叫。如需相關使用操作說明,請參閱 malloc_hooks 說明文件。
Malloc 統計資料
Android 支援對 <malloc.h>
進行 mallinfo(3) 和 malloc_info(3) 擴充。
Android 6.0 (Marshmallow) 及以上版本支援 malloc_info
功能,其 XML 架構記錄在 Bionic 的 malloc.h 標頭中。
剖析
如需對原生程式碼進行 CPU 剖析,您可以使用 Simpleperf。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[null,null,["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],null,["# Debug your project\n\nDebug native crashes\n--------------------\n\nIf you're struggling to understand a native crash dump or tombstone,\n[Debugging Native Android Platform Code](https://source.android.com/devices/tech/debug/index.html)\nis a good introduction.\n\nFor a fuller catalog of common types of crash and how to investigate them, see\n[Diagnosing Native Crashes](https://source.android.com/devices/tech/debug/native-crash).\n\nThe [ndk-stack](/ndk/guides/ndk-stack) tool can help symbolize your crashes.\nYou can debug crashes in Android Studio as described in the general\n[Debug your app](/studio/debug) documentation. If you prefer to use the\ncommand-line, [ndk-gdb](/ndk/guides/ndk-gdb) lets you attach either `gdb` or\n`lldb` from your shell.\n\n### Provide apps direct access to tombstone traces\n\nStarting in Android 12 (API level 31), you can access your app's native crash\ntombstone as a\n[protocol buffer](https://developers.google.com/protocol-buffers/) through the\n[`ApplicationExitInfo.getTraceInputStream()`](/reference/android/app/ApplicationExitInfo#getTraceInputStream())\nmethod. The protocol buffer is serialized using [this schema](https://android.googlesource.com/platform/system/core/+/refs/heads/main/debuggerd/proto/tombstone.proto).\nPreviously, the only way to get access to this information was through the\n[Android Debug Bridge](/studio/command-line/adb) (adb).\n\nHere's an example of how to implement this in your app: \n\n ActivityManager activityManager: ActivityManager = getSystemService(Context.ACTIVITY_SERVICE);\n MutableList\u003cApplicationExitInfo\u003e exitReasons = activityManager.getHistoricalProcessExitReasons(/* packageName = */ null, /* pid = */ 0, /* maxNum = */ 5);\n for (ApplicationExitInfo aei: exitReasons) {\n if (aei.getReason() == REASON_CRASH_NATIVE) {\n // Get the tombstone input stream.\n InputStream trace = aei.getTraceInputStream();\n // The tombstone parser built with protoc uses the tombstone schema, then parses the trace.\n Tombstone tombstone = Tombstone.parseFrom(trace);\n }\n }\n\nDebug native memory issues\n--------------------------\n\n### Address Sanitizer (HWASan/ASan)\n\n[HWAddress Sanitizer](/ndk/guides/hwasan) (HWASan) and\n[Address Sanitizer](/ndk/guides/asan) (ASan) are similar to Valgrind, but\nsignificantly faster and much better supported on Android.\n\nThese are your best option for debugging memory errors on Android.\n\n### Malloc debug\n\nSee\n[Malloc Debug](https://android.googlesource.com/platform/bionic/+/main/libc/malloc_debug/README.md)\nand\n[Native Memory Tracking using libc Callbacks](https://android.googlesource.com/platform/bionic/+/main/libc/malloc_debug/README_api.md)\nfor a thorough description of the C library's built-in options for debugging\nnative memory issues.\n\n### Malloc hooks\n\nIf you want to build your own tools, Android's libc also supports intercepting\nall allocation/free calls that happen during program execution. See the\n[malloc_hooks documentation](https://android.googlesource.com/platform/bionic/+/main/libc/malloc_hooks/README.md)\nfor usage instructions.\n\n### Malloc statistics\n\nAndroid supports the\n[mallinfo(3)](http://man7.org/linux/man-pages/man3/mallinfo.3.html)\nand\n[malloc_info(3)](http://man7.org/linux/man-pages/man3/malloc_info.3.html)\nextensions to `\u003cmalloc.h\u003e`.\n\nThe `malloc_info` functionality is available in Android 6.0 (Marshmallow) and\nhigher and its XML schema is documented in Bionic's\n[malloc.h](https://android.googlesource.com/platform/bionic/+/main/libc/include/malloc.h)\nheader.\n\nProfiling\n---------\n\nFor CPU profiling of native code, you can use [Simpleperf](/ndk/guides/simpleperf)."]]