IzzyOnDroid

• Intro
• App-Listen
• Artikel
• Bücher
• Downloads
• App-Repo
• Impressum

Privacy Links

↓ Your product here? ↓

Das Inoffizielle Android-Handbuch Android kennenlernen, Tipps & Tricks Für EUR 16,99 bei Amazon kaufen

Das Inoffizielle Android Systemhandbuch Tiefer ins System einsteigen Für EUR 7,00 bei Amazon kaufen

Die besten Android-Apps Den Androiden austatten Für EUR 5,00 bei Amazon kaufen

 

ADB für Anwender

Toyota Robot; © Chris 73 (GNU)
Quelle: Wikimedia

Die meisten haben sicherlich bereits einmal vom Android SDK, einem hauptsächlich für die Entsicklung von Android Software gedachten Toolkit¹, gehört. Eine seiner Komponenten nennt sich ADB, die Android Debug Bridge, und wird für die Interaktion von Android-Gerät und Computer eingesetzt. Ein recht mächtiges Tool, mit dem man interessante Dinge anstellen kann – aber noch einmal: Es ist nur eine der Komponenten des SDK (und keineswegs die umfangreichste, was die Dateigröße betrifft).

Viele sind sicher auch bereits über Tutorials gestolpert, in denen einzelne Schritte den Einsatz der ADB notwendig machten – sei es für ein einfaches logcat, Shell-Zugriff, Side-Loading von Apps, oder eine andere Aufgabe. Einige haben an der Stelle wohl mit dem Lesen aufgehört, und nach einem anderen Tutorial Ausschau gehalten: Warum sollte man sich ganze 90+ MB (welche installiert definitiv noch mehr Platz einnehmen) für ein komplettes Entwickler-Toolkit herunterladen, wenn man nur einen kleinen Teil davon benötigt? Man kauft ja schließlich auch nicht gleich ein Rind, wenn man ein Steak essen will! Ist das denn wirklich notwendig? Zum Glück keinesfalls – wie ich bereits in meinem ursprünglichen Post zu diesem Thema vor ungefähr einem Jahr aufgezeigt habe. Welchen ich hier aufgreifen, und mit einigen Anwendungs-Beispielen aus einem meiner Bücher² bereichern möchte.

Gibt es eine minimale ADB-Installation?

Tatsächlich muss man dafür nicht das komplette SDK installieren – zumindest nicht, wenn man ohnehin nicht in die Entwicklung einzusteigen beabsichtigt. Um ein paar ADB-Befehle als “normaler Anwender” ausführen zu können, ist eine rudimentäre Installation vollkommen ausreichend. In diesem Artikel möchte ich zeigen, wie man genau dies erreicht – und dabei die gebräuchlichsten Betriebssysteme einschließen.

Voraussetzungen

Zunächst einmal benötigen wir die passenden Binaries. Diese finden sich u. a. im Download-Bereich dieser Site: Einfach links den Reiter Downloads auswählen, und die für das Ziel-Betriebssystem passende Datei herunterladen. Es stehen adb-binaries-* für Linux, Mac, und Windows bereit. Zugegebenermaßen nicht unbedingt in der jeweils aktuellsten Version – aber unseren Bedarf als “normale Anwender” erfüllen sie allemal. Wer auf einer aktuelleren Version besteht, findet die passenden Archive u. a. bei Blogspot³, vergleicht den Inhalt der Dateien mit denen von hier – und sollte sich sein eigenes “Minimal-Paket” zusammenstellen können.

Windows-PCs

Bei einsatz von MS Windows (in welcher Version auch immer) benötigt man außerdem spezifische USB-Treiber für das zu verwendende Android-Gerät. Einen wirklich generischen Treiber gibt es hier nicht (auch wenn Koushs Universal Driver mit einer Vielzahl von Android-Geräten funktionieren sollte). Der jeweils passende Treiber findet sich i. d. R. im download-Bereich auf der Website des jeweiligen Herstellers.

Linux und Mac OS

Läuft der Computer mit Linux oder MacOS, sind keine speziellen Treiber notwendig. Allerdings muss das einzusetzende Android-Gerät (so es denn nicht “Nexus” heißt) u. U. dem System bekannt gemacht werden. Für Linux finden sich die entsprechenden Schritte in meinem Post bei Stack Exchange beschrieben. Da ich mit MacOS nicht vertraut bin, kann ich dafür leider keine passenden Instruktionen anbieten.

Installation

Linux

