Nicht-Root-Backup mit mehreren Benutzern (Nicht-Besitzer oder sekundäre Benutzer)

Wenn Sie Android 4.2.2 verwenden, gibt es eine Möglichkeit, den Bootloader zu entsperren, ohne das Gerät zu löschen. Verwenden Sie Towelroot , um Ihr Gerät zu rooten. (Es funktioniert auf einem neuxs 7, solange Sie einen Kernel-Build < 3. Juni haben). Danach können Sie die folgende App verwenden , um den Bootloader zu entsperren (es löscht das Gerät nicht). Dann können Sie mit Titanium Backup alles auf Ihrem Gerät sichern, auch wenn Sie als sekundärer Benutzer angemeldet sind.

Es wäre hilfreich, expliziter zu sein, was Sie tun, wie bestimmte ADB-Befehle, obwohl ich denke, dass ich auf dasselbe Problem stoße.

Ich glaube, was in Ihrer Situation passiert, ist, dass Sie (unbeabsichtigt) ein Backup des Owner-Benutzers erstellen. Da Sie sich im sekundären Benutzerprofil befinden, wird Ihnen die Aufforderung zum Starten der Sicherung für den Besitzerbenutzer nicht angezeigt . Also hängt adb und wartet auf eine Bestätigung, die Sie nie sehen.

Es ist wichtig zu beachten, dass adb-Sitzungen immer im Kontext des Owner-Benutzers ausgeführt werden. Wenn Sie also keine Benutzer-ID an den Sicherungsprozess übergeben, wird eine Sicherung des Eigentümerprofils durchgeführt.

Wie initiiert man also eine Sicherung/Wiederherstellung in einem Nicht-Besitzer-Profil? Es ist hilfreich zu wissen, dass die adb-Sicherungs- und Wiederherstellungsbefehle am Ende buauf dem System ausgeführt werden. Wenn Sie bu helpvon der Adb-Shell aus ausführen, erhalte ich Folgendes:

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)

Okay, großartig, also gibt es anscheinend eine -userOption. Großartig! Also versuche ich jetzt, eine Wiederherstellung für einen sekundären Benutzer von adb auszuführen, und Folgendes bekomme ich:

$ ./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

Okay, vielleicht ist es pingelig und will die Sicherungsdatei als erstes Argument. Dies führt jedoch zu derselben Ausgabe. Ich habe nicht herausgefunden, warum adb das -userArgument nicht akzeptiert.

Aber es gibt noch eine andere Option, wir können budirekt von der Adb-Shell ausführen. Leider muss ich das auch noch zum Laufen bringen, aber ich komme weiter. Ich lade zuerst das Backup in das Besitzerprofil hoch und führe es buvom Besitzerprofil aus mit der Adb-Shell aus. Ich kenne keine Möglichkeit, eine Adb-Shell in einem Nicht-Eigentümerprofil zu erhalten. Dies sollte jedoch kein Problem sein, denn dafür ist das -userArgument da. Ich habe zwei Szenarien vergeblich versucht.

1. Führen Sie bu -user <uid> <backup file>es aus, während Sie beim Profil dieser UID angemeldet sind, in diesem Fall UID 11. Ich sehe keine Bestätigungsaufforderung für die Wiederherstellung oder irgendetwas passiert visuell. Hier sind relevante Logcat-Zeilen:

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.

Wie zu sehen ist, weiß der BackupManagerService, dass ich eine Wiederherstellung von UID 11 anfordere. Außerdem sagt er, dass die Bestätigungs-Benutzeroberfläche gestartet wird, obwohl nichts angezeigt wird. Irgendwann laufen die Anfragen ab.

2. Ausführen bu -user <uid> <backup file>, während Sie im Besitzerprofil angemeldet sind. Hier sind relevante Logcat-Zeilen:

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.

Wie beim ersten Versuch sehen wir, dass der BackupManagerService versucht, eine Wiederherstellung für uid 11 durchzuführen. Er startet die Bestätigungs-UI, die auftaucht. Ich bestätige dann die Wiederherstellung. Aber dann sehen wir, dass seine uid 0 die Wiederherstellung bestätigt, und ich glaube, das ist der Grund, warum das resultierende Token ungültig ist. Macht Sinn, warum sollte ein Profil in der Lage sein, die Sicherung/Wiederherstellung eines anderen zu bestätigen? (macht etwas mehr Sinn, damit das Besitzerprofil das kann)

Ich glaube also, ich bin hier auf eine Straßensperre gestoßen. Ich bin mir nicht sicher, wie ich die Bestätigungs-Benutzeroberfläche dazu bringen kann, im richtigen Benutzer ausgeführt zu werden. Ich vermute, dass dies (noch!) nicht von der Android-Community getestet wurde, aber warum überhaupt eine -userOption?

Hier sind einige andere Protokollmeldungen, die Hinweise auf einen weiteren Weg geben könnten:

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

Ich glaube nicht, dass es einen Weg gibt, einen Root-Aktivierungs-Exploit zu finden. adb backup -apk -shared -allsichert nur für Benutzer 0 sowohl für /data/user/ als auch /storage/emulated/ (für Nicht-Geräte ohne erweiterbaren Speicher). Auch mit 4.4 kein Glück.