In diesem Abschnitt werden nützliche Tools und verwandte Befehle zum Debuggen, Verfolgen und Profilieren von nativem Android-Plattformcode bei der Entwicklung von Funktionen auf Plattformebene zusammengefasst.
Hinweis: Auf den Seiten in diesem Abschnitt und an anderen Stellen dieser Website wird die Verwendung von adb
in Verbindung mit dem Argument setprop
empfohlen, um bestimmte Aspekte von Android zu debuggen. In Android 7.x und niedriger galt für Eigenschaftsnamen eine Längenbeschränkung von 32 Zeichen. Das bedeutete, dass zum Erstellen einer Wrap-Eigenschaft mit dem Namen der App der Name passend gekürzt werden musste. In Android 8.0 und höher ist dieser Grenzwert viel höher und sollte keine Kürzung erfordern.
Auf dieser Seite werden die Grundlagen rund um Absturz-Dumps in der Logcat-Ausgabe behandelt. Auf anderen Seiten finden Sie weitaus detailliertere Informationen zur Diagnose nativer Abstürze , zur Erkundung von Systemdiensten mit dumpsys
, zur Anzeige der nativen Speicher- , Netzwerk- und RAM- Nutzung, zur Verwendung von AddressSanitizer zur Erkennung von Speicherfehlern in nativem Code, zur Bewertung von Leistungsproblemen (einschließlich systrace ) und zur Verwendung von Debuggern .
Crash-Dumps und Grabsteine
Wenn eine dynamisch verknüpfte ausführbare Datei gestartet wird, werden mehrere Signalhandler registriert, die im Falle eines Absturzes bewirken, dass ein grundlegender Absturzspeicherauszug in logcat und eine detailliertere Tombstone- Datei in /data/tombstones/
geschrieben wird. Der Tombstone ist eine Datei mit zusätzlichen Daten über den abgestürzten Prozess. Insbesondere enthält es Stack-Traces für alle Threads im abstürzenden Prozess (nicht nur den Thread, der das Signal empfangen hat), eine vollständige Speicherzuordnung und eine Liste aller offenen Dateideskriptoren.
Vor Android 8.0 wurden Abstürze von den Daemons debuggerd
und debuggerd64
behandelt. In Android 8.0 und höher werden crash_dump32
und crash_dump64
nach Bedarf erzeugt.
Der Crash-Dumper kann nur dann angehängt werden, wenn nichts anderes bereits angehängt ist. Dies bedeutet, dass die Verwendung von Tools wie strace
oder lldb
das Auftreten von Crash-Dumps verhindert.
Beispielausgabe (ohne Zeitstempel und überflüssige Informationen):
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'Android/aosp_angler/angler:7.1.1/NYC/enh12211018:eng/test-keys' Revision: '0' ABI: 'arm' pid: 17946, tid: 17949, name: crasher >>> crasher <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc r0 0000000c r1 00000000 r2 00000000 r3 00000000 r4 00000000 r5 0000000c r6 eccdd920 r7 00000078 r8 0000461a r9 ffc78c19 sl ab209441 fp fffff924 ip ed01b834 sp eccdd800 lr ecfa9a1f pc ecfd693e cpsr 600e0030 backtrace: #00 pc 0004793e /system/lib/libc.so (pthread_mutex_lock+1) #01 pc 0001aa1b /system/lib/libc.so (readdir+10) #02 pc 00001b91 /system/xbin/crasher (readdir_null+20) #03 pc 0000184b /system/xbin/crasher (do_action+978) #04 pc 00001459 /system/xbin/crasher (thread_callback+24) #05 pc 00047317 /system/lib/libc.so (_ZL15__pthread_startPv+22) #06 pc 0001a7e5 /system/lib/libc.so (__start_thread+34) Tombstone written to: /data/tombstones/tombstone_06
Die letzte Ausgabezeile gibt die Position des vollständigen Tombstones auf der Festplatte an.
Wenn Sie über die entpackten Binärdateien verfügen, können Sie eine detailliertere Abwicklung mit Informationen zur Zeilennummer erhalten, indem Sie den Stapel in development/scripts/stack
einfügen:
development/scripts/stack
Tipp: Der Einfachheit halber: Wenn Sie lunch
ausgeführt haben, befindet sich stack
bereits in Ihrem $PATH
, sodass Sie nicht den vollständigen Pfad angeben müssen.
Beispielausgabe (basierend auf der Logcat-Ausgabe oben):
Reading native crash info from stdin 03-02 23:53:49.477 17951 17951 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 03-02 23:53:49.477 17951 17951 F DEBUG : Build fingerprint: 'Android/aosp_angler/angler:7.1.1/NYC/enh12211018:eng/test-keys' 03-02 23:53:49.477 17951 17951 F DEBUG : Revision: '0' 03-02 23:53:49.477 17951 17951 F DEBUG : ABI: 'arm' 03-02 23:53:49.478 17951 17951 F DEBUG : pid: 17946, tid: 17949, name: crasher >>> crasher <<< 03-02 23:53:49.478 17951 17951 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc 03-02 23:53:49.478 17951 17951 F DEBUG : r0 0000000c r1 00000000 r2 00000000 r3 00000000 03-02 23:53:49.478 17951 17951 F DEBUG : r4 00000000 r5 0000000c r6 eccdd920 r7 00000078 03-02 23:53:49.478 17951 17951 F DEBUG : r8 0000461a r9 ffc78c19 sl ab209441 fp fffff924 03-02 23:53:49.478 17951 17951 F DEBUG : ip ed01b834 sp eccdd800 lr ecfa9a1f pc ecfd693e cpsr 600e0030 03-02 23:53:49.491 17951 17951 F DEBUG : 03-02 23:53:49.491 17951 17951 F DEBUG : backtrace: 03-02 23:53:49.492 17951 17951 F DEBUG : #00 pc 0004793e /system/lib/libc.so (pthread_mutex_lock+1) 03-02 23:53:49.492 17951 17951 F DEBUG : #01 pc 0001aa1b /system/lib/libc.so (readdir+10) 03-02 23:53:49.492 17951 17951 F DEBUG : #02 pc 00001b91 /system/xbin/crasher (readdir_null+20) 03-02 23:53:49.492 17951 17951 F DEBUG : #03 pc 0000184b /system/xbin/crasher (do_action+978) 03-02 23:53:49.492 17951 17951 F DEBUG : #04 pc 00001459 /system/xbin/crasher (thread_callback+24) 03-02 23:53:49.492 17951 17951 F DEBUG : #05 pc 00047317 /system/lib/libc.so (_ZL15__pthread_startPv+22) 03-02 23:53:49.492 17951 17951 F DEBUG : #06 pc 0001a7e5 /system/lib/libc.so (__start_thread+34) 03-02 23:53:49.492 17951 17951 F DEBUG : Tombstone written to: /data/tombstones/tombstone_06 Reading symbols from /huge-ssd/aosp-arm64/out/target/product/angler/symbols Revision: '0' pid: 17946, tid: 17949, name: crasher >>> crasher <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc r0 0000000c r1 00000000 r2 00000000 r3 00000000 r4 00000000 r5 0000000c r6 eccdd920 r7 00000078 r8 0000461a r9 ffc78c19 sl ab209441 fp fffff924 ip ed01b834 sp eccdd800 lr ecfa9a1f pc ecfd693e cpsr 600e0030 Using arm toolchain from: /huge-ssd/aosp-arm64/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/ Stack Trace: RELADDR FUNCTION FILE:LINE 0004793e pthread_mutex_lock+2 bionic/libc/bionic/pthread_mutex.cpp:515 v------> ScopedPthreadMutexLocker bionic/libc/private/ScopedPthreadMutexLocker.h:27 0001aa1b readdir+10 bionic/libc/bionic/dirent.cpp:120 00001b91 readdir_null+20 system/core/debuggerd/crasher.cpp:131 0000184b do_action+978 system/core/debuggerd/crasher.cpp:228 00001459 thread_callback+24 system/core/debuggerd/crasher.cpp:90 00047317 __pthread_start(void*)+22 bionic/libc/bionic/pthread_create.cpp:202 (discriminator 1) 0001a7e5 __start_thread+34 bionic/libc/bionic/clone.cpp:46 (discriminator 1)
Sie können stack
auf einen ganzen Grabstein anwenden. Beispiel:
stack < FS/data/tombstones/tombstone_05
Dies ist nützlich, wenn Sie gerade einen Fehlerbericht im aktuellen Verzeichnis entpackt haben. Weitere Informationen zur Diagnose nativer Abstürze und Tombstones finden Sie unter Diagnostizieren nativer Abstürze .
Abrufen eines Stack-Trace/Tombstones von einem laufenden Prozess
Sie können das Tool debuggerd
verwenden, um einen Stack-Dump von einem laufenden Prozess abzurufen. Rufen Sie debuggerd
über die Befehlszeile mit einer Prozess-ID (PID) auf, um einen vollständigen Tombstone in stdout
auszugeben. Um nur den Stack für jeden Thread im Prozess zu erhalten, schließen Sie das Flag -b
oder --backtrace
ein.
Eine komplexe Abwicklung verstehen
Wenn eine App abstürzt, ist der Stapel in der Regel ziemlich komplex. Das folgende detaillierte Beispiel verdeutlicht viele der Komplexitäten:
#00 pc 00000000007e6918 /system/priv-app/Velvet/Velvet.apk (offset 0x346b000) #01 pc 00000000001845cc /system/priv-app/Velvet/Velvet.apk (offset 0x346b000) #02 pc 00000000001847e4 /system/priv-app/Velvet/Velvet.apk (offset 0x346b000) #03 pc 00000000001805c0 /system/priv-app/Velvet/Velvet.apk (offset 0x346b000) (Java_com_google_speech_recognizer_AbstractRecognizer_nativeRun+176)
Die Frames #00–#03 stammen aus nativem JNI-Code, der unkomprimiert im APK gespeichert wurde, um Speicherplatz zu sparen, anstatt in eine separate .so
Datei extrahiert zu werden. Der Stack-Unwinder in Android 9 und höher benötigt die extrahierte .so
Datei nicht, um diesen häufigen Android-spezifischen Fall zu bewältigen.
Die Frames #00–#02 haben keine Symbolnamen, da sie vom Entwickler entfernt wurden.
Bild Nr. 03 zeigt, dass der Abwickler Symbole verwendet, wenn sie verfügbar sind.
#04 pc 0000000000117550 /data/dalvik-cache/arm64/system@priv-app@Velvet@Velvet.apk@classes.dex (offset 0x108000) (com.google.speech.recognizer.AbstractRecognizer.nativeRun+160)
Frame Nr. 04 ist vorab kompilierter Java-Code. Der alte Unwinder hätte hier angehalten und wäre nicht in der Lage gewesen, ihn über Java abzuwickeln.
#05 pc 0000000000559f88 /system/lib64/libart.so (art_quick_invoke_stub+584) #06 pc 00000000000ced40 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200) #07 pc 0000000000280cf0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344) #08 pc 000000000027acac /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+948) #09 pc 000000000052abc0 /system/lib64/libart.so (MterpInvokeDirect+296) #10 pc 000000000054c614 /system/lib64/libart.so (ExecuteMterpImpl+14484)
Die Frames #05–#10 stammen aus der ART-Interpreter-Implementierung. Der Stack-Unwinder in Versionen vor Android 9 hätte diese Frames ohne den Kontext von Frame Nr. 11 angezeigt, der erklärt, welchen Code der Interpreter interpretierte. Diese Frames sind nützlich, wenn Sie ART selbst debuggen. Wenn Sie eine App debuggen, können Sie sie ignorieren. Einige Tools, wie zum Beispiel simpleperf
, lassen diese Frames automatisch weg.
#11 pc 00000000001992d6 /system/priv-app/Velvet/Velvet.apk (offset 0x26cf000) (com.google.speech.recognizer.AbstractRecognizer.run+18)
Frame Nr. 11 ist der Java-Code, der interpretiert wird.
#12 pc 00000000002547a8 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.780698333+496) #13 pc 000000000025a328 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216) #14 pc 000000000027ac90 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+920) #15 pc 0000000000529880 /system/lib64/libart.so (MterpInvokeVirtual+584) #16 pc 000000000054c514 /system/lib64/libart.so (ExecuteMterpImpl+14228)
Die Frames #12–#16 sind die Interpreter-Implementierung selbst.
#17 pc 00000000002454a0 /system/priv-app/Velvet/Velvet.apk (offset 0x1322000) (com.google.android.apps.gsa.speech.e.c.c.call+28)
Frame Nr. 17 ist der Java-Code, der interpretiert wird. Diese Java-Methode entspricht den Interpreter-Frames #12–#16.
#18 pc 00000000002547a8 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.780698333+496) #19 pc 0000000000519fd8 /system/lib64/libart.so (artQuickToInterpreterBridge+1032) #20 pc 00000000005630fc /system/lib64/libart.so (art_quick_to_interpreter_bridge+92)
Frames #18–#20 sind die VM selbst, Code für den Übergang vom kompilierten Java-Code zum interpretierten Java-Code.
#21 pc 00000000002ce44c /system/framework/arm64/boot.oat (offset 0xdc000) (java.util.concurrent.FutureTask.run+204)
Frame Nr. 21 ist die kompilierte Java-Methode, die die Java-Methode in Nr. 17 aufruft.
#22 pc 0000000000559f88 /system/lib64/libart.so (art_quick_invoke_stub+584) #23 pc 00000000000ced40 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200) #24 pc 0000000000280cf0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344) #25 pc 000000000027acac /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+948) #26 pc 0000000000529880 /system/lib64/libart.so (MterpInvokeVirtual+584) #27 pc 000000000054c514 /system/lib64/libart.so (ExecuteMterpImpl+14228)
Die Frames #22–#27 sind die Interpreter-Implementierung, die einen Methodenaufruf vom interpretierten Code zu einer kompilierten Methode durchführt.
#28 pc 00000000003ed69e /system/priv-app/Velvet/Velvet.apk (com.google.android.apps.gsa.shared.util.concurrent.b.e.run+22)
Frame Nr. 28 ist der Java-Code, der interpretiert wird.
#29 pc 00000000002547a8 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.780698333+496) #30 pc 0000000000519fd8 /system/lib64/libart.so (artQuickToInterpreterBridge+1032) #31 pc 00000000005630fc /system/lib64/libart.so (art_quick_to_interpreter_bridge+92)
Die Frames #29–#31 sind ein weiterer Übergang zwischen kompiliertem Code und interpretiertem Code.
#32 pc 0000000000329284 /system/framework/arm64/boot.oat (offset 0xdc000) (java.util.concurrent.ThreadPoolExecutor.runWorker+996) #33 pc 00000000003262a0 /system/framework/arm64/boot.oat (offset 0xdc000) (java.util.concurrent.ThreadPoolExecutor$Worker.run+64) #34 pc 00000000002037e8 /system/framework/arm64/boot.oat (offset 0xdc000) (java.lang.Thread.run+72)
Die Frames #32–#34 sind kompilierte Java-Frames, die sich gegenseitig direkt aufrufen. In diesem Fall ist der native Call-Stack derselbe wie der Java-Call-Stack.
#35 pc 0000000000559f88 /system/lib64/libart.so (art_quick_invoke_stub+584) #36 pc 00000000000ced40 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200) #37 pc 0000000000280cf0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344) #38 pc 000000000027acac /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+948) #39 pc 0000000000529f10 /system/lib64/libart.so (MterpInvokeSuper+1408) #40 pc 000000000054c594 /system/lib64/libart.so (ExecuteMterpImpl+14356)
Die Frames #35–#40 sind der Interpreter selbst.
#41 pc 00000000003ed8e0 /system/priv-app/Velvet/Velvet.apk (com.google.android.apps.gsa.shared.util.concurrent.b.i.run+20)
Frame Nr. 41 ist der Java-Code, der interpretiert wird.
#42 pc 00000000002547a8 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.780698333+496) #43 pc 0000000000519fd8 /system/lib64/libart.so (artQuickToInterpreterBridge+1032) #44 pc 00000000005630fc /system/lib64/libart.so (art_quick_to_interpreter_bridge+92) #45 pc 0000000000559f88 /system/lib64/libart.so (art_quick_invoke_stub+584) #46 pc 00000000000ced40 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200) #47 pc 0000000000460d18 /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104) #48 pc 0000000000461de0 /system/lib64/libart.so (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue*)+424) #49 pc 000000000048ccb0 /system/lib64/libart.so (art::Thread::CreateCallback(void*)+1120)
Die Frames #42–#49 sind die VM selbst. Diesmal ist es der Code, der die Ausführung von Java in einem neuen Thread startet.
#50 pc 0000000000082e24 /system/lib64/libc.so (__pthread_start(void*)+36) #51 pc 00000000000233bc /system/lib64/libc.so (__start_thread+68)
In den Frames Nr. 50–51 sollten alle Threads beginnen. Dies ist der Startcode für den neuen libc
Thread.