51 votes

La sauvegarde ADB crée un fichier de 0 octet; demande le mot de passe de sauvegarde actuel même si je n'en ai jamais défini un; "Échec de la définition du mot de passe" pour le mot de passe

Le problème :

Chaque fois que j'exécute une sauvegarde ADB, je reçois un message près du bas de l'écran d'accueil disant Démarrage de la sauvegarde..., suivi d'un message disant Sauvegarde terminée quelques secondes plus tard, malgré le fait que j'utilise 17 Go de mémoire sur l'appareil, et que le fichier de sauvegarde résultant est créé avec une taille de 0 octets. Je ne reçois aucun message d'erreur, aucun retour d'information indiquant que quelque chose ne va pas, encore moins ce qui ne va pas. Il semble fonctionner, mais beaucoup trop rapidement, et le fichier de sauvegarde est vide.

Le processus :

  1. Je confirme que l'appareil est reconnu par ADB en utilisant la commande adb devices, et reçois la sortie suivante :

    List of devices attached
    8e1f368a        device
  2. Je lance la commande de sauvegarde ADB (détails à suivre).

  3. Je reçois le message suivant dans l'invite de commande :

    Déverrouillez maintenant votre appareil et confirmez l'opération de sauvegarde.

    ...et la demande suivante sur le téléphone :

    entrer la description de l'image ici

    Cela n'a aucune importance ce que je fais ici (détails à suivre).

  4. Je touche le bouton Sauvegarder mes données (coin inférieur droit).

  5. Le téléphone revient à l'écran d'accueil et affiche le message Démarrage de la sauvegarde..., puis le message Sauvegarde terminée quelques secondes plus tard. Un fichier de 0 octet est créé, nommé soit le backup.ab par défaut, soit ce que j'ai spécifié avec l'interrupteur -f.

