La copia de seguridad de ADB crea un archivo de 0 bytes; solicita la contraseña de respaldo actual aunque nunca configuré una; "Error al establecer la contraseña" para la contraseña de respaldo de escritorio

El problema:

Cada vez que ejecuto la copia de seguridad de ADB, aparece un mensaje cerca de la parte inferior de la pantalla de inicio que dice Backup starting..., seguido de un mensaje que dice Backup finished unos segundos más tarde a pesar de que estoy usando 17 GB de memoria del dispositivo, y se crea el archivo de copia de seguridad resultante. con un tamaño de 0 bytes. No recibo mensajes de error, ningún comentario que indique que algo está mal, y mucho menos qué está mal. Parece funcionar, pero demasiado rápido, y el archivo de copia de seguridad está vacío.

El proceso:

  1. Confirmo que ADB reconoce el dispositivo usando el adb devicescomando y recibo el siguiente resultado:

    List of devices attached
    8e1f368a        device
    
  2. Ejecuto el comando de copia de seguridad ADB (detalles a continuación).

  3. Recibo el siguiente mensaje en el símbolo del sistema:

    Now unlock your device and confirm the backup operation.
    

    ...y el siguiente mensaje en el teléfono:

    ingrese la descripción de la imagen aquí

    No importa lo que haga aquí (detalles a continuación).

  4. Toco el Back up my databotón (esquina inferior derecha).

  5. El teléfono vuelve a la pantalla de inicio y me muestra el Backup starting...mensaje, luego el Backup finishedmensaje unos segundos más tarde. Se crea un archivo de 0 bytes, denominado backup.ab predeterminado o lo que haya especificado con el modificador -f .

El comando de respaldo ADB (usado en el paso 2):

Probé múltiples combinaciones de opciones, desde tan simples como

adb backup -all

a cosas como

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

También intenté agregar el -nosystemmodificador después de leer this y this , que indican que tratar de incluir una copia de seguridad del sistema en un dispositivo no rooteado puede resultar en un archivo de 0 bytes, y que se debe usar este modificador. No hace ninguna diferencia, el proceso aún se completa en cuestión de segundos y todavía obtengo un archivo de 0 bytes.

La solicitud de contraseña de "Copia de seguridad completa" (paso 3):

Estoy bastante seguro de que nunca he establecido una contraseña de respaldo antes. Nunca antes había tenido la oportunidad de establecer esta contraseña o acceder a esta configuración de ninguna manera. Sin embargo, he intentado todo lo siguiente:

  • Dejando ambas contraseñas en blanco
  • Dejando la "contraseña de respaldo actual" en blanco e ingresando una nueva contraseña en el segundo cuadro
  • Ingresar el PIN de bloqueo de pantalla actual y todos los PIN que he usado en el pasado como la "contraseña de respaldo actual".
  • Ingresar todas las contraseñas que se me ocurran que hubiera usado alguna vez para cualquier cosa en este dispositivo

En todos los casos, el comportamiento es exactamente el mismo que se describe en el paso 5. No recibo errores ni ningún tipo de indicación de que algo anda mal o de que mis contraseñas no son válidas, y no hay indicios de si realmente está esperando una contraseña actual o si eso el campo debe dejarse en blanco. (La captura de pantalla en esta respuesta y varios otros foros de soporte que he visto parecen implicar que el cuadro "contraseña de respaldo actual" no se mostraría si no hay una contraseña actual, pero eso es solo una inferencia; nada aclara si en realidad se requiere una contraseña actual.)

Sospecho que la contraseña que solicita podría ser la "Contraseña de copia de seguridad del escritorio" establecida en las opciones de Desarrollador:

ingrese la descripción de la imagen aquí

Nunca he puesto esa contraseña antes. Si trato de configurar uno, aparece un mensaje que diceFailed to set backup password.

Al buscar información sobre este error, encontré al menos otro caso en el que alguien que tenía este problema dijo que esto le impedía usar la copia de seguridad de ADB, pero no fue específico sobre lo que sucede cuando intenta usar ADB. respaldo.

La mayoría de las personas que recibieron este mensaje sin haber establecido nunca la contraseña antes dicen que la solución fue dejar la contraseña actual en blanco, pero lo intenté en primer lugar y no funcionó. Encontré una pregunta de otra persona que se encontró con este problema y estaba segura de que no había configurado la contraseña antes . Desafortunadamente, no parece que haya tenido una solución o incluso una explicación.

