7 votos

Copia de seguridad sin root con múltiples usuarios (usuarios no propietarios o secundarios)

Realmente pasé un tiempo investigando esto y me sorprendió no encontrar ninguna respuesta ( este gran hilo no aborda este problema en absoluto... . Estoy intentando recuperarme de mi desafortunada situación: Configuré un usuario secundario en mi Nexus 7 4.2.2 y mi dispositivo no está (todavía) rooteado. Ahora me doy cuenta, como muchos otros, de que el rooteo borrará todo para desbloquear (si hubiera leído eso antes), y estoy intentando hacer una copia de seguridad de todos los datos de las aplicaciones para el usuario secundario.

Cuando intento ejecutar cualquier copia de seguridad basada en adb en el usuario secundario, simplemente se cuelga y luego se agota, creando un archivo .ab vacío. La cuenta de usuario del propietario hace la copia de seguridad sin problemas.

¿Alguna idea? ¿Es el multiusuario demasiado nuevo? Me he encontrado con otras cosas molestas (ningún cliente VPN se conecta, no puedo entrar en la configuración del desarrollador, ni siquiera puedo cambiar la configuración del TIEMPO, etc...)

Gracias.

0 votos

¿El usuario secundario sigue configurado después de un borrado? O he entendido mal que ya se ha realizado ¿el borrado/desbloqueo? Si no lo has hecho ya, es Depuración USB habilitado cuando intentas conectarte con el usuario secundario? ¿Tiene adb devices ¿lista el Nexus?

0 votos

¡Todo esto es pre-limpio! Todo sigue siendo stock, dos usuarios en total. Como no puedo habilitar la depuración USB como usuario secundario, la habilité como propietario. Cuando me conecto como el usuario secundario Depuración USB conectada aparece en la barra de estado de la tablet y sí veo que mi dispositivo aparece en adb devices - pero cuando corro adb backup... y dice "desbloquee su dispositivo y confirme..." nunca se muestra nada en la tablet. De nuevo, como propietario el mensaje se muestra y la copia de seguridad funciona.

0 votos

¿Has autorizado ese dispositivo con ADB? 4.2.2 en adelante te pedirá una confirmación RSA la primera vez que te conectes, y ese diálogo sólo se abre si estás en el usuario principal. Sin embargo, funciona en todos los usuarios después de la autorización.

2voto

Chrisii Puntos 586

Si estás en Android 4.2.2 hay una forma de desbloquear el bootloader sin borrar el dispositivo. Utilice toallero para rootear tu dispositivo. (Funciona en un neuxs 7 siempre y cuando tengas un kernel build < Jun 3). Después puedes usar lo siguiente aplicación para desbloquear el bootloader (no borra el dispositivo). A continuación, puede utilizar la copia de seguridad de titanio para hacer una copia de seguridad de todo en su dispositivo, incluso cuando se inicia la sesión como un usuario secundario.

1voto

crass Puntos 131

Sería útil ser más explícito en lo que haces, como comandos adb específicos, aunque creo que me encuentro con el mismo problema.

Creo que lo que ocurre en tu situación es que estás tomando (sin querer) una copia de seguridad del usuario Propietario. Como estás en el perfil de usuario secundario, no verás el aviso para iniciar la copia de seguridad para el usuario Propietario . Así que adb se cuelga esperando una confirmación que nunca se ve.

Una cosa importante a tener en cuenta es que las sesiones adb siempre se ejecutan en el contexto del usuario propietario. Así que si usted no está pasando un ID de usuario para el proceso de copia de seguridad, que va a hacer una copia de seguridad del perfil propietario.


Entonces, ¿cómo se inicia una copia de seguridad/restauración a un perfil no propietario? Ayuda saber que los comandos adb backup y restore terminan ejecutando bu en el sistema. Cuando se ejecuta bu help desde el adb shell aquí está la salida que obtengo:

sunfish:/ $ bu help
 backup [-user USER_ID] [-f FILE] [-apk|-noapk] [-obb|-noobb] [-shared|-noshared]
        [-all] [-system|-nosystem] [-keyvalue|-nokeyvalue] [PACKAGE...]
     write an archive of the device's data to FILE [default=backup.adb]
     package list optional if -all/-shared are supplied
     -user: user ID for which to perform the operation (default - system user)
     -apk/-noapk: do/don't back up .apk files (default -noapk)
     -obb/-noobb: do/don't back up .obb files (default -noobb)
     -shared|-noshared: do/don't back up shared storage (default -noshared)
     -all: back up all installed applications
     -system|-nosystem: include system apps in -all (default -system)
     -keyvalue|-nokeyvalue: include apps that perform key/value backups.
         (default -nokeyvalue)
 restore [-user USER_ID] FILE       restore device contents from FILE
     -user: user ID for which to perform the operation (default - system user)

Vale genial, así que aparentemente hay un -user opción. Genial. Así que ahora intento ejecutar una restauración para un usuario secundario desde adb y esto es lo que obtengo:

$ ./platform-tools/adb restore -user 11 <path to android backup>
WARNING: adb restore is deprecated and may be removed in a future release
adb: restore requires an argument

Bien, tal vez sea quisquilloso y quiera el archivo de copia de seguridad como primer argumento. Pero esto resulta en la misma salida. No he descubierto por qué adb no toma el -user argumento.


Pero hay otra opción, podemos ejecutar bu directamente desde el shell adb. Desgraciadamente, aún no he conseguido que esto funcione tampoco, pero voy avanzando. Primero subo la copia de seguridad al perfil de Propietario y ejecuto bu desde el perfil de Propietario utilizando el shell adb. No conozco ninguna forma de obtener un adb shell en un perfil no propietario. Sin embargo, esto no debería ser un problema porque eso es lo que el -user argumento es para. He intentado dos escenarios en vano.

  1. Ejecutar bu -user <uid> <backup file> mientras está conectado al perfil de ese uid, en este caso el uid 11. No veo ningún prompt de confirmación de restauración ni nada que ocurra visualmente. Aquí están las líneas de logcat relevantes:

    03-14 17:58:29.286 11753 11753 D AndroidRuntime: Calling main entry com.android.commands.bu.Backup 03-14 17:58:29.288 11753 11753 D bu : Beginning: restore 03-14 17:58:29.289 1493 1731 I BackupManagerService: [UserID:11] Beginning restore... 03-14 17:58:29.289 1493 1731 D BackupManagerService: [UserID:11] Starting restore confirmation UI, token=30388736403-14 17:58:29.289 1493 1731 I ActivityTaskManager: START u0 {act=fullrest flg=0x20000000 cmp=com.android.backupconfirm/.BackupRestoreConfirmation (has extras)} from uid 1000 03-14 17:58:29.289 1493 1731 W ActivityTaskManager: startActivity called from non-Activity context; forcing Intent.FLAG_ACTIVITY_NEW_TASK for: Intent {act=fullrest flg=0x20800000 cmp=com.android.backupconfirm/.BackupRestoreConfirmation (has extras) } 03-14 17:58:29.293 1493 1731 D BackupManagerService: [UserID:11] Waiting for restore completion... 03-14 17:59:29.388 1493 25093 I BackupManagerService: Full backup/restore timedout waiting for user confirmation 03-14 17:59:29.388 1493 1731 I BackupManagerService: [UserID:11] adb restore processing complete. 03-14 17:59:29.388 11753 11753 D bu : Finished.

Como se puede ver, el BackupManagerService sabe que estoy solicitando una restauración del uid 11. También dice que está iniciando la interfaz de usuario de confirmación, a pesar de que no veo nada. Al final, la solicitud se agota.

  1. Ejecutar bu -user <uid> <backup file> mientras está conectado al perfil del Propietario. Aquí están las líneas de logcat relevantes:

    03-14 18:00:39.448 11948 11948 D AndroidRuntime: Calling main entry com.android.commands.bu.Backup 03-14 18:00:39.450 11948 11948 D bu : Beginning: restore 03-14 18:00:39.451 1493 2786 I BackupManagerService: [UserID:11] Beginning restore... 03-14 18:00:39.451 1493 2786 D BackupManagerService: [UserID:11] Starting restore confirmation UI, token=606614021 03-14 18:00:39.451 1493 2786 I ActivityTaskManager: START u0 {act=fullrest flg=0x20000000 cmp=com.android.backupconfirm/.BackupRestoreConfirmation (has extras)} from uid 1000 03-14 18:00:39.451 1493 2786 W ActivityTaskManager: startActivity called from non-Activity context; forcing Intent.FLAG_ACTIVITY_NEW_TASK for: Intent { act=fullrest flg=0x20800000 cmp=com.android.backupconfirm/.BackupRestoreConfirmation (has extras) } 03-14 18:00:39.459 1493 1994 W ActivityTaskManager: Tried to set launchTime (0) < mLastActivityLaunchTime (22366588) 03-14 18:00:39.462 1493 2786 D BackupManagerService: [UserID:11] Waiting for restore completion... 03-14 18:00:39.572 1493 1757 I ActivityTaskManager: Displayed com.android.backupconfirm/.BackupRestoreConfirmation: +112ms 03-14 18:00:43.431 1493 5565 D BackupManagerService: [UserID:0] acknowledgeAdbBackupOrRestore : token=606614021 allow=true 03-14 18:00:43.432 1493 5565 W BackupManagerService: [UserID:0] Attempted to ack full backup/restore with invalid token 03-14 18:00:46.213 1493 2063 D InputDispatcher: Waiting to send key to Window{200410c u0 com.android.backupconfirm/com.android.backupconfirm.BackupRestoreConfirmation} because there are unprocessed events that may cause focus to change 03-14 18:01:39.563 1493 25093 I BackupManagerService: Full backup/restore timed out waiting for user confirmation 03-14 18:01:39.563 1493 2786 I BackupManagerService: [UserID:11] adb restore processing complete. 03-14 18:01:39.564 11948 11948 D bu : Finished.

Al igual que en el primer intento, vemos que el BackupManagerService está intentando hacer una restauración para el uid 11. Se inicia la UI de confirmación, que sí aparece. Entonces confirmo la restauración. Pero entonces vemos que es el uid 0 el que confirma la restauración y creo que por eso el token resultante es inválido. Tiene sentido, ¿por qué un perfil puede cnofirmar la copia de seguridad/restauración de otro? (tendría un poco más de sentido que el perfil Propietario pudiera hacerlo)

Creo que me he topado con un obstáculo. No estoy seguro de cómo conseguir que la interfaz de usuario de confirmación se ejecute en el usuario correcto. Sospecho que esto (¡todavía!) no ha sido probado por la comunidad Android, aunque por qué tener un -user ¿opción en absoluto?


Aquí hay algunos otros mensajes de registro que pueden ser pistas para un camino a seguir:

03-14 18:00:28.422  1493  5597 W WindowManager: Attempted to set replacing window on app token with no content Token{b3c5879 ActivityRecord{23cb9be u0 com.android.backupconfirm/.BackupRestoreConfirmation t1100006}}
03-14 18:00:28.610  1493  2786 I ActivityTaskManager: Activity reported stop, but no longer stopping: ActivityRecord{23cb9be u0 com.android.backupconfirm/.BackupRestoreConfirmation t1100006}
03-14 18:00:37.042  1493  2063 D InputDispatcher: Waiting to send key to Window{6f7d966 u0 com.android.backupconfirm/com.android.backupconfirm.BackupRestoreConfirmation} because there are unprocessed events that may cause focus to change

0voto

Stephen Puntos 1

No creo que haya una manera de hacerlo si no se encuentra un exploit que permita el uso de root. adb backup -apk -shared -all sólo hace copias de seguridad para el usuario 0, tanto para /data/user/ como para /storage/emulated/ (Para dispositivos sin almacenamiento ampliable). No hay suerte con 4.4 tampoco.

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