Unter Linux gestaltet sich dies denkbar einfach: Die Binaries aus dem heruntergeladenen Archiv in ein Verzeichnis nach Wahl kopieren (es empfehlen sich ~/bin für eine rein persönliche, bzw. /usr/local/bin für eine systemweite Installation). Aktuell sind das lediglich zwei Dateien: adb sowie aapt (wobei letztgenannte hauptsächlich von Tools wie QtADB⁴ genutzt wird, und für die Ausführung der unten beschriebenen ADB Befehle nicht notwendig ist). Dann ggf. noch die Permissions anpassen (an der Kommandozeile: chmod 0755 adb aapt), und sie schließlich (optional) zum Pfad hinzufügen – damit sie von überall aus erreichbar sind (für /usr/local/bin sollte dies bereits der Fall sein; andernfalls beispielsweise bei Installation nach ~/bin am Ende der persönlichen ~/.profile ein export PATH="~/bin:$PATH" einfügen).

Windows

Der Download für Windows beinhaltet einige zusätzliche Dateien, doch auch hier gilt: Alles in ein Verzeichnis der Wahl entpacken, und ggf. den Pfad in der entsprechenden Umgebungsvariable eintragen. Da ich kein Windows verwende, kann ich dafür keine genauere Beschreibung liefern.

MacOS

Hier sollte das Vorgehen weitgehend analog zur Installation unter Linux verlaufen, wobei ich – so ganz ohne Meck – keine detaillierte Anleitung liefern kann.

Anwendung und Einsatz-Beispiele

Welche praktischen Anwendungsfälle gibt es nun für “normale Anwender”? Einige habe ich bereits in der Einleitung dieses Artikels aufgezählt, beginnen wir daher mit diesen. Zuvor gilt es jedoch sicherzustellen, dass das Android-Gerät ordnungsgemäß mit dem Computer verbunden, und von letzterem auch erkannt wurde: Zeigt der Befehl adb devices nichts an, ist dies nicht der Fall. Erscheint jedoch eine (meist kryptische) Bezeichnung für ein “device”, hat soweit alles geklappt

Logcat

Android System-Logs erweisen sich für Debugging und Troubleshooting oftmals als extrem hilfreich. Selbst wenn man als “normaler Anwender” selbigen nicht viel verständliches entnehmen können sollte: Durch die Möglichkeit, die enthaltenen Informationen dem jeweiligen Entwickler zur Verfügung stellen zu können, erhöht sich die Chance, dass dieser das Problem identifizieren (und beheben) kann. Dafür bietet sich beispielsweise der Befehl adb logcat mit einer ganzen Reihe an Parametern an – von welchen ich hier lediglich zwei herauspicken möchte, die für uns Nicht-Entwickler von besonderem Interesse sein dürften: -v time konvertiert den jeder Meldung vorangestellten Timestamp in ein für Menschen lesbares Format, und -f <Dateiname> speichert die Ausgabe in der angegebenen Datei (statt sie auf dem Bildschirm auszugeben), sodass sie mit einem Text-Betrachter der Wahl untersucht werden kann.

Doch logcat ist nicht der einzige Befehl, der uns Debug-Informationen liefert. Da gibt es beispielsweise noch adb bugreport, der gleich eine ganze Kollektion von Details sammelt. Bei diesem sollte die Ausgabe besser ebenfalls in eine Datei umgeleitet werden: adb bugreport > bugreport.txt erledigt dies. Auch diese Informationen sind besonders hilfreich für den Entwickler bei der Fehler-Analyse – man selbst sollte aber ruhig selbst einmal einen Blick hinein werfen, was definitiv interessant sein dürfte

Shell-Zugriff

Linux-Anwendern brauche ich sicher nicht zu erklären, was sich hinter dem Begriff “Shell” verbirgt: Vereinfacht gesagt, eine Kommandozeile direkt auf dem Android-Gerät. Diese lässt sich mit einer Terminal-App erreichen – oder via adb shell. Und was tut man nun damit? Welche Kommandozeilen-Tools stehen hier zur Verfügung? Eine Referenz stellt eine längere Liste interessanter Kandidaten bereit. Eine kürzere Liste findet sich hier, um einen Vorgeschmack zu geben:

