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

Realmente pasé algún tiempo investigando esto y me sorprendió no encontrar ninguna respuesta ( este excelente hilo no aborda este problema en absoluto... Estoy tratando de 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, como muchos otros, me doy cuenta de que rootear borrará todo para desbloquear (si solo hubiera leído eso primero), y estoy tratando de hacer una copia de seguridad de todas las aplicaciones datos para el usuario secundario.

Cuando intento ejecutar cualquier copia de seguridad basada en adb en el usuario secundario, simplemente se bloquea y luego se agota el tiempo de espera, creando un archivo .ab vacío. La cuenta de usuario del propietario se respalda correctamente.

¿Algunas ideas? ¿Es el multiusuario demasiado nuevo? Me encontré con otras cosas molestas con él (ningún cliente VPN se conectará, no puedo acceder a la configuración del desarrollador, ni siquiera puedo cambiar la configuración de TIEMPO, etc.)

¡Gracias!

¿El usuario secundario sigue configurado después de un borrado? ¿O entendí mal que ya realizaste el borrado/desbloqueo? Si aún no lo hizo, ¿está habilitada la depuración USB cuando intenta conectarse al usuario secundario? ¿ adb devicesLista el Nexus?
¡Todo esto es limpieza previa! Todo sigue en stock, dos usuarios en total. Como no puedo habilitar la depuración de USB como usuario secundario, la habilité como propietario. Cuando me conecto como usuario secundario, Depuración USB conectada se muestra en la barra de estado de la tableta y veo mi dispositivo en la lista adb devices, pero cuando lo ejecuto adb backup...y dice "desbloquee su dispositivo y confirme...", nunca se muestra nada en la pantalla. tableta. Nuevamente, como propietario, se muestra el mensaje y la copia de seguridad funciona.
¿Ha autorizado ese dispositivo con ADB? 4.2.2 en adelante le pedirá una confirmación de RSA la primera vez que se conecte, y ese cuadro de diálogo solo se abre si está en el usuario principal. Sin embargo, funciona en todos los usuarios después de la autorización.
No estoy seguro de lo que quiere decir con autorizar fuera de la conexión adb típica... Cuando el perfil del propietario está activo, la copia de seguridad funciona bien como se indicó anteriormente: se solicita la contraseña cifrada predefinida del dispositivo y cuando se ingresa permite la copia de seguridad completar. Una vez que cambio a la cuenta de no propietario, mi computadora lo cuenta como que el dispositivo se desconecta y se vuelve a conectar, y luego, como se indicó, nunca se me pide confirmación y adb se cuelga hasta que se agota el tiempo de espera y deja un archivo .ab vacío.

Respuestas (3)

Si tiene Android 4.2.2, hay una forma de desbloquear el gestor de arranque sin borrar el dispositivo. Use towelroot para rootear su dispositivo. (Funciona en un neuxs 7 siempre que tenga una compilación del kernel < 3 de junio). Luego, puede usar la siguiente aplicación para desbloquear el gestor de arranque (no borra el dispositivo). Luego, puede usar la copia de seguridad de titanio para hacer una copia de seguridad de todo en su dispositivo, incluso cuando haya iniciado sesión como usuario secundario.

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

Creo que lo que está sucediendo en su situación es que (sin querer) está realizando una copia de seguridad del usuario Propietario. Dado que se encuentra en el perfil de usuario secundario, no verá la indicación para iniciar la copia de seguridad para el usuario Propietario . Entonces adb se cuelga esperando una confirmación que nunca ves.

Una cosa importante a tener en cuenta es que las sesiones de adb siempre se ejecutan en el contexto del usuario Propietario. Entonces, si no está pasando una identificación de usuario al proceso de copia de seguridad, estará haciendo una copia de seguridad del perfil del Propietario.

Entonces, ¿cómo se inicia una copia de seguridad/restauración en un perfil que no es de propietario? Es útil saber que los comandos de copia de seguridad y restauración de adb terminan ejecutándose buen el sistema. Cuando ejecuta bu helpdesde el shell de adb, este es el resultado 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)

Bien, genial, aparentemente hay una -useropción. ¡Gran! 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

De acuerdo, tal vez sea quisquilloso y quiera el archivo de copia de seguridad como primer argumento. Pero esto da como resultado la misma salida. No he descubierto por qué adb no aceptará el -userargumento.

Pero hay otra opción, podemos ejecutar budirectamente desde el shell adb. Desafortunadamente, todavía tengo que hacer que esto funcione bien, pero avanzo más. Primero cargo la copia de seguridad en el perfil del Propietario y ejecuto budesde el perfil del Propietario usando el shell adb. No conozco ninguna forma de obtener un shell adb en un perfil que no sea de propietario. Sin embargo, esto no debería ser un problema porque para eso es el -userargumento. He intentado dos escenarios en vano.

  1. Ejecutar bu -user <uid> <backup file>mientras está conectado al perfil de ese uid, en este caso uid 11. No veo ningún mensaje de confirmación de restauración ni ocurre nada visualmente. Aquí hay líneas 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, BackupManagerService sabe que estoy solicitando una restauración de uid 11. También dice que está iniciando la interfaz de usuario de confirmación, aunque no veo nada. Eventualmente, las solicitudes expiran.

  1. Ejecutar bu -user <uid> <backup file>mientras está conectado al perfil de Propietario. Aquí hay líneas 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.

Como en el primer intento, vemos que BackupManagerService está intentando realizar una restauración para uid 11. Inicia la interfaz de usuario de confirmación, que aparece. Luego confirmo la restauración. Pero luego vemos que su uid 0 confirma la restauración y creo que es por eso que el token resultante no es válido. Tiene sentido, ¿por qué un perfil debería poder confirmar la copia de seguridad/restauración de otro? (tiene un poco más de sentido que el perfil de Propietario pueda hacer eso)

Así que creo que me he topado con un obstáculo aquí. No estoy seguro de cómo hacer 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 de Android, aunque ¿por qué tener una -useropción?

Aquí hay algunos otros mensajes de registro que pueden ser pistas sobre el 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
¿Comprobó si el servicio backupmanager se estaba ejecutando para su usuario 11? ¿Qué dumpsys backup usersinformó? En mi Android, el servicio de copia de seguridad no se estaba ejecutando para mi cuenta de usuario secundaria, incluso cuando dicha cuenta de usuario estaba activa en el dispositivo. Por lo tanto, -userno funcionó en mi opinión.

No creo que haya forma de encontrar un exploit que permita la raíz. adb backup -apk -shared -allsolo realiza copias de seguridad para el usuario 0 tanto para /data/user/ como para /storage/emulated/ (para dispositivos que no tienen almacenamiento ampliable). No hubo suerte con 4.4 tampoco.

Copia de seguridad no root con múltiples usuarios (usuarios no propietarios o secundarios)
RespuestasAquíPolítica de privacidad1y, 0v