Independientemente de si ADB está buscando la "contraseña de respaldo de escritorio" o si la contraseña de cifrado de ADB es algo separado, me sorprende por qué ADB requeriría que ingrese una contraseña anterior para iniciar una nueva copia de seguridad. No estoy tratando de restaurar, sobrescribir o acceder de ninguna manera a datos previamente encriptados, por lo que incluso si se estableció previamente una contraseña de encriptación para una copia de seguridad , no puedo imaginar por qué alguien pensaría que es una buena idea evitar que hacer una copia de seguridad de su dispositivo si no recuerda qué contraseña usó para cifrar las copias de seguridad en el pasado.

Información adicional:

Modelo: Samsung Galaxy S4 SCH-I545
Versión del kernel: 3.4.0
Versión del sistema operativo: 4.4.2 Versión de
las herramientas del SDK de Android: 1.16
La depuración de USB está habilitada.

Tenga en cuenta que mi razón para usar la copia de seguridad de ADB es hacer una copia de seguridad completa de mi teléfono para estar seguro antes de rootearlo * para poder usar las herramientas de copia de seguridad de nandroid como la copia de seguridad de titanio. Por lo tanto, cualquier sugerencia que implique rootear mi teléfono sería un Catch-22, no una solución. No hace falta decir que un restablecimiento de fábrica tampoco es una solución, ya que anularía todo el propósito de realizar la copia de seguridad.

El teléfono está configurado para sincronizarse con los servidores de Exchange de mi empresa y el servidor aplica algunas políticas. Pensé que el dispositivo estaba encriptado cuando configuré por primera vez la sincronización con la cuenta de la empresa, pero aparentemente no está encriptado actualmente. De hecho, eso es lo que puso en marcha esta cadena de eventos: Recibo un mensaje que me dice que necesito encriptar el dispositivo para continuar conectándome a los servidores de la empresa. Quiero hacer una copia de seguridad de nandroid antes de encriptar, lo que requiere enraizamiento, y quiero usar la copia de seguridad de ADB antes de enraizar.


* Sí, soy consciente de que se supone que Towelroot es seguro, pero prefiero no correr riesgos y me gustaría resolver o al menos entender este problema en caso de que surjan problemas relacionados en el futuro.

He tenido varios problemas con ADB en una de mis tabletas (rooteados o no, en ambos casos) que eran similares (al revés: aunque adb backupfuncionaba bien, adb restoresiempre fallaba). Resultó que era un problema de permisos (el fabricante se había equivocado con la ROM), por adb restorelo que no pudo leer el archivo de copia de seguridad una vez que se transfirió al dispositivo. Fue un poco difícil de encontrar, y no estoy seguro de si algo similar realmente es el caso aquí; pero podría valer la pena comprobarlo.
Para aquellos que terminarían aquí con el mismo problema de 0 bytes: tuve este problema porque una vez configuré la contraseña del escritorio en Configuración y la olvidé. Debido a que el dispositivo está rooteado, seguí esta respuesta (la mía) y todo salió bien.
También puede consultar: code.google.com/p/android/issues/detail?id=47009 : si ha cifrado su teléfono, es posible que deba usar su contraseña de cifrado como "contraseña actual" en todas las indicaciones: en la pantalla "Copia de seguridad completa", o en la de "Contraseña de copia de seguridad de escritorio".

Respuestas (10)

Respuesta corta

Intente usar una versión anterior de adb. 1.0.32 no funcionó para mí, pero 1.0.31 sí.

Respuesta larga

Acabo de encontrar este problema en un Nexus 5 que ejecuta CyanogenMod 11 (basado en Android 4.4) usando la versión actual de Platform Tools y ADB (Android Debug Bridge versión 1.0.32 Revisión eac51f2bb6a8-android).

Usando adb logcatpara ver los registros del dispositivo, noté que después de invocar adb backup -apk -obb -shared -all -nosystemhabía algunas entradas de registro sospechosas:

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

Donde parece que el dispositivo interpreta las opciones de la línea de comandos como argumentos que no son opciones y produce un error porque no son nombres de paquetes instalados. Esto me hizo sospechar que el protocolo adb o las opciones de invocación de comando/servicio habían cambiado en el dispositivo en relación con el host, así que probé una versión anterior de adb y listo, funcionó.

Investigué un poco y encontré un cambio para Usar escape_arg en "adb backup" , que ahora hace que todos los argumentos estén entre comillas simples al invocar /system/bin/bu backup. Esto explica el comportamiento y los argumentos entre comillas simples en el mensaje de registro. Sin embargo, no parece coincidir con la hora en la que encontró el error. También sugeriría que el problema está mucho más extendido de lo que parece. Así que dudo en llamar a esto la causa, pero puede ser un buen punto de partida para una mayor investigación.

