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.
Confirmo que ADB reconoce el dispositivo usando el adb devices
comando y recibo el siguiente resultado:
List of devices attached
8e1f368a device
Ejecuto el comando de copia de seguridad ADB (detalles a continuación).
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:
No importa lo que haga aquí (detalles a continuación).
Toco el Back up my databotón (esquina inferior derecha).
El teléfono vuelve a la pantalla de inicio y me muestra el Backup starting...
mensaje, luego el Backup finished
mensaje 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 .
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 -nosystem
modificador 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.
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:
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:
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.
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.
Intente usar una versión anterior de adb. 1.0.32 no funcionó para mí, pero 1.0.31 sí.
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 logcat
para ver los registros del dispositivo, noté que después de invocar adb backup -apk -obb -shared -all -nosystem
habí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.
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'.-all
sin -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 volumes
FullBackup: Unrecognized domain shared/0
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:
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
Ninguna de las soluciones funcionó para mí aquí, y no quiero degradar mis herramientas SDK. Esto es lo que se me ocurrió: omita adb backup
la 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/bu
y 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. bu
puede escribir allí incluso en Android 4.4.2, porque es una aplicación de sistema. /mnt/extSdCard/backup.ab
me funcionó igual que /sdcard
.
bu 1 backup -apk app.package.name > /sdcard/backup.ab
crea un archivo vacío de 47 bytes en mi caso.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.
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...
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 BackupManagerService
se 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, skipping
Afortunadamente, 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 backup
lo que no lo encontraba y estaba creando un archivo de respaldo vacío, sin informar ningún error . adb logcat
mostró 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.
izzy
adb backup
funcionaba bien,adb restore
siempre fallaba). Resultó que era un problema de permisos (el fabricante se había equivocado con la ROM), poradb restore
lo 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.Señor del Fuego
marco leogrande