1 votos

No se puede restaurar una copia de seguridad de adb debido a un tarball con una cabecera rota

Tengo dos dispositivos que tienen Android 5.0.2 y 6.0.1 respectivamente. Me gustaría migrar algunas aplicaciones que no están en la nube desde el dispositivo con la versión de Android más antigua a la nueva utilizando adb . El comando de copia de seguridad es sencillo:

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

Ahora, después de conectar el dispositivo con la nueva versión de Android, se espera que el siguiente comando funcione:

adb restore foo.bar.baz.ab

Desgraciadamente no es así. Como es habitual, el proceso de restauración falla silenciosamente sólo informando que el proceso de restauración ha terminado. En realidad no pasa nada. Aquí están los registros:

adb logcat -s BackupManagerService

08-27 01:02:44.100 1300 2300 I BackupManagerService: Comenzando la restauración completa...
08-27 01:02:44.100 1300 2300 D BackupManagerService: Iniciando la interfaz de confirmación de la restauración, token=1956031088
08-27 01:02:44.120 1300 2300 D BackupManagerService: Esperando la finalización de la restauración completa...
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: --- Realizando la restauración del conjunto de datos completo ---
08-27 01:02:45.680 1300 18181 I BackupManagerService: El paquete foo.bar.baz no está instalado; requiere apk en el conjunto de datos
08-27 01:02:45.680 1300 18181 D BackupManagerService: Archivo APK; instalando
08-27 01:02:45.680 1300 18181 D BackupManagerService: Instalando desde la copia de seguridad: foo.bar.baz
08-27 01:02:45.690 1300 18181 E BackupManagerService: No se puede transcribir el apk restaurado para su instalación
08-27 01:02:45.690 1300 18181 E BackupManagerService: Error de análisis en la cabecera: Número inválido en la cabecera: '' para el radix 8
08-27 01:02:45.710 1300 18181 W BackupManagerService: io exception on restore socket read
08-27 01:02:45.710 1300 18181 W BackupManagerService: java.io.IOException: Número inválido en la cabecera: '' para 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: Procesamiento de restauración completa completado.
08-27 01:02:45.720 1300 18181 D BackupManagerService: Pase de restauración completo completado.

Parece algo extraño que no se pueda restaurar el mismo formato de copia de seguridad en un dispositivo más nuevo. También he intentado volver a empaquetar el tarball subyacente utilizando nelenkov/android-backup-extractor conservando el mismo orden de los archivos ( tar cvf ... -T files.lst ) con la esperanza de que la cabecera rota sea reparada. No hubo suerte.

¿Qué es lo que provoca ese comportamiento de copia de seguridad/restauración y cómo puedo resolver el problema para migrar la aplicación del dispositivo antiguo al nuevo? Cualquier ayuda es altamente apreciado y gracias de antemano.

  • Android Debug Bridge versión 1.0.31
  • LG Optimus E975, Android 5.0.2, CyanogenMod 12-2015...
  • Samsung Galaxy S5, Android 6.0.2, flasheado a un firmware más reciente de Sprint (inicialmente Android 5.0.x anterior)

2voto

Lyubomyr Shaydariv Puntos 128

Después de un día entero de varios experimentos con otras herramientas como TitaniumBackup (ninguna de las dos funcionaba bien, TB sólo era capaz de restaurar APKs, no datos) he averiguado que especificando el -apk la llave era el problema. Basta con omitir el indicador durante una operación de copia de seguridad para que se pueda restaurar por completo.

Así que mi nuevo plan de copia de seguridad/restauración pasó a ser el siguiente:

  • dispositivo 1: sólo datos de respaldo
  • dispositivo 2: copia de seguridad APK+datos conservando el APK sólo después (requiere nelenkov/android-backup-exractor por Nikolay Elenkov; se puede construir fácilmente usando JDK 1.8.x y Gradle 2.7 (no se pudo construir usando Gradle 2.7+ y Gradle 3.0+) con un simple gradle mando)
  • dispositivo 2: restaurar el APK utilizando adb install
  • dispositivo 2: restaurar los datos mediante adb restore