• pm (der “Package Manager”): ohne Parameter aufgerufen, präsentiert er eine Liste verfügbarer Optionen. Er beschäftigt sich mit “Packages” – was in etwa den installierten Apps aus System-Sicht entspricht. Diese lassen sich auflisten, ihre Permissions anzeigen, installieren/de-Installieren, oder auch aktivieren/deaktivieren (aka “freeze/defrost”), und mehr. Letzteres ist besonders interessant, wenn man bereits eine gute Zahl von Apps deaktiviert hat, und eines Tages einen Factory-Reset des Gerätes durchführen muss: Statt vorher alles akribisch zu notieren und anschließend wieder manuell abzuarbeiten, lässt sich dies hiermit auch automatisieren (für Details, siehe Einfrieren an der Kommandozeile).
• am (der “Application Manager”): eine Liste möglicher Parameter gibt es auch hier wieder, indem man es einfach ohne aufruft. Und wieder geht es um Apps, diesmal jedoch eher aus “Prozess-Sicht”. Es lassen sich “Aktivitäten” starten (d. h. direkt zu einem bestimmten “Bildschirm” in einer App springen), Apps “Zwangsbeenden” (force-stop) oder “abschießen” (kill), und so weiter. Klingt etwas abstrakt, daher ein paar “fassbarere” Beispiele:
  • adb shell "am start -a android.intent.action.VIEW -d https://duckduckgo.com/": einen Web-Browser mit der angegebenen Seite starten
  • am start -a android.intent.action.CALL -d tel:012345678: einen Anruf bei der angegebenen Nummer tätigen
  • adb shell "am start -n com.android.settings/com.android.settings.Settings": die Android System-Einstellungen öffnen
  • adb shell "am start -a android.intent.action.INSERT -t vnd.android.cursor.dir/contact -e name ’Martin Mustermann’ -e phone 1234567890": einen neuen Kontakt erstellen
  • busybox sed -n ’s/<package name="([^"]+)".*enabled="false".*/1/p’ /data/system/packages.xml | while read PKG; do pm enable "$PKG"; done: alle deaktivierten Apps wieder aktivieren. Besonders dann hilfreich, wenn man “offensichtlich eine zuviel” deaktiviert hat, nicht mehr weiß, welche das gewesen sein könnte – und der Androide nach einem Reboot nicht mehr bis zum Homescreen kommt. Solange ein Zugriff per ADB noch funktioniert, lässt sich das Problem auf diese Weise beheben.

Gedanken eines Linux-Admins: ”I’ll convert you into a tiny little shell script!” Warum auch nicht?

#!/bin/bash
if [ -z "$‌1" ]; then
  read -p "Welche Nummer soll angerufen werden: " NUMBER
else
  NUMBER=$‌1
fi
echo "Initialisiere Anruf bei $NUMBER..."
am start -a android.intent.action.CALL -d tel:$NUMBER

Jetzt braucht man sich den “kryptischen Befehl” nicht länger merken: Obigen Schnippsel als anruf speichern, ein chmod 0755 anruf (ausführbar machen) hinterher, und ab geht’s: anruf 12345 ruft direkt an, einfach nur anruf fragt zunächst nach der Nummer. anruf ahsfdjadk dürfte allerdings einen Fehler provozieren, den ich im Beispiel-Skript nicht abgefangen habe…

Dateien von/zum Android-Gerät kopieren

Zumindest aus meiner Sicht ist es ziemlicher Overkill, für das einfache Kopieren einer Datei erst zwei grafische Applikationen (eine auf dem Gerät, eine auf dem Computer) starten zu müssen – nur um die eigentliche Aktion dann per “Dreck and Dropp” zu vollziehen. Eine einzige Zeile am “Prompt” tut es doch auch. Dafür stehen uns jetzt adb push (Computer → Gerät) und adb pull (Gerät → Computer) zur Verfügung. Beide erwarten zwei Parameter: Quelle und Ziel. Der kleine Fallstrick, der einen dabei desöfteren erwischt: Beide Parameter müssen im Typ übereinstimmen. Kopiert man also eine Datei, müssen Quelle und Ziel ein Dateiname sein – zum Kopieren eines ganzen Verzeichnis(baum)es entsprechend Verzeichnisse. Mischen impossibel: adb push somefile.ext /sdcard wird fehlschlagen (Datei → Verzeichnis).

Side-Loading von Apps

Für das Installieren und Deinstallieren von Apps stellt uns ADB zwei weitere interessante Möglichkeiten zur Verfügung. Hat man beispielsweise eine App in Verdacht, auf dem Gerät für Probleme zu sorgen – möchte aber bei einer testweisen Deinstallation nicht die Daten derselben verlieren: kein Problem. Entweder macht man vorher ein Backup, welches man später wieder herstellen kann – oder verwendet einfach adb uninstall mit dem Parameter -k, der für “keep data” (Daten behalten) steht. Während adb uninstall <package_name> App und Daten vom Gerät entfernt, fasst adb uninstall -k <package_name> die Daten nicht an. War die “entfernte App” unschuldig (und man hat deren .apk Datei zur Hand), befördert ein adb install <apk_file> wieder zurück, als sei nichts gewesen.

