1 votes

Impossible de restaurer une sauvegarde adb à cause d'une archive dont l'en-tête est cassé.

J'ai deux appareils qui ont respectivement Android 5.0.2 et 6.0.1. J'aimerais migrer certaines applications non-cloud de l'appareil avec la version Android la plus ancienne vers le nouveau en utilisant adb . La commande de sauvegarde est simple :

adb backup -apk -f foo.bar.baz.ab foo.bar.baz

Maintenant, après avoir connecté l'appareil avec la nouvelle version d'Android, la commande suivante devrait fonctionner :

adb restore foo.bar.baz.ab

Malheureusement, ce n'est pas le cas. Comme d'habitude, le processus de restauration échoue en silence, signalant simplement que le processus de restauration est terminé. En fait, rien ne se passe vraiment. Voici les journaux :

adb logcat -s BackupManagerService

08-27 01:02:44.100 1300 2300 I BackupManagerService : Début de la restauration complète...
08-27 01:02:44.100 1300 2300 D BackupManagerService : Démarrage de l'interface utilisateur de confirmation de restauration, token=1956031088
08-27 01:02:44.120 1300 2300 D BackupManagerService : Waiting for full restore completion...
08-27 01:02:45.650 1300 2450 D BackupManagerService : acknowledgeFullBackupOrRestore : token=1956031088 allow=true
08-27 01:02:45.660 1300 18181 I BackupManagerService : --- Exécution d'une restauration complète du jeu de données ---
08-27 01:02:45.680 1300 18181 I BackupManagerService : Le paquet foo.bar.baz n'est pas installé ; nécessite apk dans le jeu de données.
08-27 01:02:45.680 1300 18181 D BackupManagerService : Fichier APK ; installation
08-27 01:02:45.680 1300 18181 D BackupManagerService : Installation à partir de la sauvegarde : foo.bar.baz
08-27 01:02:45.690 1300 18181 E BackupManagerService : Impossible de transcrire l'apk restauré pour l'installation
08-27 01:02:45.690 1300 18181 E BackupManagerService : Parse error in header : Nombre non valide dans l'en-tête : '' pour le radix 8
08-27 01:02:45.710 1300 18181 W BackupManagerService : exception io sur la lecture de la socket de restauration
08-27 01:02:45.710 1300 18181 W BackupManagerService : java.io.IOException : Nombre invalide dans l'en-tête : '' pour radix 8
08-27 01:02:45.710 1300 18181 W BackupManagerService : at com.Android.server.backup.BackupManagerService$PerformAdbRestoreTask.extractRadix(BackupManagerService.java:7380)
08-27 01:02:45.710 1300 18181 W BackupManagerService : at com.Android.server.backup.BackupManagerService$PerformAdbRestoreTask.readTarHeaders(BackupManagerService.java:7179)
08-27 01:02:45.710 1300 18181 W BackupManagerService : at com.Android.server.backup.BackupManagerService$PerformAdbRestoreTask.restoreOneFile(BackupManagerService.java:6396)
08-27 01:02:45.710 1300 18181 W BackupManagerService : at com.Android.server.backup.BackupManagerService$PerformAdbRestoreTask.run(BackupManagerService.java:6254)
08-27 01:02:45.710 1300 18181 W BackupManagerService : at java.lang.Thread.run(Thread.java:818)
08-27 01:02:45.710 1300 2300 I BackupManagerService : Traitement de la restauration complète terminé.
08-27 01:02:45.720 1300 18181 D BackupManagerService : Passe de restauration complète terminée.

Il semble quelque peu étrange que le même format de sauvegarde ne puisse pas être restauré sur un appareil plus récent. J'ai également essayé de reconditionner l'archive tarball sous-jacente à l'aide de nelenkov/android-backup-extractor en conservant le même ordre des fichiers ( tar cvf ... -T files.lst ) en espérant que l'en-tête cassé soit réparé. Pas de chance.

Quelle est la cause d'un tel comportement de sauvegarde/restauration et comment puis-je résoudre le problème pour migrer l'application de l'ancien appareil vers le nouveau ? Toute aide est la bienvenue hautement J'apprécie et je vous remercie d'avance.

  • Android Debug Bridge version 1.0.31
  • LG Optimus E975, Android 5.0.2, CyanogenMod 12-2015...
  • Samsung Galaxy S5, Android 6.0.2, flashé vers un firmware stock Sprint plus récent (initialement Android 5.0.x plus tôt)