Aquí están los guiones:

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 "*************"

Este script requiere un nombre de paquete como parámetro de entrada y almacena un APK y sus datos como foo.bar.apk y foo.bar.DATA.ab respectivamente. También lo implementé como un script (un dispositivo pide hacer una copia de seguridad dos veces) porque no quería volver a empaquetar los tarballs subyacentes conservando el orden original de los archivos sólo asegurándome de que el DATA.ab el archivo está en su estado original.

restaurar.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 "*************"

Este script simplemente instala un APK en un dispositivo de destino y restaura sus datos. El único parámetro de entrada es el nombre del paquete de la aplicación.

Así que el proceso general de copia de seguridad/restauración es:

  • Conectar el dispositivo nº 1
  • Ejecutar backup.sh pasar un nombre de paquete de aplicación
  • Haga clic en "Copia de seguridad..." en el dispositivo nº 1 (se le pedirá dos veces para las copias de seguridad de datos y APK+datos respectivamente)
  • Repita los dos pasos anteriores para otros paquetes si es necesario
  • Desconecte el dispositivo #1 y conecte el dispositivo #2
  • Ejecutar restore.sh pasar un nombre de paquete de aplicación
  • Haga clic en "Restaurar..." en el dispositivo #2 una vez que se le pregunte
  • Repita los dos pasos anteriores para otros paquetes si es necesario

2voto

neerajdorle Puntos 108

Sólo quiero añadir a su respuesta, para las personas que van de KitKat (4.4) a Nougat (7.1). (Por cierto, finalmente me encontré con su pregunta / respuesta después de 2 días de lucha con esto, gracias a una tonelada)

Hay varios fallos en adb a partir de la versión 1.0.32 al intentar hacer una copia de seguridad, pero la versión 1.0.31 funciona de maravilla. Sin embargo, parece que necesita 1.0.36 para restaurar a Nougat.

Para hacer una copia de seguridad: plataforma-herramientas_r20 (DEBE establecer una contraseña)

Para restaurar: plataforma-herramientas_r25.0.3 (No se necesita contraseña)

Como tal, he añadido a su script un poco... (tendrás que añadir enlaces simbólicos para adb-1.0.31 y 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 "*************"

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

Kathleen Haley Puntos 6

Me da el mismo error cuando para .ab archivo que empaqué .7z en lugar de .tar . Usé 7z.exe, así que cambiando el comando de:

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

a:

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

ayudado. Saludos.

0voto

tbart Puntos 1

Sé que no es una respuesta directa a tu pregunta, pero otras personas pueden estar en la misma situación y buscar una solución similar:

Esto me pasó hoy también durante una actualización de Lineage 14.1->15.1. ADB 1.0.39 no parece mejorar la situación.

No quería utilizar versiones antiguas de adb, sino que quería que fuera sencillo y de código abierto.

He encontrado oandbackup ( https://f-droid.org/en/packages/dk.jens.backup/ ) para hacer exactamente lo que quiero. Sólo tienes que seleccionar todas las aplicaciones de usuario, copia de seguridad apk + datos, copiar toda la carpeta en el otro teléfono, restaurar todas las aplicaciones + apks, y voila, (casi) todo de nuevo como debe ser. Las entradas de cuentas (imapnotes, davdroid) no han funcionado, y al hacer la copia de seguridad de la app "account" se ha añadido una cuenta de imapnotes invisible que no ha funcionado y no se ha podido volver a añadir. Tuve que borrar los datos de la aplicación y volver a añadir la cuenta manualmente. Así que no recomendaría hacer una copia de seguridad de la información de la cuenta.

Aparte de eso, estoy contento.

Solía utilizar adebar ( https://github.com/IzzySoft/Adebar ) que era perfecto, pero ahora que adb backup/restore no funcionan de forma fiable, tampoco funciona.

Cada versión de adb crea diferentes mensajes de error:

DefContainer: Failed to parse package o

Unable to transcribe restored apk for install

Esperemos que algún buscador recoja estas cadenas.

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X