adb install hat ebenfalls zwei interessante Parameter anzubieten: -r für “Re-Install” (um eine bereits installierte App zu ersetzen), und -s für die direkte Installation auf SDKarte.

Backup & Restore

Helium Backup

Android 4.0 (aka “Ice Cream Sandwich”) brachte still und heimlich ein mächtiges neues Feature mit: Die Möglichkeit zur Erstellung (und Wiederherstellung) von Backups via ADB. Wie auch die bereits zuvor aufgeführten Dinge, arbeitet dies von der Kommandozeile – mit zwei Befehlen: adb backup sowie dem Gegenstück adb restore. adb backup bringt eine Reihe von Optionen mit die, wie der Name suggeriert, alle optional sind:

• -f <file>: die Datei, in der das Backup abgelegt werden soll. Default: backup.ab
• -apk bzw. -noapk: ob die .apk Dateien der Apps mitgesichert werden sollen oder nicht (Default: -noapk)
• -shared bzw. -noshared: analog für die Daten der SDKarte. Default: -noshared.
• -all: Alle Apps sichern (damit man sie nicht jeweils einzeln aufzählen muss)
• -system bzw. -nosystem: System-Apps mit sichern (oder halt, defaultmäßig, nicht). Vorsicht mit -system, siehe unten.
• zum Abschluss der Liste die Paketnamen der Apps, die gesichert werden sollen.

adb restore hingegen kennt nur einen einzigen Parameter: die Backup-Datei, die wiederhergestellt werden soll. Eine Wiederherstllung ausgewählter Teile ist nicht möglich – diese Operation heißt “Alles-oder-Nichts”. Und während sich selbstinstallierte Apps sowie deren Daten auch geräteübergreifend wiederherstelllen ließen, kann man dies für System-Apps nicht unbedingt sagen: Die sind nämlich oftmals Geräte- und sogar Android-Versions-abhängig. Daher meine obige Warnung zum -system Parameter.

Schauen wir uns ein praktisches Beispiel an: Sichern wir eine App einschließlich ihrer Daten, und stellen das Ganze (auf dem gleichen oder einem anderen Gerät) wieder her. Dafür benötigen wir zunächst den Paketnamen der App – welcher sich am Einfachsten per Besuch auf der zugehörigen Playstore-Seite herausfinden lässt. Nur so zum Spaß verwende ich als Beispiel eine weitere Backup-App zum back-uppen: Titanium Backup hat die Playstore URL https://play.google.com/store/apps/details?id=com.keramidas.TitaniumBackup. Der Paketname ist mit dem id Parameter angegeben: com.keramidas.TitaniumBackup.

# Backup erstellen:
adb backup -f titanium.ab -apk -noshared -nosystem com.keramidas.TitaniumBackup
# Wiederherstellen:
adb restore titanium.ab

Natürlich sind einige der hier von mir verwendeten Parameter obsolet: -noshared -nosystem sind Defaults. So wird aber der Aufbau der Befehlszeile etwas deutlicher: Erst der Befehl (adb backup), dann die Optionen, und erst ganz zum Schluss der oder die Paketnamen (mit Leerzeichen getrennt lassen sich weitere angeben).

Kein Freund der Kommandozeile? Kein Problem, es gibt auch zahlreiche grafische “Front-Ends”. Speziell für das Backup wäre da beispielsweise Helium Backup zu nennen – welches mit und ohne root direkt auf dem Gerät funktioniert, und die Sicherungen auf der SD-Karte speichert – ein Screenshot findet sich am Anfang dieses “Kapitels”. Wer die ganze Operation gleich direkt vom Computer ausführen möchte, kann auch einen Blick auf Holo Backup werfen – verfügbar zumindest für Linux und Windows.

Abschluss

Wie ich (hoffentlich) zeigen konnte, gibt es so einige Bereiche, in denen der Droide per ADB wunderbar mit dem Computer zusammenspielt⁵. Sollte das USB-Kabel zu kurz, oder weitere Ideen gesucht sein: In der App-Liste ADB hier bei IzzyOnDroid sollten sich noch einige Inspirationen finden lassen. Und nicht nur hier: Das Web ist voll von “kleinen netten Tricks” und auch “(grafischen) Tools” zur Benutzung mit ADB.