Bash + ADB: Adebar hilft bei Backup, Dokumentation, und Restore
Jetzt ist es passiert: Ich muss eines meiner Android-Geräte zwecks Reparatur zum Service-Center einschicken. Das bedeutet natürlich einen „Factory-Reset“ vor dem Verpacken, was ein vorheriges (gutes) Backup impliziert. Zwar erstelle ich regelmäßig diverse Sicherungen (etwa automatisch mit Titanium Backup), aber habe ich wirklich an alles gedacht? Wird die Wiederherstellung ein „Kinderspiel”? Vielleicht sollte ich die Chance auch gleich zum „Aufräumen“ nutzen. Oh, und was ist mit der ganzen „Bloatware“, die ich mühselig ausfindig gemacht und deaktiviert habe, und den deaktivierten „Auto-Starts“? Wieviel Handarbeit kommt da auf mich zu, wenn ich mein Gerät wieder habe?
Das waren so etwa die Gedanken, die mich dazu gebracht haben, Adebar zu schreiben. Was sich daraus entwickelt hat, möchte ich im Folgenden beschreiben:
Was ist Adebar?
In wenigen Worten: Was ist Adebar, und was leistet es? Im Wesentlichen verwendet es Bash scripting und ADB Befehle, um Informationen vom angeschlossenen Android-Gerät zu beziehen – und daraus mehrere Dateien zu erstellen:
- Skripts zum Backup/Restore von User-Apps und ihrer Daten sowie der Daten von System-Apps
- Skripts zum „wieder Einfrieren“ von Apps etwa nach einem Factory-Reset
- Kopien verschiedener Konfigurations-Dateien, welche (root-) Anwender verändert haben könnten
- Eine begrenzte „Geräte-Dokumentation“
Ein „Beispiel-Ausgabe-Verzeichnis“ könnte etwa wie folgt aussehen:
├── conf │ ├── gps.conf │ ├── hosts │ └── wpa_supplicant.conf ├── docs │ ├── build.prop │ ├── deadreceivers │ ├── deadReceivers.md │ ├── deviceInfo.md │ ├── packages.xml │ └── userApps.md ├── deadReceivers.sh ├── defaultInstallLoc ├── disable ├── sysbackup ├── sysrestore ├── userbackup └── userrestore
Wie an diesem Beispiel ersichtlich, erstellt Adebar drei Sets von Dateien:
- Einige gesicherte Konfigurations-Dateien im Unterverzeichnis
conf/
- Eine „Geräte-Dokumentation“ im Unterverzeichnis
docs/
- Einige Skripte im „Hauptverzeichnis“
Die meisten der Skripte sind auch bereits „ausführbar“ gemacht.
Was an dieser Stelle erwähnt werden sollte: Nicht alle dieser Dateien werden generell erstellt. Der Zugriff auf manche erfordert es, dass der ADB Daemon im root-Modus läuft (dies ist bei vielen Custom-ROMs automatisch der Fall, und kann andernfalls z. B. mit Chainfire’s adbd Insecure erreicht werden – setzt aber generell ein gerootetes Gerät voraus), andere benötigen zusätzlich das PHP Command-Line Interface auf dem Rechner (das Parsen der packages.xml
findet auf diese Weise statt).
Was leisten die erstellten Skripte?
Zuallererst: Vor ihrer Ausführung sollte man einen Blick auf deren Inhalt werfen, und unerwünschtes auskommentieren. Das könnten beispielsweise Apps sein, die man gar nicht mehr verwendet – kein Grund, das Backup damit „aufzublähen“.
deadReceivers.sh
würde einige „Auto-Starter” deaktivieren. Dies ist das einzige Skript, welches nicht automatisch ausführbar gemacht wird, und auch eine Dateierweiterung besitzt. Mit gutem Grund: Dieses so auszuführen, wie es ist, könnte „unschöne Nebenwirkungen“ haben. Wer sich damit nicht auskennt, lässt also besser die Finger davon.defaultInstallLoc
: irgendwann im Leben des Gerätes hat man evtl. die „default install location“ (die Einstellung dafür, wo Apps per Default installiert werden sollen) angepasst. Mit diesem Skript lässt sie sich auf den Wert einstellen, der zum Zeitpunkt der Erstellung desselben aktiv war. Oder man ignoriert es einfach, wenn der Wert beispielsweise auf „0” steht (was üblicherweise auf einem „frischen System“ ohnehin eingestellt ist).- lässt man das Skript
disable
laufen, werden alle Apps deaktiviert/eingefroren, die dies zum Zeitpunkt der Skripterstellung waren. Sehr nützlich, um die ganze „Bloatware“ wieder loszuwerden, ohne die gesamte App-Liste von Hand durchgehen zu müssen sysbackup
/sysrestore
führenadb backup
resp.adb restore
für die Daten der System-Apps aus – für jede dieser Apps separat, um ein selektives Backup/Restore zu ermöglichen. Das beinhaltet auch die sogenannte „Shared Storage” (also die Inhalte der SD-Karte), was allerdings vom Anwender extra bestätigt werden muss: je nach „Füllstand” kann ein Backup desselben nämlich nicht nur recht lange dauern, sondern auch in einer riesigen Datei resultieren.userbackup
/userrestore
führenadb backup
resp.adb restore
für die User-Apps (einschließlich ihrer Daten) aus, wiederum für jede App separat (aus dem zuvor beschriebenen Grund).
Wofür sind die Dateien im Verzeichnis docs/
?
Hier kann man eine kleine Geräte-Dokumentation erwarten. Die schließt einige vom Gerät gesicherte Dateien ein (build.prop
, packages.xml
), aber ebenso aus selbigen extrahierte Inhalte in Form von Markdown Dateien:
deviceInfo.md
gibt ein wenig generelle Information über das Gerät, die hauptsächlich aus derbuild.prop
und mittelspm list features
gewonnen wurde. Das beinhaltet u. a. Hersteller- und Geräte-Namen, Android-Version, Sprach-/DNS- Einstellungen, und ein wenig mehr. Nicht alle Details sind bei jedem Gerät verfügbar.userApps.md
listed die vom Anwender installierten Apps auf, gruppiert nach Installations-Quelle.deadReceivers.md
ist das Pendant zum zuvor erwähnten Skript, welches die „disabled components“ in (hoffentlich) lesbarem Format enthält.
Wo kann man mehr Informationen bekommen?
Adebar ist Open Source, und bei Github gehostet – daher ist dort natürlich auch die erste Anlaufstelle: ob man auf den jeweils aktuellen Quelltext zugreifen, Probleme melden, einen Feature-Wunsch äußern, oder sich an der Entwicklung / als Tester beteiligen möchte (Tipp: Tester und Feedback sind ebenso willkommen wie jemand, der eine GUI schreiben möchte ). Der Entwickler (meinereiner) ist auch via IRC bei Freenode im Channel #izzysoft
zu finden.
Fazit
Adebar ist zwar definitiv keine „Ein-Klick-Lösung“ – kann aber definitiv zu einem „guten Gefühl“ bezüglich „vorhandene Backups und was sie Abdecken“ beitragen. Als Nebeneffekt erhält man auch gleich noch eine kleine Geräte-Dokumentation. Das Ganze erweist sich insbesondere als nützlich, wenn man einen Werksreset seines Gerätes vornehmen, oder dessen Konfiguration duplizieren möchte. Adebar ist noch nicht vollständig getestet (bislang nur auf den Geräten des Autors), daher ist Feedback – seien es Erfolgsmeldungen oder Probleme – hochwillkommen: Ich kann das ganze nicht als „produktionsreif“ deklarieren ohne zu wissen, dass es das auch ist