ADB-Sicherung erstellt 0-Byte-Datei; fordert zur Eingabe des aktuellen Backup-Passworts auf, obwohl ich nie eines festgelegt habe; „Kennwort konnte nicht festgelegt werden“ für das Desktop-Sicherungskennwort

Das Problem:

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.

Der Prozess:

  1. Ich bestätige, dass das Gerät von ADB mit dem adb devicesBefehl erkannt wird, und erhalte die folgende Ausgabe:

    List of devices attached
    8e1f368a        device
    
  2. Ich gebe den ADB-Sicherungsbefehl aus (Details folgen).

  3. An der Eingabeaufforderung erhalte ich folgende Meldung:

    Now unlock your device and confirm the backup operation.
    

    ...und folgende Aufforderung am Telefon:

    Geben Sie hier die Bildbeschreibung ein

    Es spielt keine Rolle, was ich hier mache (Details folgen).

  4. Ich tippe auf die Back up my dataSchaltfläche (untere rechte Ecke).

  5. Das Telefon kehrt zum Startbildschirm zurück und zeigt mir die Backup starting...Nachricht und Backup finishedeinige 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.

Der ADB-Sicherungsbefehl (in Schritt 2 verwendet):

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 -nosystemSchalter 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.

Die Passwortabfrage „Vollständige Sicherung“ (Schritt 3):

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:

  • Lassen Sie beide Passwörter leer
  • Lassen Sie das "aktuelle Backup-Passwort" leer und geben Sie ein neues Passwort in das zweite Feld ein
  • Eingabe der aktuellen Bildschirmsperr-PIN und aller PINs, die ich jemals in der Vergangenheit verwendet habe, als "aktuelles Backup-Passwort".
  • Ich gebe jedes Passwort ein, das ich mir vorstellen kann und das ich jemals für irgendetwas auf diesem Gerät verwendet hätte

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:

Geben Sie hier die Bildbeschreibung ein

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.

Weitere Informationen:

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.

Ich hatte mehrere Probleme mit ADB auf einem meiner Tablets (in beiden Fällen gerootet oder nicht), die ähnlich waren (nur umgekehrt: adb backupfunktionierte zwar gut, adb restoreschlug aber immer fehl). Es stellte sich heraus, dass es sich um ein Berechtigungsproblem handelte (der Hersteller hatte das ROM vermasselt), sodass adb restoredie 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.
Für diejenigen, die hier mit demselben 0-Byte-Problem enden würden: Ich hatte dieses Problem, weil ich einmal ein Desktop-Passwort unter Einstellungen eingerichtet und es vergessen hatte. Da das Gerät gerootet ist, bin ich dieser Antwort (meiner) gefolgt und alles lief gut.
Sie können sich auch Folgendes ansehen: code.google.com/p/android/issues/detail?id=47009 - Wenn Sie Ihr Telefon verschlüsselt haben, müssen Sie möglicherweise Ihr Verschlüsselungspasswort als "aktuelles Passwort" in allen Eingabeaufforderungen verwenden: entweder im Bildschirm „Vollständiges Backup“ oder im Bildschirm „Desktop-Backup-Passwort“.

Antworten (10)

Kurze Antwort

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.

Lange Antwort

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 logcatder Geräteprotokolle bemerkte ich, dass nach dem Aufrufen adb backup -apk -obb -shared -all -nosystemeinige 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.

