Le problème:

Chaque fois que j'exécute la sauvegarde ADB, un message apparaît au bas de l'écran d'accueil Backup starting..., suivi d'un message Backup finished quelques secondes plus tard malgré le fait que j'utilise 17 Go de mémoire de périphérique et le fichier de sauvegarde résultant est créé. avec une taille de 0 octet. Je ne reçois aucun message d'erreur, aucun retour indiquant que quelque chose ne va pas, sans parler de ce qui ne va pas. Cela semble fonctionner, mais beaucoup trop rapidement, et le fichier de sauvegarde est vide.

Le processus:

1. Je confirme que le périphérique est reconnu par ADB à l'aide de la adb devicescommande et reçois le résultat suivant:

   List of devices attached
   8e1f368a        device
   

2. J'émets la commande de sauvegarde ADB (détails à suivre).

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

   Now unlock your device and confirm the backup operation.
   

   ... et l'invite suivante sur le téléphone:

   

   Cela ne fait aucune différence avec ce que je fais ici (détails à suivre).

4. Je tape le Back up my databouton (coin inférieur droit).

5. Le téléphone revient à l'écran d'accueil et me montre le Backup starting...message, puis le Backup finishedmessage quelques secondes plus tard. Un fichier de 0 octet est créé, nommé soit le fichier backup.ab par défaut, soit ce que j'ai spécifié avec le commutateur -f .

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

J'ai essayé plusieurs combinaisons d'options, allant d'aussi simple que

adb backup -all

à des choses comme

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

J'ai également essayé d'ajouter le -nosystemcommutateur après avoir lu ceci et cela , ce qui indique qu'essayer d'inclure une sauvegarde système sur un périphérique non enraciné peut entraîner un fichier de 0 octet et que ce commutateur doit être utilisé. Cela ne fait aucune différence, le processus se termine toujours en quelques secondes et je reçois toujours un fichier de 0 octet.

L'invite de mot de passe "Sauvegarde complète" (étape 3):

Je suis sûr que je n'ai 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 solutions suivantes:

• Laisser les deux mots de passe en blanc
• Laisser le "mot de passe de sauvegarde actuel" vide et entrer un nouveau mot de passe dans la deuxième case
• Saisie du code PIN de verrouillage d'écran actuel et de tous les codes PIN que j'ai déjà utilisés comme "mot de passe de sauvegarde actuel".
• Saisie de tous les mots de passe auxquels je peux penser que j'aurais jamais utilisés pour quoi que ce soit sur cet appareil

