プロジェクトをデバッグする
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
ネイティブ クラッシュをデバッグする
ネイティブ クラッシュのダンプや tombstone の基礎知識については、ネイティブ Android プラットフォーム コードをデバッグするをご覧ください。
一般的なクラッシュ タイプの一覧とその調査方法については、ネイティブ クラッシュを診断するをご覧ください。
ndk-stack ツールは、クラッシュのシンボル化に役立ちます。一般的なアプリのデバッグのドキュメントの説明にあるように、Android Studio でクラッシュをデバッグできます。コマンドラインを使用する場合は、ndk-gdb を使用すると、シェルから gdb
または lldb
をアタッチできます。
アプリが Tombstone トレースに直接アクセスできるようにする
Android 12(API レベル 31)以降では、ApplicationExitInfo.getTraceInputStream()
メソッドからアプリのネイティブ クラッシュ Tombstone にプロトコル バッファとしてアクセスできます。プロトコル バッファは、こちらのスキーマを使用してシリアル化されます。これまでは、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);
}
}
ネイティブ メモリの問題をデバッグする
AddressSanitizer(HWASan / ASan)
HWAddressSanitizer(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) をサポートしています。
malloc_info
機能は、Android 6.0(Marshmallow)以降で使用できます。その XML スキーマは、Bionic の malloc.h ヘッダーに記載されています。
プロファイリング
ネイティブ コードの CPU プロファイリングには、Simpleperf を使用できます。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-27 UTC。"],[],[],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)."]]