Dem Erstellen von Screenshots eines Android-Geräts haftet der Nimbus der Kompliziertheit an, weil es eben nicht wie bei iOS mit einem systemweiten Hotkey funktioniert, sondern entweder ein gerootetes (= gejailbreaktes) Handy erfordert – oder den USB-Debug-Modus und ein installiertes Android SDK (Software Development Kit). Letzteres ist aber mit den richtigen Handgriffen tatsächlich gut beherrschabar und braucht dann auch lediglich ca. 40 MB Plattenplatz – und entgegen aller Unkenrufe weder eine Eclipse-Entwicklungsumgebung noch ein vollwertiges JDK.
Ich führe dies am Beispiel von Linux durch, am Mac funktioniert es exakt identisch. — Windows dagegen habe ich nicht ausprobiert – eine entsprechende Test-Installation habe ich gerade nicht zur Hand, und dort muss noch ein spezieller USB-Treiber installiert werden, was ich für unnötigen Aufwand halte.
Also frisch ans Werk: Zuallererst brauchen wir Java – ein Feld-Wald-Wiesen-JRE (in meinem Falle ein zeitgemäßes J2SE Version 6) genügt. Am Mac ist dies meist vorinstalliert, unter Linux bemüht man die bevorzugte Paketverwaltung. Anschließend lädt man sich unter
die zum Betriebssystem passende Fassung des SDK-Starter Package herunter, in diesem Fall also android-sdk_r08-mac_86.zip für den Mac oder android-sdk_r08-linux_86.tgz für Linux. Das jeweilige Paket packt man irgendwo innerhalb des Homeverzeichnisses aus, wo man permanent Schreibrechte hat – z.B. unter ~/Documents bzw. ~/Dokumente.
Das Programm, das wir suchen, heißt „Dalvik Debug Monitor“ oder kurz „ddms“. Es findet sich nach dem Auspacken des SDK im Unterverzeichnis „tools“ als ./tools/ddms. Beim ersten Aufruf bekam ich sowohl unter Mac OS 10.6.5 als auch unter Ubuntu Linux 10.04 die Fehlermeldung
E/ddms: Not implemented [multiple displays]
Dies kann man getrost ignorieren – einfach ddms noch einmal aufrufen. Resultat:
ddms - adb-Fehler
E/adb: Failed to get the adb version: Cannot run program „/home/gero/Dokumente/android-sdk-linux_86/tools/adb“: java.io.IOException: error=2, No such file or directory
Dies kann man leider nicht so ohne weiteres ignorieren – ddms muss erst einmal wieder geschlossen werden. ADB ist meines Wissens die Datenbank der Android-Devices, und ohne die geht’s halt nicht. Siehe Kommentar von Markus unten: ADB ist die Android Debug Bridge, eine (proprietäre) Client/Server-Debug-Anbindung ähnlich einer gdb Client/Server-Verbindung.
Um dies zu lösen, ruft man statt ./ddms nun folgendes auf:
./android update sdk
Nach kurzem Nachladen und Nachdenken erscheint folgendes Fenster mit der Auswahl der nachzuinstallierenden Pakete. Keine Sorge: Sie landen einzig und allein im schreibfähigen SDK-Verzeichnis, nirgendwo sonst.
Es genügt, das oberste Paket „Android SDK Platform-tools, revision 1 [*]“ zu installieren. Alle anderen kann man mit Hilfe von „Reject“ einzeln abwählen. Die Dinger mögen bei der App-Entwicklung und zur Erstellung „virtueller“ (ie. emulierter) Android-Geräte Sinn machen, aber wir wollen ja nur Screenshots eines realen Android-Geräts anfertigen.
Android-SDK - “update sdk”
Anschließend möchte die ADB neustarten – soll sie doch.
ADB-Restart
Fertig, abputzen!
Installation abgeschlossen
Anschließend startet sich das ./ddms vollkommen problemlos, ohne Fehlermeldung.
Zur Erinnerung: Das Handheld muss unter Einstellungen / Anwendungen / Entwicklung in den USB-Debugging-Modus versetzt werden, sonst bleibt das ddms-Fenster leer.
… Im Gegensatz zu Mac OS X ergibt sich unter manchen Linux-Versionen an dieser Stelle aufgrund restriktiver Rechtevergabe auf die angeschlossenen USB-Devices leider noch eine kleinere Klippe: Im ddms erscheint das angeschlossene Handheld mit Fragezeichen entstellt.
Unbekanntes Gerät
Darüber hinaus scheitert der Versuch der Kommunikation mit dem Gerät mit der Fehlermeldung
W/ddms: Unable to get frame buffer: insufficient permissions for device
Des Rätsels pragmatische Lösung: Einfach den ADB mit Root-Rechten starten. (Es gibt eine weniger radikale Lösung, nämlich die Beschaffung von Schreibrechten für Nicht-Admin-User auf das USB-Device, aber der Start des ADB als root geht hier am schnellsten.)
Der ADB steht nach dessen Installation im SDK-Verzeichnis als ./platform-tools/adb, und folgende Kommando-Sequenz löst das Problem:
./adb kill-server
sudo ./adb start-server
Und siehe da – beim Neustart ist der ddms kooperativ:
Erkanntes Gerät
Nachdem man das Gerät angewählt hat, findet sich das Screenshot-Tool nun unter Device / Screen-Capture – was sich per Druck auf Ctrl-S bzw. Strg-S aufrufen lässt.
Ein Klick auf „Refresh“ holt den aktuellen Bildschirminhalt heran, den man mit „Save“ dann als PNG-Datei abspeichern kann.
USB-Debugging - Screenshot
Et volià! Das gesamte SDK-Verzeichnis benötigt so gerade einmal 41 MB Plattenplatz.
Wenn ich hier mal mit etwas Info zur Seite stehen darf? ADB ist die Android Debug Bridge (http://developer.android.com/guide/developing/tools/adb.html), keine Datenbank, einfach nur eine (proprietäre) Client/Server debug Anbindung ähnlich einer gdb Client/Server Verbindung.
Um dem sudo Problem beim adb Neustart zu entgehen, kann man sich auch gut mit udev Regeln behelfen, siehe hierzu e.g. fuer Ubuntu http://wiki.ubuntuusers.de/udev
Normalerweise reicht es, eine Datei
/etc/udev/rules.d/60-adb-usb.rules
mit folgendem Inhalt zu erstellen:
# Regeln zum Vergeben von Nutzerrechten auf ADB Geräten
ACTION==“add“, SUBSYSTEMS==“usb“, ATTRS{product}==““, GROUP=““
Den Gerätenamen findet man ueber „sudo lsusb“ bzw. „sudo lsusb -v“
Natuerlich muss der udev Service dann neu gestartet werden:
„sudo service udev reload“
Jawoll, Freund, hast ja recht – Du Boss, ich nix.
… Dass man die udev-Regeln modifizieren kann, stand ja vor ein paar Ausgaben in der c’t beschrieben. Aber „mal eben schnell“ war der Weg über einen sudo-Restart des adb gradliniger.