2voto

Lyubomyr Shaydariv Points 205

Après une journée entière d'expériences diverses avec d'autres outils comme TitaniumBackup (ni l'un ni l'autre n'ont bien fonctionné, TB n'a pu restaurer que les APK, pas les données), j'ai compris que le fait de spécifier l'option -apk La clé était le problème. Il suffit d'omettre l'indicateur lors d'une opération de sauvegarde pour qu'il soit entièrement restaurable.

Mon nouveau plan de sauvegarde/restauration est donc devenu le suivant :

  • dispositif 1 : données de sauvegarde uniquement
  • appareil 2 : sauvegarde APK+données en conservant l'APK seulement plus tard (nécessite nelenkov/android-backup-exractor par Nikolay Elenkov ; peut être facilement construit en utilisant le JDK 1.8.x et Gradle 2.7 (impossible de le construire en utilisant Gradle 2.7+ et Gradle 3.0+) avec de simples gradle commande)
  • appareil 2 : restaurer l'APK en utilisant adb install
  • dispositif 2 : restaurer les données en utilisant adb restore

Voici les scripts :

backup.sh

#!/bin/bash

set -e

PACKAGE=$1

if [ -z "$PACKAGE" ]; then
    echo no package specified
    exit
fi

echo ">>> Backing up $PACKAGE data..."
adb backup -f "$PACKAGE".DATA.ab $PACKAGE

echo ">>> Backing up $PACKAGE APK..."
adb backup -apk -f "$PACKAGE".APK.ab $PACKAGE

echo ">>> Extracting APK..."
java -jar abe-all.jar unpack "$PACKAGE".APK.ab "$PACKAGE".APK.ab.tar
rm "$PACKAGE".APK.ab
APK_FILENAME=$(basename $(tar tf "$PACKAGE".APK.ab.tar | grep '^apps/'"$PACKAGE"'/a/'))
tar xvf "$PACKAGE".APK.ab.tar -C ./ "apps/$PACKAGE/a/$APK_FILENAME" --strip-components=3
mv "$APK_FILENAME" "$PACKAGE".apk
rm "$PACKAGE".APK.ab.tar

echo
echo "*************"
echo "*** Done ***"
echo "*************"

Ce script requiert un nom de paquet comme paramètre d'entrée et stocke un APK et ses données en tant que foo.bar.apk y foo.bar.DATA.ab respectivement. Je l'ai également implémenté en tant que script de double sauvegarde (un dispositif demande de faire une sauvegarde deux fois) parce que je ne voulais pas ré-emballer les tarballs sous-jacents en préservant l'ordre original des fichiers, en m'assurant simplement que le fichier DATA.ab est dans son état original.

restore.sh

#!/bin/bash

set -e

PACKAGE=$1

if [ -z "$PACKAGE" ]; then
    echo no package specified
    exit
fi

echo ">>> Installing $PACKAGE APK..."
adb install -r $PACKAGE.apk

echo ">>> Restoring $PACKAGE data..."
adb restore $PACKAGE.DATA.ab

echo
echo "*************"
echo "*** Done ***"
echo "*************"

Ce script installe simplement un APK sur un appareil cible et restaure ses données. Le seul paramètre d'entrée est le nom du paquet de l'application.

Le processus global de sauvegarde/restauration est donc le suivant :

  • Connecter le dispositif #1
  • Exécuter backup.sh passer un nom de paquet d'application
  • Cliquez sur "Sauvegarde..." sur l'appareil n°1 (on vous demandera deux fois de sauvegarder respectivement les données et l'APK+données)
  • Répétez les deux étapes précédentes pour les autres paquets si nécessaire.
  • Déconnecter le dispositif #1 et connecter le dispositif #2
  • Exécuter restore.sh passer un nom de paquet d'application
  • Cliquez sur "Restaurer..." sur l'appareil n°2 une fois demandé
  • Répétez les deux étapes précédentes pour les autres paquets si nécessaire.

2voto

ac3d912 Points 21

Je veux juste ajouter à votre réponse, pour les personnes passant de KitKat (4.4) à Nougat (7.1). (BTW, je suis finalement tombé sur votre question/réponse après 2 jours de lutte avec cela, merci beaucoup)