La commande de sauvegarde ADB (utilisée à l'étape 2) :

J'ai essayé plusieurs combinaisons d'options, allant du plus simple comme

adb backup -all

à des choses comme

adb backup -all -apk -s 8e1f368a -f 'C:\Data Files\PDA\Backups\ADB\GalaxyS4_20140919.ab'

J'ai aussi essayé d'ajouter l'interrupteur -nosystem après avoir lu cela et cela, qui indiquent qu'essayer d'inclure une sauvegarde système sur un appareil non rooté peut résulter en un fichier de 0 octet, et que cet interrupteur doit être utilisé. Cela ne change rien, le processus se termine toujours en quelques secondes et j'obtiens toujours un fichier de 0 octet.

La demande de mot de passe "Sauvegarde complète" (étape 3) :

Je suis assez sûr de n'avoir jamais défini de mot de passe de sauvegarde auparavant. Je n'ai jamais eu l'occasion de définir ce mot de passe ou d'accéder à ce paramètre de quelque manière que ce soit auparavant. Cependant, j'ai essayé toutes les démarches suivantes :

  • Laisser les deux mots de passe vides
  • Laisser le "mot de passe de sauvegarde actuel" vide et entrer un nouveau mot de passe dans la deuxième case
  • Entrer le PIN de verrouillage actuel de l'écran et tous les PIN que j'ai déjà utilisés dans le passé en tant que "mot de passe de sauvegarde actuel".
  • Entrer tous les mots de passe auxquels je peux penser avoir jamais utilisés pour quoi que ce soit sur cet appareil

Dans tous les cas, le comportement est exactement le même que celui décrit à l'étape 5. Je ne reçois aucune erreur ni aucun type d'indication que quelque chose ne va pas ou que mes mots de passe sont invalides, et aucune indication sur le fait qu'il attend réellement un mot de passe actuel ou que ce champ devrait être laissé vide. (La capture d'écran dans cette réponse et plusieurs autres forums d'assistance que j'ai consultés semblent impliquer que la boîte "mot de passe de sauvegarde actuel" ne serait pas affichée s'il n'y a pas de mot de passe actuel, mais c'est juste une inférence ; rien ne précise clairement si un mot de passe actuel est réellement requis.)

Je soupçonne que le mot de passe demandé pourrait être le "mot de passe de sauvegarde de bureau" défini dans les options pour les développeurs :

entrer la description de l'image ici

Je n'ai jamais défini ce mot de passe auparavant. Si j'essaie d'en définir un, je reçois un message disant Impossible de définir le mot de passe de sauvegarde.

En cherchant des informations sur cette erreur, j'ai rencontré au moins un autre cas où quelqu'un ayant ce problème disait que cela l'empêchait d'utiliser la sauvegarde ADB, mais il n'a pas été précis sur ce qui se passe lorsqu'il essaie d'utiliser ADB backup.

La plupart des personnes qui ont reçu ce message sans jamais avoir défini le mot de passe auparavant disent que la solution a été de laisser le mot de passe actuel vide, mais j'ai essayé cela en premier lieu et ça n'a pas fonctionné. J'ai trouvé une question d'une autre personne ayant rencontré ce problème et étant sûr de ne pas avoir défini le mot de passe auparavant. Malheureusement, il semble qu'il n'ait jamais reçu de solution ou même d'explication.

Peu importe que ADB recherche le "mot de passe de sauvegarde de bureau" ou que le mot de passe de chiffrement ADB soit quelque chose de séparé, je me demande pourquoi ADB exigerait que vous saisissiez un mot de passe précédent pour initier une nouvelle sauvegarde. Je n'essaie pas de restaurer, écraser ou accéder de quelque manière que ce soit à des données chiffrées précédemment, donc même si un mot de passe de chiffrement pour une sauvegarde avait été défini auparavant, je ne peux pas imaginer pourquoi quelqu'un penserait que ce serait une bonne idée de vous empêcher de sauvegarder votre appareil si vous ne vous souvenez pas du mot de passe que vous avez utilisé pour chiffrer les sauvegardes par le passé.

Informations supplémentaires :

Modèle : Samsung Galaxy S4 SCH-I545
Version du noyau : 3.4.0
Version du système d'exploitation : 4.4.2
Version des outils Android SDK : 1.16
Le débogage USB est activé.

Notez que ma raison d'utiliser la sauvegarde ADB est de faire une sauvegarde complète de mon téléphone pour être prudent avant de le rooter* afin que je puisse utiliser des outils de sauvegarde nandroid tels que Titanium backup. Donc, toute suggestion impliquant de rooter mon téléphone serait un cercle vicieux, pas une solution. Inutile de dire qu'une réinitialisation aux paramètres d'usine n'est pas non plus une solution, car cela irait à l'encontre de l'objectif de réaliser la sauvegarde.

Le téléphone est configuré pour se synchroniser avec les serveurs Exchange de mon entreprise, et certaines politiques sont appliquées par le serveur. J'avais pensé que l'appareil était chiffré lorsque j'ai configuré la synchronisation avec le compte de l'entreprise, mais apparemment il n'est actuellement pas chiffré. En fait, c'est ce qui a déclenché cette chaîne d'événements : Je reçois un message me disant que je dois chiffrer l'appareil pour continuer à me connecter aux serveurs de l'entreprise. Je veux faire une sauvegarde nandroid avant de chiffrer, ce qui nécessite le root, et je veux utiliser la sauvegarde ADB avant le rootage.


* Oui, je suis conscient que Towelroot est censé être sûr, mais je préférerais ne pas prendre de risques, et j'aimerais résoudre ou du moins comprendre ce problème au cas où des problèmes similaires surviendraient à l'avenir.

0 votes

J'ai eu plusieurs problèmes avec ADB sur l'une de mes tablettes (rootée ou non, dans les deux cas) qui étaient similaires (juste inversés : tandis que adb backup fonctionnait bien, adb restore échouait toujours). Il s'est avéré que c'était un problème de permission (le fabricant avait altéré la ROM), donc adb restore ne pouvait pas lire le fichier de sauvegarde une fois transféré sur l'appareil. C'était un peu délicat à trouver, et je ne suis pas sûr si quelque chose de similaire est vraiment le cas ici ; mais ça vaut peut-être la peine de vérifier.

2 votes

Pour ceux qui se retrouveraient ici avec le même problème de 0 octet : J'ai eu ce problème car j'avais une fois configuré un mot de passe de bureau dans les paramètres et l'avait oublié. Comme l'appareil est rooté, j'ai suivi cette réponse (la mienne) et tout s'est bien passé.

0 votes

Vous pouvez également consulter : code.google.com/p/android/issues/detail?id=47009 - Si vous avez crypté votre téléphone, vous pourriez avoir besoin d'utiliser votre mot de passe de cryptage comme "mot de passe actuel" dans tous les messages d'avertissement : soit dans l'écran de "Sauvegarde complète", soit dans celui du "Mot de passe de sauvegarde sur bureau".

33voto

Kevinoid Points 501

Réponse courte

Essayez d'utiliser une version antérieure de adb. La version 1.0.32 ne fonctionnait pas pour moi, mais la version 1.0.31 a fonctionné.

Réponse longue

J'ai rencontré ce problème sur un Nexus 5 fonctionnant sous CyanogenMod 11 (basé sur Android 4.4) en utilisant la version actuelle des Outils de plate-forme et de l'ADB (Android Debug Bridge version 1.0.32 Révision eac51f2bb6a8-android).

En utilisant adb logcat pour surveiller les logs de l'appareil, j'ai remarqué qu'après avoir invoqué adb backup -apk -obb -shared -all -nosystem, il y avait des entrées de log suspectes:

V/BackupManagerService(  811): Demande de sauvegarde complète : apks=false obb=false shared=false all=false pkgs=[Ljava.lang.String;@4181ffc8
W/BackupManagerService(  811): Package inconnu  '-apk' '-obb' '-shared' '-all' '-nosystem', saut

Il semble que l'appareil interprète les options de la ligne de commande comme des arguments non optionnels, et produit une erreur car ils ne sont pas des noms de packages installés. Cela m'a fait penser que le protocole adb ou les options d'invocation de commande/service avaient changé sur l'appareil par rapport à l'hôte, alors j'ai essayé une version plus ancienne de adb et voilà, cela a fonctionné.

J'ai fait quelques recherches et suis tombé sur un changement à Use escape_arg in "adb backup", qui fait maintenant que tous les arguments sont mis entre guillemets simples lors de l'invocation de /system/bin/bu backup. Cela explique le comportement et les arguments mis entre guillemets simples dans le message de journal. Cependant, cela ne semble pas correspondre au moment où vous avez rencontré l'erreur. Cela suggérerait également que le problème est beaucoup plus répandu qu'il ne semble l'être. Je suis donc réticent à appeler cela la cause, mais cela peut être un bon point de départ pour une enquête plus approfondie.

2 votes

Utiliser une version antérieure (1.0.31) a résolu mon problème. Cette question stackoverflow.com/q/9555337/1741542 et en particulier cette réponse stackoverflow.com/a/23022718/1741542 m'ont aidé à trouver une version antérieure, par exemple platform-tools_r20-linux.zip.

0 votes

Il semble que cela ne fonctionne pas avec tous les modèles. Alors que j'ai réussi à faire une sauvegarde complète d'un Samsung S3 mini (Android 4.2) sans aucun problème, je n'ai pas pu le faire avec une tablette, qui est sur Android 4.0. J'ai essayé toutes les versions de adb de adb-r10 à adb-r23 (sauf adb-r15) sans succès.

4 votes

J'ai eu un problème similaire avec adb 1.0.32 et un Nexus 5 (Android 6). J'ai résolu cela en mettant explicitement entre guillemets les arguments de sauvegarde, c'est-à-dire en exécutant adb backup '-noapk -noshared -all -nosystem' au lieu de adb backup -noapk -noshared -all -nosystem (à l'intérieur d'un shell bash). Sans les guillemets, je reçois des messages logcat comme celui-ci : 'unknown backup flag -all:-nosystem:-noapk', 'no backup packages supplied and neither -shared nor -all given' et enfin 'Finished.'.

16voto

KroniK907 Points 261

En s'appuyant sur la réponse de kevenoid, cela peut dépendre de la version d'adb qui s'exécute sur le téléphone.

Vous pouvez découvrir quelle version est exécutée sur le téléphone de manière native en faisant ce qui suit:

Tout d'abord, découvrez quelle version vous exécutez sur votre ordinateur de bureau

adb version

Ensuite, ouvrez l'interpréteur de commandes sur votre téléphone

adb shell

Une fois l'interpréteur de commandes ouvert, vous pouvez exécuter

adb version

Ensuite, quittez l'interpréteur de commandes en exécutant

exit

J'ai découvert que mon téléphone exécutait la version 1.0.31 et non 1.0.32 (c'est un samsung note 2)

J'ai essayé d'utiliser des guillemets ou des caractères d'échappement comme l'a montré Hunter, mais rien de tout cela n'a fonctionné à partir de la ligne de commande Windows. Cependant, le fait de rétrograder a permis de résoudre le problème d'incompatibilité entre les deux versions.

J'ai pu trouver l'ancienne version en suivant les instructions ici: https://stackoverflow.com/a/23022718/1741542

Le lien de téléchargement que j'ai utilisé était :
http://dl-ssl.google.com/android/repository/platform-tools_r20-windows.zip

Autres plateformes:

0 votes

Y a-t-il un moyen de mettre à jour la version adb sur le téléphone ?

1 votes

10voto

Lyubomyr Dutko Points 1266

Les autres réponses concernant la cotation des arguments de la commande sont exactes. J'ai constaté que si vous échappez les espaces entre les arguments, cela fonctionne.

Comme ceci : adb backup -apk\ -shared\ -all\ -system

0 votes

Cela peut ne pas être la solution au problème de l'OP, mais c'est une meilleure solution au problème de @Kevinoid que d'utiliser un ancien ADB, qui n'a pas fonctionné pour moi.

0 votes

Ceci est un duplicata de la réponse de Kevinoid sans la justification. Cependant, cela a bien fonctionné pour moi et je préfère utiliser \ au lieu de '

1 votes

Cette solution a fonctionné pour moi, pas besoin de rétrograder adb

7voto

TWiStErRob Points 321

Aucune des solutions de contournement n'a fonctionné pour moi ici, et je ne veux pas rétrograder mes outils SDK. Voici ce que j'ai trouvé : passez adb backup sur l'ordinateur et allez directement sur l'appareil via adb shell.

$ adb version
Version de l'Android Debug Bridge 1.0.35
Révision 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

Cela appelle /system/bin/bu et envoie le fichier de sauvegarde sur STDOUT (descripteur de fichier n°1). Les paramètres sont les mêmes adb backup -> bu 1 backup . La sortie est redirigée vers un fichier sur l'appareil et peut ensuite être extraite comme n'importe quel fichier.

Le seul inconvénient est que vous ne pouvez pas effectuer une sauvegarde complète si votre appareil est rempli à plus de la moitié. Cela peut être contourné si vous avez un emplacement pour carte Sd externe. bu peut écrire là-bas même sur Android 4.4.2, car c'est une application système. /mnt/extSdCard/backup.ab a fonctionné de la même manière pour moi que /sdcard.

0 votes

bu 1 sauvegarde -apk app.package.name > /sdcard/backup.ab crée un fichier vide de 47 octets dans mon cas.

2 votes

@user2284570 ouais, j'ai eu récemment une expérience similaire (fichier ab vide) sur Android 9. Je pense qu'à l'époque, c'était simplement cassé (0 octets), mais maintenant ils ont restreint davantage l'accès, et il sera également supprimé, voir link.medium.com/4edL3pBnolb

4voto

Matt Points 141

soupir Je suis vraiment désolé si c'est le cas, et vous semblez être attentif à en juger par vos captures d'écran et les lignes de commande, mais j'ai découvert à ma grande honte les mêmes symptômes et j'ai pensé poster au cas où des futurs découvreurs viendraient ici. Il s'avère que adb est très pointilleux sur les tirets simples ou doubles dans ses options. Pour moi, les double tirets reproduisaient exactement ce cas: même invite sur le téléphone, même fichier de 0 octet. Les tirets simples même s'il y a des noms d'arguments longs ont fonctionné à merveille.

En cas d'importance, mon téléphone est un Samsung Galaxy Note 2 AT&T SGH-i317 fonctionnant sous Android 5.1/Cyanogenmod 12.1.

3 votes

Je suis un peu confus quant à savoir si cela devrait être publié en tant que réponse ou commentaire. L'OP montre qu'il utilise un tiret simple, pas un tiret double, donc votre réponse a probablement manqué le point. J'admets que cette réponse est informative (valeur ajoutée), mais ne semble pas répondre au problème de l'OP.

0 votes

Cela a résolu mon problème.

0 votes

Veuillez publier vos lignes de commande actuelles.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X