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 ² 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é?

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 base

Comme l'a constaté Izzy, l' bmgroutil 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 outil adb shellpour 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.BACKUPpour 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:

bmgr backup com.shadowburst.showr
bmgr run

(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:

bmgr restore com.shadowburst.showr

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:

bmgr list sets

et vous aurez une sortie comme celle-ci:

  3ff7800e963f25c5 : manta
  3f0e5c90a412cca7 : manta
  3dd65924a70e14c8 : TF101
  3baa67e9ce029355 : m0

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:

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

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:

bmgr wipe com.shadowburst.showr

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.

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.

• Android effectue automatiquement une opération de restauration lorsque votre application est installée et qu'il existe des données de sauvegarde associées à l'utilisateur.
  → cela peut signifier deux choses:
  • Si une application prend en charge l'API Google Backup et que l'utilisateur dispose de cette fonctionnalité, les données de sauvegarde disponibles seront automatiquement restaurées lors de l'installation. Bonne chose lorsque vous installez une application utilisée sur un seul appareil sur un deuxième appareil pour la première fois.
  • les sauvegardes sont uniquement associées au compte Google, pas au périphérique ( et il existe des données de sauvegarde associées à l'utilisateur ) - ou l'autre fait a simplement été ignoré comme non pertinent pour ce cas particulier ("l'application est installée")
• Le transport de sauvegarde est le composant côté client de la structure de sauvegarde d'Android, qui peut être personnalisée par le fabricant du périphérique et le fournisseur de services. Le transport de sauvegarde peut différer d'un périphérique à l'autre [...]
  → cela peut expliquer le manque de fiabilité entre différents périphériques (ou différentes versions d'Android).
  ^{(c'est moi qui souligne)}
• La sauvegarde des données n’est pas garantie sur tous les appareils Android.
  (sans commentaire)
• Google fournit un transport de sauvegarde avec le service de sauvegarde Android pour la plupart des appareils Android fonctionnant sous Android 2.2 ou une version ultérieure.
  → la version Android minimum requise pour Google Backup est disponible: Froyo, AKA Android 2.2
• Pour obtenir votre clé de service de sauvegarde, inscrivez-vous au service de sauvegarde Android. [...]
  → 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)
• Lors du développement de votre application, vous pouvez lancer une opération de sauvegarde immédiate à partir du gestionnaire de sauvegarde avec l'outil bmgr.
  → semble-t-il possible de déclencher manuellement des sauvegardes? Creusons dans cela plus tard. ↓
• Lorsqu'il est temps de restaurer les données de votre application, le gestionnaire de sauvegarde appelle la 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.).
• Sauvegarder d'autres fichiers
  → 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

• Il fournit des commandes pour induire des opérations de sauvegarde et de restauration [...]
  → voici un moyen de déclencher des actions manuellement en cas d'échec de "l'automatisme"
• Ces commandes sont accessibles via le shell adb.
  → 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.settingspour les paramètres système, ou com.android.providers.telephonypour les SMS / MMS, etc.?)
• vous pouvez forcer toutes les opérations de sauvegarde en attente à s'exécuter immédiatement à l'aide de la bmgr runcommande
  → 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: bmgrpeut ê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.

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 setssans 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.

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.

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 et bmgr runcomme 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!