Usar una versión anterior (1.0.31) resolvió mi problema. Esta pregunta stackoverflow.com/q/9555337/1741542 y especialmente esta respuesta stackoverflow.com/a/23022718/1741542 me ayudaron a encontrar una versión anterior, por ejemplo, platform-tools_r20-linux.zip.
Aunque parece que no funciona con todos los modelos. Si bien hice una copia de seguridad completa de un Samsung S3 mini (Android 4.2) sin ningún problema, no pude hacerlo con una tableta, que tiene Android 4.0. Probé todo, desde adb-r10 hasta adb-r23 (excluyendo adb-r15) sin éxito.
Tuve un problema similar con adb 1.0.32 y un Nexus 5 (Android 6). Resolví esto citando explícitamente los argumentos de respaldo, es decir, ejecutando adb backup '-noapk -noshared -all -nosystem'en lugar de adb backup -noapk -noshared -all -nosystem(dentro de un shell bash). Sin las comillas, recibo mensajes de logcat como este: 'marcador de copia de seguridad desconocido -todos: -sin sistema:-noapk', 'no se proporcionaron paquetes de copia de seguridad ni -compartidos ni -todos dados' y finalmente 'Terminado'.
Finalmente también obtuve una copia de seguridad completa con Android 4.0. Estúpido de mí, fue solo un reinicio de la tableta, lo que me puso en marcha.
Sí, el modelo/sistema operativo definitivamente importa de alguna manera, Galaxy S5 en Lollipop funcionó bien con 1.0.32, pero Nexus 7 en Kit Kat requirió 1.0.31 para funcionar.
¡Sorprendente! Funcionó perfectamente con 1.0.32 en un dispositivo Lollipop Android One.
En realidad, lo retiro. La copia de seguridad no contiene ninguno de los datos compartidos, solo los datos de la aplicación, como si hubiera usado -allsin -shared(que también funcionó). Vi estos mensajes en el archivo de registro : BackupManagerService: Calling doFullBackup() on com.android.sharedstoragebackup//SharedStorageAgent: Backing up 1 shared volumesFullBackup: Unrecognized domain shared/0
Confirmaré que 1.0.31 también resolvió mi problema. Usé la respuesta aquí para encontrar la versión anterior: stackoverflow.com/questions/24619607/…
¡Gracias! Por cierto, puedes descargar adb 1.0.31 para todas las plataformas aquí: ftp.mozilla.org/pub/labs/r2d2b2g
Entonces, si entiendo correctamente, ¿debería poder restaurar una copia de seguridad desde cualquier versión de adb, no solo la versión anterior con la que tomé la copia de seguridad?

Sobre la base de la respuesta de kevenoid, puede depender de qué versión de adb se esté ejecutando en el teléfono.

Puede averiguar qué versión está ejecutando el teléfono de forma nativa haciendo lo siguiente:

Primero averigüe qué versión está ejecutando en su escritorio

adb version

Luego abre la carcasa de tu teléfono.

adb shell

Una vez que el shell está abierto, puede ejecutar

adb version

Luego salga del shell ejecutando

exit

Descubrí que mi teléfono estaba ejecutando la versión 1.0.31 y no la 1.0.32 (es un samsung note 2)

Intenté usar comillas o caracteres de escape como mostró Hunter, pero ninguno funcionó desde la línea de comandos de Windows. Sin embargo, la degradación solucionó el problema de incompatibilidad entre las dos versiones.

Pude encontrar la versión anterior siguiendo las instrucciones aquí: https://stackoverflow.com/a/23022718/1741542

El enlace de descarga que utilicé fue:
http://dl-ssl.google.com/android/repository/platform-tools_r20-windows.zip

Otras plataformas:

¿Hay alguna forma de actualizar la versión adb en el teléfono?

Las otras respuestas sobre los argumentos de comando que se citan son precisas. Descubrí que si escapas de los espacios entre los argumentos, funciona.

Me gusta esto:adb backup -apk\ -shared\ -all\ -system

Puede que esta no sea la solución al problema de OP, pero es una mejor solución al problema de @Kevinoid que usar un ADB anterior, que no funcionó para mí.
Este es un duplicado de la respuesta de Kevinoid sin la justificación. Sin embargo, funcionó bien para mí, y prefiero usar \ a '
Esta solución funcionó para mí, no es necesario degradar adb
Puedo confirmar la sospecha de @HunterPerrin de que este es un problema diferente porque probé esto primero y no resolvió mi problema, pero la segunda vez que fui a 1.0.31 adb comenzó a copiar correctamente

