Il serait utile d'être plus explicite dans ce que vous faites, comme des commandes adb spécifiques, bien que je pense que je rencontre le même problème.
Je pense que ce qui se passe dans votre situation est que vous prenez (involontairement) une sauvegarde de l'utilisateur propriétaire. Puisque vous êtes dans le profil d'utilisateur secondaire, vous ne verrez pas l'invitation à démarrer la sauvegarde. pour l'utilisateur propriétaire . Donc adb se bloque en attendant une confirmation que vous ne voyez jamais.
Il est important de noter que les sessions adb s'exécutent toujours dans le contexte de l'utilisateur propriétaire. Ainsi, si vous ne transmettez pas d'identifiant d'utilisateur au processus de sauvegarde, il effectuera une sauvegarde du profil du propriétaire.
Alors comment faire pour initier une sauvegarde/restauration vers un profil non propriétaire ? Il est utile de savoir que les commandes de sauvegarde et de restauration adb finissent par exécuter bu sur le système. Lorsque vous exécutez bu help depuis le shell adb voici la sortie que j'obtiens :
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)
Ok super, donc apparemment il y a un -user option. Super ! Alors maintenant, j'essaie d'exécuter une restauration pour un utilisateur secondaire à partir de adb et voici ce que j'obtiens :
$ ./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
Ok, peut-être qu'il est tatillon et qu'il veut le fichier de sauvegarde comme premier argument. Mais cela donne le même résultat. Je n'ai pas encore compris pourquoi adb ne prend pas le fichier -user argument.
Mais il y a une autre option, nous pouvons exécuter bu directement depuis le shell adb. Malheureusement, je n'ai pas encore réussi à faire fonctionner cette méthode non plus, mais j'ai progressé. Je télécharge d'abord la sauvegarde vers le profil du propriétaire et je lance bu depuis le profil du propriétaire en utilisant le shell adb. Je ne connais aucun moyen d'obtenir un shell adb sur un profil non propriétaire. Cela ne devrait pas être un problème, car c'est ce que fait l'ordinateur. -user l'argument est pour. J'ai essayé deux scénarios, sans succès.
-
Exécuter bu -user <uid> <backup file> tout en étant connecté au profil de cet uid, dans ce cas l'uid 11. Je ne vois pas d'invite de confirmation de restauration ou quoi que ce soit qui se produise visuellement. Voici les lignes de logcat pertinentes :
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.
Comme on peut le voir, le BackupManagerService sait que je demande une restauration de l'uid 11. Il indique également qu'il lance l'interface utilisateur de confirmation, même si je ne vois rien s'afficher. Finalement, la demande s'arrête.
-
Exécuter bu -user <uid> <backup file> en étant connecté au profil du propriétaire. Voici les lignes de logcat pertinentes :
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.
Comme lors de la première tentative, nous voyons que le BackupManagerService essaie de faire une restauration pour l'uid 11. Il lance l'interface de confirmation, qui s'affiche. Je confirme alors la restauration. Mais nous voyons ensuite que c'est l'uid 0 qui confirme la restauration et je pense que c'est la raison pour laquelle le jeton résultant est invalide. C'est logique, pourquoi un profil devrait-il être capable de confirmer la sauvegarde/restauration d'un autre profil ? (il serait un peu plus logique que le profil du propriétaire puisse le faire).
Donc je pense que je suis dans une impasse ici. Je ne sais pas comment faire pour que l'interface de confirmation s'exécute avec le bon utilisateur. Je soupçonne que cela n'a pas (encore !) été testé par la communauté Android, bien que pourquoi avoir une -user du tout ?
Voici d'autres messages de journal qui peuvent être des indices pour aller de l'avant :
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
