Ce n'est pas nouveau que l' on puisse utiliser plusieurs appareils Android avec un seul compte Google . Mettre en marche un nouvel appareil pour la première fois demande si on veut stocker ses données avec Google, qui synchroniserait alors toujours "certaines choses" avec les serveurs de Google, essentiellement
- certaines données d'application (si les applications le supportent explicitement)
- Mots de passe Wi-Fi
- signets du navigateur
- une liste des applications installées à partir de Google Play
- mots ajoutés au dictionnaire utilisé par le clavier à l'écran
- la plupart de vos paramètres personnalisés
Les détails peuvent être trouvés dans le tableau de bord Google . Les questions pertinentes abordant ces questions incluent:
- Quelles informations Google sauvegarde-t-il?
- Qu'est-ce qui est synchronisé avec Google?
- Comment Android synchronise-t-il les profils WiFi?
L’ API des développeurs sur Google Backup fournit des informations supplémentaires sur le fonctionnement supposé du matériel de sauvegarde (et plusieurs questions ici expliquent son fonctionnement réel: c’est parfois le cas, parfois seulement partiellement, voire pas du tout). Mis à part la fiabilité et le fait que tout le monde veut ses données privées dans le nuage (et même mentionné la référence API 2 met en garde: Android ne fait aucune garantie quant à la sécurité de vos données lors de l' utilisation de sauvegarde Vous devez toujours être prudent sur l' utilisation de sauvegarde pour stocker sensibles. données, telles que les noms d’utilisateur et les mots de passe. ), ma question principale est:
Après avoir sauvegardé les données de plusieurs appareils utilisant le même compte:
- qu'adviendrait-il d'un périphérique réinitialisé en usine utilisé de cette manière auparavant? Serait-il reconnu et n'aurait-il que les objets restaurés qui ont été utilisés auparavant?
(l'identification de l'appareil pourrait par exemple se faire par exemple via IMEI (mais pas via Android_ID, car cela pourrait disparaître avec une réinitialisation d'usine ) - ce qui pourrait expliquer le comportement décrit dans la réponse de Nalum ) - qu'est-ce qui serait restauré sur un périphérique (nouveau / réinitialisé) que vous venez d'initialiser pour la première fois avec ce compte Google?
(si les périphériques étaient identifiés avec des sauvegardes dans le compte Google utilisé, cela pourrait déclencher une action spéciale pour "nouveau périphérique", par exemple "restaurer tout, le périphérique a été modifié!" - ou "restaurer tout depuis le périphérique X qui n'est plus connecté, comme il a probablement été remplacé! "- mais tenez-vous à" restaurer uniquement ce qu'il y avait sur cet appareil "en cas de réinitialisation d'usine)
Le problème est le suivant: si l’on dispose de plusieurs appareils, ceux-ci sont souvent utilisés pour des problèmes spécifiques; on ne veut donc pas tout sur tous les appareils. Comme je n'ai pas trouvé le moyen de choisir les données à sauvegarder (par exemple, pour exclure les "données sensibles" pour lesquelles nous avons été avertis: les mots de passe WiFi appartiendraient à cette catégorie), je suppose qu'il n'y a pas d'autre choix en matière de restauration? Alors, comment est-ce géré?
Réponses:
Parlons des ensembles, bébé
Le service de sauvegarde d'Android a un concept appelé ensemble : l'ensemble de toutes les données sauvegardées à partir d'un périphérique (sur un transport , mais c'est un détail). Chaque ensemble est identifié par une chaîne unique, telle que l'IMEI sur le périphérique. Lorsqu'une application (ou la liste des applications installées) est sauvegardée, ses données de sauvegarde sont stockées dans l'ensemble associé au périphérique à partir duquel elle est sauvegardée. Tous les ensembles sont toujours spécifiques au compte Google de l'utilisateur. Si vous nettoyez votre appareil et que vous le vendez à quelqu'un d'autre, il ne pourra pas accéder à l'ensemble de cet appareil à moins de pouvoir se connecter à votre compte Google.
Comportement par défaut
Lorsqu'une application est installée ou que la liste des applications d'un périphérique est restaurée, le système de sauvegarde commence par rechercher dans le jeu de ce périphérique les données de sauvegarde de ce package. S'il n'en trouve pas (soit parce que c'est un tout nouveau périphérique sans données sauvegardées, soit parce que ce paquet n'a jamais été installé sur ce périphérique), la recherche sera étendue à d'autres ensembles. (Si vous avez le choix, le dernier jeu utilisé pour une restauration complète du périphérique sera utilisé.)
Ainsi, lorsque vous configurez un nouvel appareil, il restaure la liste des applications à partir de la sauvegarde d'un ancien appareil, et chaque application à partir de la sauvegarde de l'ancien appareil. Si une application est installée sur un appareil et que vous l'installez sur un autre appareil, l'application sera restaurée avec les données de l'ancien appareil. Dans les deux cas, les données sont maintenant sauvegardées dans l'ensemble du nouveau périphérique, ce qui signifie que les données de sauvegarde des deux périphériques sont désormais séparées.
Une fois que vous avez réinitialisé les périphériques, un périphérique est restauré à partir de la dernière sauvegarde de ce périphérique, le cas échéant, et à partir de la sauvegarde d'un autre périphérique, le cas échéant, mais il commence à créer son propre jeu à partir de ce moment. C'est pourquoi les deux appareils de Nalum ne voient pas les applications sauvegardées les uns des autres: ils restaurent chacun à partir de leurs propres sauvegardes.
La source
Ce mécanisme ne contient aucune documentation orientée utilisateur, car il est censé faire automatiquement le bon choix, mais le code est disponible .
bmgr
: utilisation de baseComme l'a constaté Izzy, l'
bmgr
outil vous donne un certain contrôle sur ce processus. Il est conçu pour aider les programmeurs à tester et à déboguer l’intégration de sauvegarde dans leurs applications. Vous pouvez utiliser cet outiladb shell
pour déclencher des sauvegardes et des restaurations des packages choisis, effacer les données sauvegardées des packages et même une restauration complète de l'appareil.N'essayez pas de l'utiliser dans un shell intégré au périphérique, sauf en tant qu'utilisateur root : vous avez besoin du niveau système
android.permission.BACKUP
pour faire quoi que ce soit d'intéressant.Vous pouvez faire en sorte qu'une application mette immédiatement à jour ses données sauvegardées:
(ou quel que soit le nom du package de l'application). Cela n'est normalement pas nécessaire, car les applications demandent leurs propres sauvegardes chaque fois que leurs données changent, mais cela vous permet de contourner une application mal écrite. Pour restaurer un paquet à partir des données sauvegardées, il choisirait par défaut:
mais encore une fois, cela ne fera que ce que le périphérique ferait lui-même, de sorte que vous ne devriez pas avoir besoin de l'utiliser. Notez également que le périphérique doit déjà être installé pour que cela fonctionne.
Plus de contrôle
Passons maintenant aux tâches que le système de sauvegarde ne fera pas. Pour voir quels jeux de données sauvegardées sont disponibles:
et vous aurez une sortie comme celle-ci:
Le nombre hexadécimal de 64 bits à gauche est un jeton . Vous aurez besoin de cela dans une minute. La chose à droite est un nom (relativement) convivial pour le périphérique qui possède l'ensemble. Par exemple, manta est le nom de code du nexus-10 ; TF-101 fait référence au transformateur asus-eee-pad-original . Une fois que vous avez déterminé quel ensemble vous souhaitez, vous pouvez restaurer une application à partir de cet ensemble à l'aide de son jeton:
Vous pouvez ajouter plusieurs noms de package à la fin de la commande pour restaurer plusieurs packages à la fois, ou vous pouvez ne spécifier aucun nom de package (uniquement le jeton) pour restaurer chaque application contenant des données dans cet ensemble (c'est-à-dire qu'elle effectue un système complet. restaurer).
Enfin, vous pouvez effacer les données d'une application du jeu actuel:
Cela fera sa prochaine opération de sauvegarde à partir de zéro. Cela peut être utile après la désinstallation d'une application, si une erreur de celle-ci a corrompu ses données de sauvegarde et que vous ne souhaitez pas qu'elle soit restaurée.
Vous ne pouvez pas faire en sorte qu'un périphérique commence à écrire dans un jeu différent, ni effacer tout un jeu.
la source
Ce qui suit est de loin pas de réponse à la question, mais pourrait éclaircir certains détails:
Quelques extraits de l' API de sauvegarde
Bien que l'API soit principalement destinée aux développeurs, il est possible d'extraire quelques faits pour notre cas. Dans la liste suivante, les italiques indiquent des guillemets dans la documentation de l'API.
→ cela peut signifier deux choses:
→ cela peut expliquer le manque de fiabilité entre différents périphériques (ou différentes versions d'Android).
(c'est moi qui souligne)
(sans commentaire)
→ la version Android minimum requise pour Google Backup est disponible: Froyo, AKA Android 2.2
→ chaque application doit avoir sa propre clé. Il n'y a pas de "pourquoi" décrit, mais une bonne idée: isoler les sauvegardes afin qu'aucune application ne puisse lire les sauvegardes d'une autre application (clé incorrecte; comme pour les sauvegardes d'un autre utilisateur: compte incorrect)
→ semble-t-il possible de déclencher manuellement des sauvegardes? Creusons dans cela plus tard. ↓
onRestore()
méthode de votre agent de sauvegarde .→ Cela souligne à nouveau le premier élément de cette liste: l'application doit d'abord être installée, puis ses propres implémentations sont utilisées pour restaurer ses données. Deuxième aspect: si la restauration de l'application échoue, il n'y aura pas de restauration de données pour les applications en échec, à moins que vous ne les installiez manuellement via Google Play. Ensuite, comme le montre le premier élément, les données doivent être automatiquement restaurées via Google Backup dans les conditions expliquées (elles doivent avoir été sauvegardées avec le même compte, etc.).
→ pardonnez-moi de ne pas citer le contenu (technique) de ce chapitre, mais en résumé: seuls les fichiers de la mémoire interne peuvent être sauvegardés en conséquence.
Quelques morceaux extraits de l' API bmgr
→ voici un moyen de déclencher des actions manuellement en cas d'échec de "l'automatisme"
→ cela ne nécessite aucune explication :)
adb shell bmgr backup <package>
→ OK, cette action est liée aux applications. Si vous connaissez le nom du package du fournisseur de données, cela devrait également fonctionner (par exemple,
com.android.providers.settings
pour les paramètres système, oucom.android.providers.telephony
pour les SMS / MMS, etc.?)bmgr run
commande→ la première commande "planifie" uniquement les sauvegardes. Après avoir déclenché tous les packages, ceci peut être utilisé pour les exécuter immédiatement.
adb shell bmgr restore <package>
→ cela semble trop beau pour être vrai, non? Exactement, parce que: le gestionnaire de sauvegarde instancie immédiatement l'agent de sauvegarde de l'application et l'invoque pour la restauration. Données uniquement, car l'application doit déjà être présente (car ses routines sont appelées).
Donc, en bref:
bmgr
peut être utilisé pour déclencher des sauvegardes pour des applications prenant en charge Google Backup, que vous avez installées - et il peut également déclencher une restauration des données. Il ne peut pas être utilisé pour déclencher une restauration complète - du moins, ce n'est pas documenté ici.la source
Quelques informations supplémentaires sur la sauvegarde de Google. Lorsque j'ai flashé un micrologiciel personnalisé, il n'a pas restauré les applications comme prévu. Dans Paramètres -> Sauvegarde et réinitialisation, le message "Sauvegarde sur le cache privé réservé au débogage" était affiché,
bmgr list sets
sans résultat.J'ai résolu mon problème en procédant comme suit
adb shell
:$ bmgr transport com.google.android.backup/.BackupTransportService
$ bmgr list sets 3a0a00a516a1daf1 : LT22i
Cela n'a toutefois pas suffi. Il n'a pas commencé à installer des applications. Cela en a montré la raison:
$ bmgr list sets 3179e4ab08d74930 : LT22i 3a0a00a516a1daf1 : LT22i
Il avait créé un nouvel ensemble, bien que l’IMEI soit évidemment le même. Quoi qu'il en soit, c'était le correctif:
$ bmgr restore 3a0a00a516a1daf1
(l'identifiant qu'il a montré la première fois)$ bmgr run
(pour être sûr)Ensuite, il a commencé à télécharger les applications.
la source
D'après mon expérience, chaque périphérique dispose de sa propre sauvegarde. Je comprends cela en jouant avec mon Nexus 7 et mon Galaxy S II. Sinon, je ne sais pas.
Applications:
Mon Nexus 7 a ces applications Caustic , DC Comics et 20 Minute Meals qui, lors de la réinitialisation d'usine de mon Galaxy S II, ne sont pas installés sur le Galaxy S II.
Mon Galaxy S II a ces applications DriveDroid et Human Japanese qui, lors de la réinitialisation d'usine de mon Nexus 7, ne sont pas installées sur le Nexus 7.
Les applications étant compatibles avec les deux appareils, leur incompatibilité ne peut donc pas être la raison pour laquelle elles ne sont pas installées sur l'autre appareil respectif.
Les données:
En ce qui concerne le Wi-Fi et d'autres données, je ne suis pas sûr, car chaque fois que j'ai configuré le Wi-Fi sur chaque appareil lors de la configuration initiale d'Android. En ce qui concerne les autres comptes Google que vous pouvez avoir, ils ne semblent pas être copiés sur chaque appareil et il en va de même pour les comptes Skype et GitHub sur chaque appareil.
la source
Avant de nettoyer et d’installer la mémoire ROM personnalisée Carbon sur un Nexus 4 (stock KitKat), j’ai sauvegardé des données à l’aide de la sauvegarde intégrée Google et de la sauvegarde Helium. Google s'attend à restaurer les applications, les paramètres, etc. comme il le faisait auparavant lorsque j'ai restauré ce téléphone, mais pas de joie.
Helium essayé aussi, même pas de joie, même avec la restauration manuelle 'PC Download' - dit 'restaurée' mais Wifi et les données de l'application ne sont toujours pas là.
L 'exécution de
bmgr restore <xxx>
la restauration complète etbmgr run
comme détaillé ci - dessus a déclenché la restauration complète de Google et a fonctionné comme une friandise pour moi!Google pourrait faire un meilleur effort, surtout s’ils veulent rivaliser avec l’idée des «œuvres géniales» d’Apple ... Malgré tout, j’adore le piratage d’Android malgré ses pièges!
la source