Ninguna de las soluciones funcionó para mí aquí, y no quiero degradar mis herramientas SDK. Esto es lo que se me ocurrió: omita adb backupla computadora y vaya directamente al dispositivo a través de 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

Esto llama /system/bin/buy vuelca el archivo de copia de seguridad en STDOUT (descriptor de archivo #1). Los parámetros son los mismos adb backup <params>-> bu 1 backup <params>. La salida se redirige a un archivo en el dispositivo y luego se puede extraer como cualquier archivo.

El único inconveniente es que no puede hacer una copia de seguridad completa si su dispositivo está lleno a más de la mitad. Esto se puede solucionar si tiene una ranura externa para SdCard. bupuede escribir allí incluso en Android 4.4.2, porque es una aplicación de sistema. /mnt/extSdCard/backup.abme funcionó igual que /sdcard.

bu 1 backup -apk app.package.name > /sdcard/backup.abcrea un archivo vacío de 47 bytes en mi caso.
@ user2284570 sí, tuve una experiencia similar (archivo ab vacío) recientemente en Android 9. Creo que en el pasado simplemente estaba roto (0 bytes), pero ahora tienen un acceso más restringido y también se eliminará. ver link.medium.com/4edL3pBnolb

suspiro , lo siento mucho si este es el caso, y pareces ser cuidadoso a juzgar por tus capturas de pantalla y líneas de comando, pero descubrí, para mi disgusto, los mismos síntomas y pensé en publicar en caso de que futuros descubridores lo hagan aquí. Resulta que adb es muy exigente con los guiones simples o dobles en sus opciones. Para mí, los guiones dobles reprodujeron este caso exactamente: el mismo aviso en el teléfono, el mismo archivo de 0 bytes. Los guiones simples a pesar de que hay nombres de argumentos largos funcionaron a la perfección.

En caso de que importe, mi teléfono es un Samsung Galazy Note 2 AT&T SGH-i317 con Android 5.1/Cyanogenmod 12.1.

Estoy un poco confundido si esto debería publicarse como respuesta o comentario. OP muestra que está usando un solo guión, no un guión doble, por lo que su respuesta probablemente no dio en el blanco. Admito que esta respuesta es informativa (valor adicional), pero no parece responder al problema de OP.
Esto resolvió mi problema.
Por favor, publique sus líneas de comando reales.

Debe ejecutar el comando de copia de seguridad adb en adb versión 1.0.31.

Para windows hice:

Tronco:

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

El servidor adb está desactualizado. asesinato...

  • el demonio se inició con éxito *

Ahora desbloquee su dispositivo y confirme la operación de copia de seguridad.

...entonces vuelve todo a la normalidad.

OK, así es como arreglé el mío.

Probé la solución de Hunter Perrin:

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

Pero simplemente regresó de inmediato sin error, sin pantalla de respaldo en el teléfono.

A través de prueba y error esto funcionó para mí:

adb backup -all\

Creo que tengo una solución para aquellos que usan 1.0.32:

ingrese una contraseña cuando se le solicite en la pantalla de Android

A pesar de que dice que usará la contraseña predeterminada si no ingresa ninguna, creo que no es así y adb 1.0.32 quizás no permita la creación de copias de seguridad sin cifrar.

Ingresar una contraseña funcionó para mí, luego terminé usando "Android Backup Extractor" (Warning Sourceforge) y "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" para extraerlo en un archivo tar.

Me encontré con el problema inverso: 1.0.31 con un teléfono más nuevo (Android 7) también falla. 1.0.31 usa : como separador al pasar argumentos al teléfono. Como adb logcat -s BackupManagerServicese muestra, el adb más nuevo en el teléfono tampoco puede manejar el estilo antiguo: 02-19 01:59:44.330 1100 9830 W BackupManagerService: Unknown package com.gameloft.android.ANMP.GloftPOHM:-apk, skippingAfortunadamente, el adb más nuevo también acepta espacios como separador, por lo que encerrar los argumentos entre comillas dobles funciona, por ejemplo:adb.exe backup "com.gameloft.android.ANMP.GloftPOHM -apk" -f game-backup.ab

Para mí fue que se había cambiado el nombre del paquete, por adb backuplo que no lo encontraba y estaba creando un archivo de respaldo vacío, sin informar ningún error . adb logcatmostró el error. Una vez que actualicé el nombre del paquete, tuve adb backupéxito.

Esto estaba usando ADB versión 1.0.41, con una contraseña de respaldo de escritorio habilitada.