Jedes Mal, wenn ich eine ADB-Sicherung ausführe, erhalte ich eine Meldung am unteren Rand des Startbildschirms mit der Aufschrift Backup starting...
, gefolgt von einer Meldung Backup finished
einige Sekunden später , obwohl ich 17 GB Gerätespeicher verwende und die resultierende Sicherungsdatei erstellt wird mit einer Größe von 0 Byte. Ich erhalte keine Fehlermeldungen, keinerlei Rückmeldungen, die darauf hindeuten , dass etwas nicht stimmt, geschweige denn, was nicht stimmt. Es scheint zu funktionieren, aber viel zu schnell, und die Sicherungsdatei ist leer.
Ich bestätige, dass das Gerät von ADB mit dem adb devices
Befehl erkannt wird, und erhalte die folgende Ausgabe:
List of devices attached
8e1f368a device
Ich gebe den ADB-Sicherungsbefehl aus (Details folgen).
An der Eingabeaufforderung erhalte ich folgende Meldung:
Now unlock your device and confirm the backup operation.
...und folgende Aufforderung am Telefon:
Es spielt keine Rolle, was ich hier mache (Details folgen).
Ich tippe auf die Back up my dataSchaltfläche (untere rechte Ecke).
Das Telefon kehrt zum Startbildschirm zurück und zeigt mir die Backup starting...
Nachricht und Backup finished
einige Sekunden später die Nachricht an. Eine 0-Byte-Datei wird erstellt, die entweder die Standard -backup.ab oder was auch immer ich mit dem Schalter -f angegeben habe, benannt wird.
Ich habe mehrere Kombinationen von Optionen ausprobiert, von so einfach wie
adb backup -all
zu Dingen wie
adb backup -all -apk -s 8e1f368a -f 'C:\Data Files\PDA\Backups\ADB\GalaxyS4_20140919.ab'
Ich habe auch versucht, den -nosystem
Schalter nach dem Lesen von this und this hinzuzufügen , was darauf hinweist, dass der Versuch, eine Systemsicherung auf einem nicht gerooteten Gerät einzuschließen, zu einer 0-Byte-Datei führen kann und dass dieser Schalter verwendet werden muss. Es macht keinen Unterschied, der Vorgang ist immer noch in Sekundenschnelle abgeschlossen und ich erhalte immer noch eine 0-Byte-Datei.
Ich bin mir ziemlich sicher, dass ich noch nie zuvor ein Backup-Passwort festgelegt habe. Ich hatte noch nie die Gelegenheit, dieses Passwort festzulegen oder auf diese Einstellung in irgendeiner Weise zuzugreifen. Allerdings habe ich schon alles versucht:
In allen Fällen ist das Verhalten genau das gleiche wie in Schritt 5 beschrieben. Ich erhalte keine Fehlermeldungen oder Hinweise darauf, dass etwas nicht stimmt oder dass meine Passwörter ungültig sind, und keinen Hinweis darauf, ob tatsächlich ein aktuelles Passwort erwartet wird oder ob das der Fall ist Feld sollte leer bleiben. (Der Screenshot in dieser Antwort und mehreren anderen Support-Foren, die ich mir angesehen habe, scheint zu implizieren, dass das Feld "Aktuelles Backup-Passwort" nicht angezeigt wird, wenn kein aktuelles Passwort vorhanden ist, aber das ist nur eine Schlussfolgerung; nichts macht klar ob ein aktuelles Passwort ist eigentlich erforderlich.)
Ich vermute, dass das Passwort, nach dem es gefragt wird, das in den Entwickleroptionen festgelegte "Desktop-Backup-Passwort" sein könnte:
Ich habe dieses Passwort noch nie gesetzt. Wenn ich versuche, einen einzustellen, bekomme ich eine MeldungFailed to set backup password.
Bei der Suche nach Informationen zu diesem Fehler bin ich auf mindestens einen anderen Fall gestoßen, in dem jemand, der dieses Problem hatte, sagte, dies hindere ihn daran, ADB-Backup zu verwenden, aber er war nicht genau darüber, was passiert, wenn er versucht, ADB zu verwenden Sicherung.
Die meisten Leute, die diese Nachricht erhalten haben, ohne zuvor das Passwort festgelegt zu haben, sagen, dass die Lösung darin bestand, das aktuelle Passwort leer zu lassen, aber ich habe das zuerst versucht und es hat nicht funktioniert. Ich habe eine Frage von einer anderen Person gefunden, die auf dieses Problem gestoßen ist, und war sich sicher, dass er das Passwort noch nie zuvor festgelegt hatte . Leider sieht es nicht so aus, als hätte er jemals eine Lösung oder gar eine Erklärung bekommen.
Unabhängig davon, ob ADB nach dem „Desktop-Backup-Passwort“ sucht oder das ADB-Verschlüsselungspasswort etwas anderes ist, ist es mir schleierhaft, warum ADB Sie auffordern würde, ein vorheriges Passwort einzugeben, um ein neues Backup zu initiieren. Ich versuche nicht, zuvor verschlüsselte Daten wiederherzustellen, zu überschreiben oder in irgendeiner Weise darauf zuzugreifen. Selbst wenn zuvor ein Verschlüsselungskennwort für ein Backup festgelegt wurde, kann ich mir nicht vorstellen, warum jemand denken sollte, dass es eine gute Idee ist, Sie daran zu hindern Sichern Sie Ihr Gerät, wenn Sie sich nicht mehr erinnern, welches Passwort Sie in der Vergangenheit zum Verschlüsseln von Sicherungen verwendet haben.
Modell: Samsung Galaxy S4 SCH-I545
Kernel-Version: 3.4.0
OS-Version: 4.4.2
Android SDK Tools-Version: 1.16
USB-Debugging ist aktiviert.
Beachten Sie, dass mein Grund für die Verwendung von ADB-Backup darin besteht, ein vollständiges Backup meines Telefons zu erstellen, um auf der sicheren Seite zu sein, bevor ich es roote*, damit ich Nandroid-Backup-Tools wie Titanium Backup verwenden kann. Jeder Vorschlag, mein Telefon zu rooten, wäre also ein Catch-22, keine Lösung. Natürlich ist auch ein Zurücksetzen auf die Werkseinstellungen keine Lösung, da dies den gesamten Zweck der Durchführung des Backups zunichte machen würde.
Das Telefon ist für die Synchronisierung mit den Exchange-Servern meines Unternehmens eingerichtet, und der Server erzwingt einige Richtlinien. Ich hatte gedacht, dass das Gerät verschlüsselt war, als ich die Synchronisierung mit dem Unternehmenskonto zum ersten Mal eingerichtet habe, aber anscheinend ist es derzeit nicht verschlüsselt. Genau das hat diese Kette von Ereignissen in Gang gesetzt: Ich erhalte eine Nachricht, die mir mitteilt, dass ich das Gerät verschlüsseln muss, um weiterhin eine Verbindung zu Unternehmensservern herzustellen. Ich möchte vor dem Verschlüsseln ein Nandroid-Backup erstellen, was Rooten erfordert, und ich möchte vor dem Rooten ein ADB-Backup verwenden.
* Ja, mir ist bewusst, dass Towelroot angeblich sicher ist, aber ich möchte lieber kein Risiko eingehen, und ich möchte dieses Problem lösen oder zumindest verstehen, falls in Zukunft ähnliche Probleme auftreten.
Versuchen Sie es mit einer früheren Version von adb. 1.0.32 hat bei mir nicht funktioniert, aber 1.0.31 hat es getan.
Ich habe dieses Problem gerade auf einem Nexus 5 festgestellt, auf dem CyanogenMod 11 (basierend auf Android 4.4) mit der aktuellen Version der Plattformtools und ADB (Android Debug Bridge Version 1.0.32 Revision eac51f2bb6a8-android) ausgeführt wird.
Beim Ansehen adb logcat
der Geräteprotokolle bemerkte ich, dass nach dem Aufrufen adb backup -apk -obb -shared -all -nosystem
einige verdächtige Protokolleinträge vorhanden waren:
V/BackupManagerService( 811): Requesting full backup: apks=false obb=false shared=false all=false pkgs=[Ljava.lang.String;@4181ffc8
W/BackupManagerService( 811): Unknown package '-apk' '-obb' '-shared' '-all' '-nosystem', skipping
Wo es scheint, dass das Gerät die Befehlszeilenoptionen als Nicht-Optionsargumente interpretiert und einen Fehler erzeugt, weil es sich nicht um installierte Paketnamen handelt. Dies ließ mich vermuten, dass sich das adb-Protokoll oder die Befehls-/Dienstaufrufoptionen auf dem Gerät relativ zum Host geändert hatten, also versuchte ich es mit einer älteren Version von adb und voilà, es funktionierte.
Ich habe ein bisschen gegraben und bin auf eine Änderung zu Use escape_arg in "adb backup" gestoßen , die jetzt dazu führt, dass alle Argumente beim Aufrufen in einfache Anführungszeichen gesetzt werden /system/bin/bu backup
. Dies erklärt das Verhalten und die Argumente in einfachen Anführungszeichen in der Protokollnachricht. Es scheint jedoch nicht mit der Zeit übereinzustimmen, zu der Sie auf den Fehler gestoßen sind. Es würde auch darauf hindeuten, dass das Problem viel weiter verbreitet ist, als es den Anschein hat. Daher zögere ich, dies als Ursache zu bezeichnen, aber es kann ein guter Ausgangspunkt für weitere Untersuchungen sein.
adb backup '-noapk -noshared -all -nosystem'
statt adb backup -noapk -noshared -all -nosystem
(innerhalb einer Bash-Shell) ausgeführt habe. Ohne die Anführungszeichen bekomme ich Logcat-Meldungen wie diese: 'unbekanntes Backup-Flag -all:-nosystem:-noapk', 'keine Backup-Pakete bereitgestellt und weder -shared noch -all given' und schließlich 'Fertig.'.-all
ohne verwendet hätte -shared
(was auch funktioniert hätte). Ich habe diese Meldungen in der Protokolldatei gesehen: BackupManagerService: Calling doFullBackup() on com.android.sharedstoragebackup
/ SharedStorageAgent: Backing up 1 shared volumes
/FullBackup: Unrecognized domain shared/0
Aufbauend auf der Antwort von kevenoid kann es davon abhängen, welche Version von adb auf dem Telefon ausgeführt wird.
Sie können herausfinden, welche Version auf dem Telefon nativ ausgeführt wird, indem Sie Folgendes tun:
Finden Sie zuerst heraus, welche Version Sie auf Ihrem Desktop ausführen
adb version
Öffnen Sie dann die Shell auf Ihrem Telefon
adb shell
Sobald die Shell geöffnet ist, können Sie laufen
adb version
Beenden Sie dann die Shell, indem Sie sie ausführen
exit
Ich habe festgestellt, dass auf meinem Telefon Version 1.0.31 und nicht 1.0.32 ausgeführt wird (es ist ein Samsung Note 2).
Ich habe versucht, Anführungszeichen oder Escape-Zeichen zu verwenden, wie Hunter es gezeigt hat, aber keines davon funktionierte über die Windows-Befehlszeile. Das Downgrade hat jedoch das Inkompatibilitätsproblem zwischen den beiden Versionen behoben.
Ich konnte die ältere Version anhand der Anweisungen hier finden: https://stackoverflow.com/a/23022718/1741542
Der von mir verwendete Download-Link war:
http://dl-ssl.google.com/android/repository/platform-tools_r20-windows.zip
Andere Plattformen:
Die anderen Antworten zu den zitierten Befehlsargumenten sind korrekt. Ich habe festgestellt, dass es funktioniert, wenn Sie die Leerzeichen zwischen den Argumenten umgehen.
So was:adb backup -apk\ -shared\ -all\ -system
Keine der Problemumgehungen hat hier für mich funktioniert, und ich möchte meine SDK-Tools nicht herabstufen. Folgendes habe ich mir ausgedacht: Überspringen adb backup
Sie den Computer und gehen Sie direkt zum Gerät über adb shell
.
$adb version
Android Debug Bridge version 1.0.35
Revision fc2a139a55f5-android
$ adb shell
shell@jflte:/ $ bu 1 backup -apk app.package.name > /sdcard/backup.ab
shell@jflte:/ $ exit
$adb pull /sdcard/backup.ab
[100%] /sdcard/backup.ab
Dadurch /system/bin/bu
wird die Sicherungsdatei auf STDOUT (Dateideskriptor Nr. 1) aufgerufen und abgelegt. Parameter sind die gleichen adb backup <params>
-> bu 1 backup <params>
. Die Ausgabe wird in eine Datei auf dem Gerät umgeleitet und kann dann wie jede andere Datei abgerufen werden.
Der einzige Nachteil ist, dass Sie keine vollständige Sicherung durchführen können, wenn Ihr Gerät mehr als halb voll ist. Dies kann umgangen werden, wenn Sie einen externen SdCard-Steckplatz haben. bu
Kann dort sogar auf Android 4.4.2 schreiben, da es sich um eine System-App handelt. /mnt/extSdCard/backup.ab
hat bei mir genauso funktioniert wie /sdcard
.
bu 1 backup -apk app.package.name > /sdcard/backup.ab
erstellt in meinem Fall eine leere 47-Byte-Datei.seufz Es tut mir wirklich leid, wenn dies der Fall ist, und Sie scheinen vorsichtig zu sein, wenn Sie nach Ihren Screenshots und Befehlszeilen urteilen, aber ich habe zu meinem Leidwesen die gleichen Symptome entdeckt und dachte, ich würde nur für den Fall posten, dass zukünftige Entdecker es hierher schaffen. Es stellt sich heraus, dass adb in seinen Optionen sehr wählerisch ist, wenn es um einzelne oder doppelte Bindestriche geht. Für mich haben doppelte Bindestriche diesen Fall genau reproduziert: dieselbe Eingabeaufforderung am Telefon, dieselbe 0-Byte-Datei. Einzelne Bindestriche , obwohl es lange Argumentnamen gibt, wirkten wie ein Zauber.
Falls es darauf ankommt, mein Handy ist ein Samsung Galazy Note 2 AT&T SGH-i317 mit Android 5.1/Cyanogenmod 12.1.
Sie müssen den Befehl adb backup auf der adb-Version 1.0.31 ausführen.
Für Windows habe ich getan:
Protokoll:
$ adb backup -apk -obb -shared -all -system -f bckp.ab
Der Adb-Server ist veraltet. Tötung...
Entsperren Sie nun Ihr Gerät und bestätigen Sie den Sicherungsvorgang.
...dann alles wieder normal machen.
OK, so habe ich meine repariert.
Ich habe die Lösung von Hunter Perrin ausprobiert:
adb backup -apk\ -shared\ -all\ -system
Aber es kam sofort ohne Fehler zurück, kein Backup-Bildschirm auf dem Telefon.
Durch Versuch und Irrtum hat dies für mich funktioniert:
adb backup -all\
Ich glaube, ich habe eine Lösung für diejenigen, die 1.0.32 verwenden:
Geben Sie ein Passwort ein, wenn Sie auf dem Android-Bildschirm dazu aufgefordert werden
Trotz der Tatsache, dass es das Standardpasswort verwenden wird, wenn Sie keins eingeben, glaube ich, dass dies nicht der Fall ist, und adb 1.0.32 erlaubt möglicherweise nicht die Erstellung unverschlüsselter Backups.
Die Eingabe eines Passworts hat bei mir funktioniert, dann habe ich "Android Backup Extractor" (Warning Sourceforge) und "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" verwendet, um es in eine tar-Datei zu extrahieren.
Ich bin auf das umgekehrte Problem gestoßen: 1.0.31 mit einem neueren Telefon (Android 7) schlägt ebenfalls fehl. 1.0.31 verwendet : als Trennzeichen bei der Übergabe von Argumenten an das Telefon. Wie adb logcat -s BackupManagerService
man sieht, kann das neuere adb auf dem Telefon auch nicht mit dem alten Stil umgehen: 02-19 01:59:44.330 1100 9830 W BackupManagerService: Unknown package com.gameloft.android.ANMP.GloftPOHM:-apk, skipping
Glücklicherweise akzeptiert das neuere adb auch Leerzeichen als Trennzeichen, sodass das Einschließen der Argumente in doppelte Anführungszeichen funktioniert, z.adb.exe backup "com.gameloft.android.ANMP.GloftPOHM -apk" -f game-backup.ab
Bei mir war es so, dass der Paketname geändert wurde, ich ihn also adb backup
nicht fand und eine leere Sicherungsdatei erstellte, ohne einen Fehler zu melden . adb logcat
zeigte den Fehler. Nachdem ich den Paketnamen aktualisiert hatte, war adb backup
es erfolgreich.
Dies verwendete ADB Version 1.0.41 mit aktiviertem Desktop-Backup-Passwort.
Izzy
adb backup
funktionierte zwar gut,adb restore
schlug aber immer fehl). Es stellte sich heraus, dass es sich um ein Berechtigungsproblem handelte (der Hersteller hatte das ROM vermasselt), sodassadb restore
die Sicherungsdatei nach der Übertragung auf das Gerät nicht gelesen werden konnte. War etwas schwierig zu finden, und ich bin mir nicht sicher, ob hier wirklich etwas Ähnliches der Fall ist; aber es könnte sich lohnen zu prüfen.Feuerlord
Marco Leogrande