Il y a plusieurs bogues dans adb à partir de la version 1.0.32+ quand on essaie de sauvegarder, mais la version 1.0.31 fonctionne très bien. Cependant, vous semblez avoir besoin de la version 1.0.36 pour restaurer vers Nougat.

Pour sauvegarder : outils de plate-forme_r20 (Vous DEVEZ définir un mot de passe)

Pour restaurer : platform-tools_r25.0.3 (Pas de mot de passe nécessaire)

Ainsi, j'ai ajouté un peu à votre script... (vous devrez ajouter des liens symboliques pour adb-1.0.31 et adb-1.0.36)

backup.sh

#!/bin/bash

set -e

DEVICE=$1
PACKAGE=$2
PASSWD=$3

if [ -z "$PACKAGE" ]; then
    echo no package specified
    exit
fi

echo ">>> Backing up $PACKAGE data..."
adb-1.0.31 -s $DEVICE backup -f "$PACKAGE".DATA.ab $PACKAGE

sleep 5

echo ">>> Backing up $PACKAGE APK..."
adb-1.0.31 -s $DEVICE backup -apk -f "$PACKAGE".APK.ab $PACKAGE

echo ">>> Extracting APK..."
java -jar abe.jar unpack "$PACKAGE".APK.ab "$PACKAGE".APK.ab.tar $PASSWD
rm "$PACKAGE".APK.ab
APK_FILENAME=$(basename $(tar tf "$PACKAGE".APK.ab.tar | grep '^apps/'"$PACKAGE"'/a/'))
tar xvf "$PACKAGE".APK.ab.tar -C ./ "apps/$PACKAGE/a/$APK_FILENAME" --strip-components=3
mv "$APK_FILENAME" "$PACKAGE".apk
rm "$PACKAGE".APK.ab.tar

echo
echo "*************"
echo "*** Done ***"
echo "*************"

restore.sh

#!/bin/bash

set -e

DEVICE=$1
PACKAGE=$2

if [ -z "$PACKAGE" ]; then
    echo no package specified
    exit
fi

echo ">>> Installing $PACKAGE APK..."
adb-1.0.36 -s $DEVICE install -r $PACKAGE.apk

echo ">>> Restoring $PACKAGE data..."
adb-1.0.36 -s $DEVICE restore $PACKAGE.DATA.ab

echo
echo "*************"
echo "*** Done ***"
echo "*************"

1voto

J'ai eu la même erreur lorsque j'ai voulu .ab fichier que j'ai emballé .7z au lieu de .tar . J'ai utilisé 7z.exe, donc changer la commande de :

7z.exe a -t7z app.package.name.7z app.package.name

à :

7z.exe a -ttar app.package.name.tar app.package.name

aidé. Salutations.

0voto

SaeX Points 145

Je sais que ce n'est pas une réponse directe à votre question, mais d'autres personnes sont peut-être dans la même situation et cherchent une solution similaire :

Cela m'est arrivé aujourd'hui lors d'une mise à jour de Lineage 14.1->15.1. ADB 1.0.39 ne semble pas vraiment améliorer la situation.

Je ne voulais pas utiliser d'anciennes versions d'adb, mais je voulais qu'il soit simple et open source.

J'ai trouvé oandbackup ( https://f-droid.org/en/packages/dk.jens.backup/ ) pour faire exactement ce que je veux. Il suffit de sélectionner toutes les applications de l'utilisateur, de sauvegarder les apk+données, de copier le dossier entier sur l'autre téléphone, de restaurer toutes les applications+apks, et voilà, (presque) tout est revenu comme il se doit. Les entrées de compte (imapnotes, davdroid) n'ont pas fonctionné, et la sauvegarde de l'application "compte" a ajouté un compte invisible imapnotes qui n'a pas fonctionné et n'a pas pu être ajouté à nouveau. J'ai dû supprimer les données de l'application et réintroduire le compte manuellement. Je ne recommande donc pas la sauvegarde des informations de compte.

À part ça, je suis heureux.

J'avais l'habitude d'utiliser adebar ( https://github.com/IzzySoft/Adebar ) qui était parfait, mais maintenant que adb backup/restore ne fonctionne pas de manière fiable, il ne fonctionne pas non plus.

Chaque version d'adb crée des messages d'erreur différents :

DefContainer: Failed to parse package o

Unable to transcribe restored apk for install

Espérons qu'un moteur de recherche reprendra ces chaînes de caractères.

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