Diese Seite wurde von der Cloud Translation API übersetzt.

ndk-gdb

Das NDK enthält ein Shell-Skript namens ndk-gdb zum Starten eines native Debugging-Sitzung über die Befehlszeile ausführen. Nutzende, die lieber eine grafische Benutzeroberfläche verwenden, sollten Lesen Sie die Dokumentation zum Debugging in Android Studio.

Voraussetzungen

Damit die native Fehlerbehebung über die Befehlszeile funktioniert, müssen die folgenden Anforderungen erfüllt sein:

Erstellen Sie Ihre Anwendung mit dem Skript ndk-build. Das Skript ndk-gdb unterstützt nicht die Legacy-Methode make APP=<name> zum Erstellen von Builds.
Aktivieren Sie das Debugging für Anwendungen in der Datei AndroidManifest.xml, indem Sie ein <application>-Element, das das android:debuggable-Attribut auf true setzt.
Erstellen Sie Ihre App für Android 2.2 (Android API-Level 8) oder höher.
Du kannst Fehler auf einem Gerät oder in einem Emulator mit Android 2.2 oder höher beheben. Zu Debugging-Zwecken kann das Ziel Die API-Ebene, die du in der Datei AndroidManifest.xml angibst, spielt keine Rolle.
Entwickeln Sie Ihre Anwendung in einer Unix-Shell. Verwenden Sie unter Windows Cygwin. oder das experimentelle ndk-gdb-py Python Implementierung.
Verwenden Sie GNU Make 3.81 oder höher.

Nutzung

Wenn Sie das Skript ndk-gdb aufrufen möchten, wechseln Sie in das Anwendungsverzeichnis oder ein beliebiges Verzeichnis darunter . Beispiel:

cd $PROJECT
$NDK/ndk-gdb

Hier verweist $PROJECT auf das Stammverzeichnis Ihres Projekts und $NDK auf Ihr NDK-Installationspfad.

Wenn Sie ndk-gdb aufrufen, wird die Sitzung so konfiguriert, dass nach Ihren Quelldateien gesucht wird sowie Symbol-/Debug-Versionen Ihrer generierten nativen Bibliotheken. Bei erfolgreichem Anhängen an Ihre Anwendungsprozess, gibt ndk-gdb eine lange Reihe von Fehlermeldungen aus und weist darauf hin, Systembibliotheken finden. Das ist normal, da Ihr Hostcomputer keine Symbol-/Debug-Versionen dieser Bibliotheken auf deinem Zielgerät. Sie können diese Nachrichten.

Als Nächstes zeigt ndk-gdb eine normale GDB-Eingabeaufforderung an.

Sie interagieren mit ndk-gdb auf dieselbe Weise wie mit GNU GDB. So können Sie zum Beispiel Verwenden Sie b <location>, um Haltepunkte festzulegen, und c (für „Weiter“), um um die Ausführung fortzusetzen. Eine umfassende Liste der Befehle finden Sie in der GDB-Handbuch Wenn Sie lieber den LLDB-Debugger, verwenden Sie den --lldb beim Aufrufen des Skripts ndk-gdb.

Beachten Sie, dass der Anwendungsprozess für die Fehlerbehebung beendet wird, wenn Sie die GDB-Eingabeaufforderung schließen. Dieses ist eine GDB-Einschränkung.

ndk-gdb verarbeitet viele Fehlerbedingungen und zeigt eine informative Fehlermeldung an, wenn ein Problem findet. Dabei wird unter anderem überprüft, ob die folgenden Bedingungen erfüllt sind:

Prüft, ob sich ADB in Ihrem Pfad befindet.
Prüft, ob Ihre Anwendung in ihrem Manifest als debugfähig deklariert ist.
Überprüft, ob auf dem Gerät die installierte App mit demselben Paketnamen auch ist. Debug-fähig ist.

Standardmäßig sucht ndk-gdb nach einem bereits laufenden Anwendungsprozess und zeigt eine wenn keine gefunden wird. Sie können jedoch die --start oder --launch=<name>-Option zum automatischen Starten deiner Aktivität vor der Fehlerbehebung Sitzung. Weitere Informationen finden Sie unter Optionen.

Optionen

Geben Sie ndk-gdb --help in die Befehlszeile ein, um eine vollständige Liste der Optionen aufzurufen. Tabelle 1 enthält eine Reihe der am häufigsten verwendeten sowie kurze Beschreibungen.

Tabelle 1 Allgemeine ndk-gdb-Optionen und ihre Beschreibungen.

Ab dem ndk-gdb mit dieser angegebenen Option wird die erste aufgeführte startbare Aktivität gestartet in deinem App-Manifest ein. --launch=<name> verwenden, um das nächste Launchable zu starten Aktivitäten. Um die Liste der startbaren Aktivitäten zu erstellen, führen Sie --launch-list über den Befehl aus Zeile.