Dans tous les cas, le comportement est identique à celui décrit à l'étape 5. Je ne reçois aucune erreur ni aucune indication que quelque chose ne va pas ou que mes mots de passe ne sont pas valides, et aucun indice quant à savoir s'il attend réellement un mot de passe actuel ou si champ doit être laissé en blanc. (La capture d'écran de cette réponse et de plusieurs autres forums d'assistance consultés semble indiquer que la case "Mot de passe de sauvegarde actuel" ne s'affiche pas s'il n'y a pas de mot de passe actuel, mais il ne s'agit que d'une inférence; rien ne permet de savoir si un mot de passe actuel est requis.)

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

Je n'ai jamais défini ce mot de passe auparavant. Si j'essaie d'en définir un, je reçois un message disantFailed to set backup password.

En cherchant des informations sur cette erreur, j'ai rencontré au moins un autre cas dans lequel quelqu'un qui avait ce problème avait déclaré que cela l'empêchait d'utiliser la sauvegarde ADB, mais il n'était pas précis sur ce qu'il se passait lorsqu'il essayait d'utiliser ADB. sauvegarde.

La plupart des personnes qui ont reçu ce message, n'ayant jamais défini le mot de passe auparavant, disent que la solution consistait à laisser le mot de passe actuel vide, mais j'ai essayé cela au départ et cela n'a pas fonctionné. J'ai trouvé une question posée par une autre personne qui rencontrait ce problème et j'étais sûre qu'il n'avait pas encore défini le mot de passe . Malheureusement, il ne semble pas avoir jamais eu une solution ni même une explication.

Indépendamment du fait que ADB recherche le "mot de passe de sauvegarde sur le bureau" ou que le mot de passe de cryptage ADB soit quelque chose de séparé, je ne comprends pas pourquoi ADB vous demanderait de saisir un mot de passe précédent pour lancer une nouvelle sauvegarde. Je n'essaie pas de restaurer, d'écraser ou d'accéder de quelque manière que ce soit aux données précédemment cryptées. Même si un mot de passe de cryptage pour une sauvegarde avait déjà été défini, je ne vois pas pourquoi quelqu'un penserait que c'est une bonne idée de vous en empêcher sauvegarder votre appareil si vous ne vous souvenez plus du mot de passe que vous avez utilisé pour chiffrer les sauvegardes dans le passé.

Information additionnelle:

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

Notez que la raison de mon utilisation de la sauvegarde ADB est d’effectuer une sauvegarde complète de mon téléphone afin de la sécuriser avant de l’enraciner * afin que je puisse utiliser des outils de sauvegarde nandroid tels que la sauvegarde Titanium. Donc, toute suggestion impliquant l'enracinement de mon téléphone serait un piège à 22, pas une solution. Il va sans dire que la réinitialisation des paramètres d'usine n'est pas non plus une solution, car cela irait à l'encontre du but de la sauvegarde.

Le téléphone est configuré pour se synchroniser avec les serveurs Exchange de mon entreprise et certaines règles sont appliquées par le serveur. J'avais pensé que le périphérique était crypté lors de la configuration initiale de la synchronisation avec le compte de l'entreprise, mais apparemment, il n'est pas crypté pour le moment. En fait, c'est ce qui a mis cette chaîne d'événements en mouvement: je reçois un message m'indiquant que je dois chiffrer le périphérique pour pouvoir continuer à vous connecter aux serveurs de l'entreprise. Je souhaite effectuer une sauvegarde nandroid avant le cryptage, ce qui nécessite un enracinement, et je souhaite utiliser la sauvegarde ADB avant l’enracinement.

_{* Oui, je suis conscient que Towelroot est censé être sûr, mais je préfère ne pas prendre de risques, et j'aimerais résoudre ou au moins comprendre ce problème si des problèmes liés à une affaire se posent à l'avenir.}

Réponse courte

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

Longue réponse

Je viens de rencontrer ce problème sur un Nexus 5 exécutant CyanogenMod 11 (basé sur Android 4.4) à l'aide de la version actuelle de Platform Tools et ADB (version 1.0.32 d'Android Debug Bridge révisée eac51f2bb6a8-android).

En adb logcatobservant les journaux de l'appareil, j'ai remarqué qu'après avoir appelé adb backup -apk -obb -shared -all -nosystemcertaines entrées de journal suspectes:

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

Il semble que le périphérique interprète les options de ligne de commande en tant qu'arguments non optionnels et génère une erreur car il ne s'agit pas de noms de packages installés. Cela m'a fait soupçonner que le protocole adb ou que les options d'invocation de commande / service avaient changé sur le périphérique par rapport à l'hôte, j'ai donc essayé une version plus ancienne de adb et voilà, cela a fonctionné.

J'ai creusé un peu et je suis tombé sur une modification apportée à l' utilisation de escape_arg dans "adb backup" , qui fait désormais figurer tous les arguments entre guillemets simples lors de l'appel /system/bin/bu backup. Cela explique le comportement et les arguments entre guillemets dans le message de journal. Cependant, il ne semble pas correspondre à l'heure à laquelle vous avez rencontré l'erreur. Cela suggérerait également que la question soit beaucoup plus répandue qu’elle ne le semble. J’hésite donc à appeler cela la cause, mais c’est peut-être un bon point de départ pour une enquête plus approfondie.

En se basant sur la réponse de kevenoid, cela peut dépendre de la version d’adb en cours d’exécution sur le téléphone.

Pour savoir quelle version du téléphone fonctionne en mode natif, procédez comme suit:

Commencez par rechercher la version que vous utilisez sur votre bureau.

adb version

Ensuite, ouvrez la coque sur votre téléphone

adb shell

Une fois que le shell est ouvert, vous pouvez exécuter

adb version

Puis quittez le shell en exécutant

exit

J'ai trouvé que mon téléphone fonctionnait sous la version 1.0.31 et non pas 1.0.32 (c'est une note 2 de samsung)