Die Verwendung einer früheren Version (1.0.31) hat mein Problem gelöst. Diese Frage stackoverflow.com/q/9555337/1741542 und insbesondere diese Antwort stackoverflow.com/a/23022718/1741542 hat mir geholfen, eine frühere Version zu finden, zB platform-tools_r20-linux.zip.
Scheint aber nicht bei allen Modellen zu funktionieren. Während ich problemlos ein vollständiges Backup eines Samsung S3 mini (Android 4.2) erstellt habe, war dies bei einem Tablet mit Android 4.0 nicht möglich. Ich habe alles von adb-r10 bis adb-r23 (außer adb-r15) ohne Erfolg ausprobiert.
Ich hatte ein ähnliches Problem mit adb 1.0.32 und einem Nexus 5 (Android 6). Ich habe dies gelöst, indem ich die Backup-Argumente explizit in Anführungszeichen gesetzt habe, dh 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.'.
Endlich habe ich auch mit Android 4.0 ein vollständiges Backup bekommen. Dummkopf, es war nur ein Neustart des Tablets, der mich in Gang gebracht hat.
Ja, das Modell/Betriebssystem spielt definitiv eine Rolle, Galaxy S5 auf Lollipop funktionierte gut mit 1.0.32, aber Nexus 7 auf Kit Kat benötigte 1.0.31, um zu funktionieren.
Toll! Funktionierte perfekt mit 1.0.32 auf einem Lollipop Android One-Gerät.
Eigentlich nehme ich das zurück. Das Backup enthält keine der freigegebenen Daten, nur die App-Daten, so als ob ich -allohne 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
Ich werde bestätigen, dass 1.0.31 auch mein Problem gelöst hat. Ich habe die Antwort hier verwendet, um die ältere Version zu finden: stackoverflow.com/questions/24619607/…
Danke! Übrigens können Sie adb 1.0.31 für alle Plattformen hier herunterladen: ftp.mozilla.org/pub/labs/r2d2b2g
Wenn ich das richtig verstehe, sollte ich in der Lage sein, ein Backup von jeder Version von adb wiederherzustellen, nicht nur von der frühen Version, mit der ich das Backup erstellt habe?

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:

Gibt es eine Möglichkeit, die adb-Version auf dem Telefon zu aktualisieren?

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

Dies ist möglicherweise nicht die Lösung für das Problem von OP, aber es ist eine bessere Lösung für das Problem von @Kevinoid als die Verwendung einer älteren ADB, die bei mir nicht funktioniert hat.
Dies ist ein Duplikat von Kevinoids Antwort ohne Begründung. Es hat jedoch gut für mich funktioniert, und ich bevorzuge die Verwendung von \ zu '
Diese Lösung hat bei mir funktioniert, kein Downgrade von adb erforderlich
Ich kann den Verdacht von @HunterPerrin bestätigen, dass dies ein anderes Problem ist, weil ich dies zuerst versucht habe und es mein Problem nicht gelöst hat, aber als ich zu 1.0.31 adb ging, begann es korrekt zu kopieren

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 backupSie 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/buwird 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. buKann dort sogar auf Android 4.4.2 schreiben, da es sich um eine System-App handelt. /mnt/extSdCard/backup.abhat bei mir genauso funktioniert wie /sdcard.

bu 1 backup -apk app.package.name > /sdcard/backup.aberstellt in meinem Fall eine leere 47-Byte-Datei.
@ user2284570 ja, ich hatte kürzlich eine ähnliche Erfahrung (leere ab-Datei) auf Android 9. Ich denke zurück an den Tag, an dem es einfach kaputt war (0 Bytes), aber jetzt haben sie weiter eingeschränkten Zugriff und es wird auch entfernt, siehe link.medium.com/4edL3pBnolb

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.

Ich bin etwas verwirrt, ob dies stattdessen als Antwort oder Kommentar gepostet werden sollte. OP zeigt, dass er einen Strich und keinen Doppelstrich verwendet, sodass Ihre Antwort wahrscheinlich das Ziel verfehlt hat. Ich gebe zu, diese Antwort ist informativ (Zusatzwert), scheint das Problem von OP jedoch nicht zu beantworten.
Dies löste mein Problem.
Bitte posten Sie Ihre tatsächlichen Befehlszeilen.

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...

  • Daemon erfolgreich gestartet *

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 BackupManagerServiceman 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, skippingGlü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 backupnicht fand und eine leere Sicherungsdatei erstellte, ohne einen Fehler zu melden . adb logcatzeigte den Fehler. Nachdem ich den Paketnamen aktualisiert hatte, war adb backupes erfolgreich.

Dies verwendete ADB Version 1.0.41 mit aktiviertem Desktop-Backup-Passwort.