Option	Beschreibung >
`--lldb`	Wenn dies festgelegt ist, verwendet das Skript für die Sitzung den LLDB-Debugger anstelle von gdb.
`--verbose`	Mit dieser Option wird das Build-System angewiesen, ausführliche Informationen zum nativen Debugging auszugeben Sitzungseinrichtung. Dies ist nur bei Debugging-Problemen erforderlich, wenn der Debugger keine Verbindung zum App und die von `ndk-gdb` angezeigten Fehlermeldungen reichen nicht aus.
`--force`	Standardmäßig wird der Vorgang von `ndk-gdb` abgebrochen, wenn bereits eine andere native Debugging-Sitzung gefunden wird auf demselben Gerät ausgeführt werden. Mit dieser Option wird die andere Sitzung beendet und durch eine neue ersetzt. Beachten Sie, dass diese Option nicht die App, für die das Debugging ausgeführt wird, beendet. Diese müssen Sie separat.
`--start`	Wenn Sie `ndk-gdb` starten, wird standardmäßig versucht, eine Verbindung zu einer vorhandenen laufenden Instanz von Ihre App auf dem Zielgerät. Sie können dieses Standardverhalten überschreiben, indem Sie `--start` verwenden, um die App vor der Fehlerbehebungssitzung explizit auf dem Zielgerät starten.
`--launch=<name>`	Diese Option ähnelt der Option `--start`, mit dem Unterschied, dass Sie damit eine bestimmte Aktivitäten aus Ihrer Anwendung. Diese Funktion ist nur nützlich, wenn in Ihrem Manifest mehrere für alle zugängliche Aktivitäten.
`--launch-list`	Mit dieser Option wird eine Liste aller Aktivitätsnamen gedruckt, die Sie in Ihrem App-Manifests. In „`--start`“ wird der Name der ersten Aktivität verwendet.
`--project=<path>`	Mit dieser Option wird das App-Projektverzeichnis angegeben. Das ist nützlich, wenn Sie den ohne in das Projektverzeichnis wechseln zu müssen.
`--port=<port>`	Standardmäßig verwendet `ndk-gdb` den lokalen TCP-Port 5039, um mit der App zu kommunizieren das Debugging auf dem Zielgerät ist. Wenn Sie einen anderen Port verwenden, können Sie Programme nativ debuggen die auf verschiedenen Geräten oder Emulatoren ausgeführt werden, die mit demselben Hostcomputer verbunden sind.
`--adb=<file>`	Mit dieser Option wird adb angegeben. ausführbar. Dies ist nur erforderlich, wenn Sie den Pfad nicht so festgelegt haben, dass diese ausführbare Datei enthalten ist.
`-d` `-e` `-s <serial>`	Diese Flags ähneln den gleichnamigen ADB-Befehlen. Legen Sie diese Flags fest, wenn Sie mehrere Geräte oder Emulatoren, die mit Ihrem Hostcomputer verbunden sind. Ihre Bedeutung hat folgende Bedeutung: `-d` Verbindung zu einem einzelnen physischen Gerät herstellen `-e` Stellen Sie eine Verbindung zu einem einzelnen Emulatorgerät her. `-s <serial>` Stellen Sie eine Verbindung zu einem bestimmten Gerät oder Emulator her. Hier ist `<serial>` der Name des Geräts. wie im Befehl `adb devices` aufgeführt. Alternativ können Sie die Umgebungsvariable `ADB_SERIAL` definieren, um eine bestimmte Gerät ausgeführt werden, ohne dass eine spezielle Option erforderlich ist.
`--exec=<file>` `-x <file>`	Diese Option weist `ndk-gdb` an, die GDB-Initialisierungsbefehle auszuführen, die in `<file>`, nachdem eine Verbindung zum Prozess hergestellt wurde, für den eine Fehlerbehebung durchgeführt wird. Diese Funktion ist nützlich, Sie etwas wiederholt ausführen möchten, z. B. eine Liste mit Haltepunkten erstellen und dann das werden automatisch ausgeführt.
`--nowait`	Deaktivieren Sie das Pausieren des Java-Codes, bis GDB verbunden ist. Wenn Sie diese Option übergeben, kann der Debugger frühe Haltepunkte zu verpassen.
`--tui` `-t`	Text-Benutzeroberfläche aktivieren, falls verfügbar.
`--gnumake-flag=<flag>`	Diese Option ist ein oder mehrere zusätzliche Flags, die an die `ndk-build`-System, wenn Projektinformationen abgefragt werden. Sie können mehrere Instanzen dieser Option in der und denselben Befehl geben.

Hinweis : Die letzten drei Optionen in dieser Tabelle beziehen sich nur auf das Python-Version von ndk-gdb.

Thread-Unterstützung

Wenn deine App auf einer Plattform läuft, die älter als Android 2.3 (API-Level 9) ist, ndk-gdb können native Threads nicht richtig debuggen. Der Debugger kann nur Fehler im Hauptthread beheben, ignoriert die Ausführung anderer Threads.

Wenn Sie einen Haltepunkt in eine Funktion einfügen, die in einem Nicht-Haupt-Thread ausgeführt wird, wird das Programm beendet und GDB zeigt die folgende Meldung an:

Program terminated with signal SIGTRAP, Trace/breakpoint trap.
      The program no longer exists.