J'ai essayé d'utiliser des guillemets ou des caractères d'échappement comme l'a montré Hunter, mais aucun de ceux-ci n'a fonctionné à partir de la ligne de commande de Windows. Cependant, le déclassement a résolu 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 le suivant:
http://dl-ssl.google.com/android/repository/platform-tools_r20-windows.zip

Autres plateformes:

• http://dl-ssl.google.com/android/repository/platform-tools_r20-macosx.zip

  http://dl-ssl.google.com/android/repository/platform-tools_r20-linux.zip

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

Comme ça: adb backup -apk\ -shared\ -all\ -system

Aucune des solutions de contournement n'a fonctionné pour moi ici, et je ne veux pas rétrograder mes outils SDK. Voici ce que je suis venu avec: sauter adb backupsur l'ordinateur et aller directement à l'appareil via 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

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

Le seul inconvénient est que vous ne pouvez pas effectuer de sauvegarde complète si votre appareil est rempli à plus de la moitié. Cela peut être contourné si vous avez un slot SdCard externe. bupeut y écrire même sur Android 4.4.2, car il s'agit d'une application système. /mnt/extSdCard/backup.abtravaillé la même chose pour moi comme /sdcard.

soupir, je suis vraiment désolé si c'est le cas, et vous semblez être prudent en jugeant par vos captures d'écran et vos lignes de commande, mais j'ai découvert à mon grand chagrin les mêmes symptômes et je pensais les poster juste au cas où de futurs découvreurs viendraient ici. Il s'avère que adb est très pointilleux sur les options simples contre les doubles tirets. Pour moi, les doubles 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 existe de longs noms d'arguments, fonctionnent comme un charme.

Au cas où cela serait nécessaire, mon téléphone est un Samsung Galazy Note 2 SGH-i317 sous Android 5.1 / CyanogenMod 12.1.

Vous devez exécuter la commande adb backup sur adb version 1.0.31.

Pour Windows, j'ai fait:

• trouvez votre dossier SDK (c: / users /.../ AppData / Local / Android / sdk)
• renommer outils & plate-outils en outils.bak & plate-outils.bak
• télécharger http://dl-ssl.google.com/android/repository/tools_r22.3-windows.zip
• télécharger http://dl-ssl.google.com/android/repository/platform-tools_r19.0.1-windows.zip
• extraire les deux zip dans le dossier sdk
• lancer la commande de sauvegarde adb comme d'habitude

Bûche:

$ adb sauvegarde -apk -obb -shared -all -system -f bckp.ab

serveur adb est obsolète. meurtre...

• démon a démarré avec succès *

Maintenant, déverrouillez votre appareil et confirmez l'opération de sauvegarde.

... puis tout remettre à la normale.

OK, c'est comme ça que j'ai réparé le mien.

J'ai essayé la solution de Hunter Perrin:

adb backup -apk\ -shared\ -all\ -system

Mais il vient de revenir immédiatement, sans erreur, sans écran de sauvegarde sur le téléphone.

Par essais et erreurs, cela a fonctionné pour moi:

adb backup -all\

Je pense avoir une solution pour ceux qui utilisent 1.0.32:

entrez un mot de passe lorsque vous êtes invité sur l'écran Android

Malgré le fait qu'il indique qu'il utilisera le mot de passe par défaut si vous n'en saisissez aucun, je crois que ce n'est pas le cas et adb 1.0.32 n'autorise peut-être pas la création de sauvegardes non chiffrées.

La saisie d’un mot de passe a fonctionné pour moi, puis j’ai fini par utiliser «Android Backup Extractor» (Warning Sourceforge) et «Stratégie de compétence illimitée JCE (Java Cryptography Extension)» pour l’extraire dans un fichier tar.

J'ai rencontré le problème inverse: 1.0.31 avec un téléphone plus récent (Android 7) échoue aussi. 1.0.31 utilise: comme séparateur lors du passage d'arguments au téléphone. Comme on peut le adb logcat -s BackupManagerServicevoir, le nouvel adb sur le téléphone ne peut pas gérer l'ancien style non plus: 02-19 01:59:44.330 1100 9830 W BackupManagerService: Unknown package com.gameloft.android.ANMP.GloftPOHM:-apk, skipping heureusement, l'adb le plus récent accepte également les espaces comme séparateur; adb.exe backup "com.gameloft.android.ANMP.GloftPOHM -apk" -f game-backup.ab