Non è una novità che si possano usare più dispositivi Android con un singolo account Google . L'accensione di un nuovo dispositivo per la prima volta chiede se si desidera archiviare i propri dati con Google, che quindi sincronizzerebbe sempre "alcune cose" con i server di Google, in pratica

• alcuni dati dell'applicazione (se le app lo supportano esplicitamente)
• Password Wi-Fi
• segnalibri del browser
• un elenco delle app installate da Google Play
• parole aggiunte al dizionario utilizzato dalla tastiera su schermo
• la maggior parte delle tue impostazioni personalizzate

I dettagli potrebbero essere trovati nel Google Dashboard . Le domande rilevanti che riguardano tali questioni includono:

• Quali informazioni esegue il backup di Google?
• Cosa è esattamente sincronizzato con Google?
• In che modo Android sincronizza i profili WiFi?

L' API Developers su Google Backup fornisce ulteriori approfondimenti su come dovrebbe funzionare il backup (e diverse domande qui mostrano come funziona davvero - cioè, a volte lo fa, a volte solo in parte, a volte per niente). A parte l'affidabilità e il fatto che non tutti vogliono i suoi dati privati ​​nel cloud (e anche menzionato il riferimento API ^{2 2} avverte: Android non fornisce garanzie sulla sicurezza dei tuoi dati durante l'utilizzo del backup. Dovresti sempre essere cauto sull'uso del backup per archiviare i dati sensibili dati, come nomi utente e password. ), la mia domanda principale è:

Dopo aver eseguito il backup dei dati da più dispositivi utilizzando lo stesso account:

• cosa succederebbe se un dispositivo ripristinato in fabbrica fosse utilizzato in quel modo prima? Sarebbe riconosciuto, e sarebbero state ripristinate solo quelle cose che sono state usate su di esso prima?
  ^{(l'identificazione del dispositivo potrebbe ad esempio avvenire ad esempio tramite IMEI (ma non tramite Android_ID, poiché potrebbe essere ripristinato con un ripristino delle impostazioni di fabbrica ) - e questo potrebbe essere il motivo del comportamento descritto nella risposta di Nalum )}
• cosa verrebbe ripristinato su un dispositivo (nuovo / ripristinato in fabbrica) che hai appena inizializzato per la prima volta con questo account Google?
  ^{(se i dispositivi verranno identificati con i backup nell'account Google utilizzato, ciò potrebbe attivare un'azione speciale per "nuovo dispositivo", ad esempio "ripristina tutto, dispositivo modificato!" - o "ripristina tutto dal dispositivo X non più connesso, poiché probabilmente è stato sostituito! "- ma attenersi a" ripristinare solo ciò che era su quel dispositivo "in caso di ripristino delle impostazioni di fabbrica)}

L'accordo è: se uno ha più dispositivi, vengono spesso utilizzati per problemi specifici, quindi non si desidera tutto su tutti i dispositivi. Dato che non ho visto alcun modo per scegliere quali dati eseguire il backup (ad esempio per escludere quei "dati sensibili" di cui siamo stati avvertiti: le password WiFi appartengono a quella categoria), presumo che non ci sia scelta sul ripristino? Quindi, come viene gestito?

Parliamo di set, piccola

Il servizio di backup di Android ha un concetto chiamato set : l'insieme di tutti i dati di cui è stato eseguito il backup da un dispositivo (su un trasporto , ma questo è un dettaglio). Ogni set è identificato da una stringa univoca, come l'IMEI sul dispositivo. Quando viene eseguito il backup di un'app (o dell'elenco delle app installate), i suoi dati di backup vanno nel set associato al dispositivo da cui viene eseguito il backup. Tutti i set sono ancora specifici per l'account Google dell'utente. Se cancelli il tuo dispositivo e lo vendi a qualcun altro, non sarà in grado di accedere al set di quel dispositivo a meno che non riesca ad accedere al tuo account Google.

Comportamento predefinito

Quando un'app è installata o un dispositivo ha il suo elenco di app ripristinato, il sistema di backup cerca prima nel set di quel dispositivo i dati di backup per quel pacchetto. Se non ne trova (sia perché è un dispositivo completamente nuovo senza dati di backup, sia perché quel pacchetto non è mai stato installato su quel dispositivo), espanderà la ricerca ad altri set. (Se esiste una scelta, utilizzerà l'ultimo set utilizzato per un ripristino completo del dispositivo.)

Pertanto, quando configuri un nuovo dispositivo, ripristinerà l'elenco delle app dal backup di un vecchio dispositivo e ripristinerà ciascuna app dal backup del vecchio dispositivo. Se hai installato un'app su un dispositivo e la installi su un altro dispositivo, l'app verrà ripristinata con i suoi dati dal vecchio dispositivo. In entrambi i casi, i dati vengono ora sottoposti a backup nel set del nuovo dispositivo, il che significa che i dati di backup dai due dispositivi sono separati da ora in poi.

Dopo aver ripristinato le impostazioni di fabbrica di un dispositivo, verrà ripristinato dall'ultimo backup di quel dispositivo, se ce n'è uno, e, in caso contrario, dal backup di qualche altro dispositivo se ce n'è uno, ma inizierà a creare il proprio set da quel momento in poi. Ecco perché i due dispositivi di Nalum non vedono le app di backup degli altri: si stanno ripristinando dai loro ultimi backup.

fonte

Questo meccanismo non ha alcuna documentazione rivolta all'utente, poiché dovrebbe fare automaticamente la cosa giusta, ma il codice è disponibile .

bmgr: uso di base

Come ha scoperto Izzy, lo bmgrstrumento ti dà un certo controllo su questo processo. È inteso come un aiuto per i programmatori per testare ed eseguire il debug dell'integrazione del backup nelle loro app. È possibile utilizzare questo strumento adb shellper attivare backup e ripristini dei pacchetti scelti, cancellare i dati di backup dei pacchetti e persino ripristinare l'intero dispositivo.

Non tentare di usarlo in una shell sul dispositivo, tranne come root : è necessario il livello android.permission.BACKUPdi sistema per fare qualcosa di interessante con esso.

Puoi fare in modo che un'app aggiorni immediatamente i suoi dati di backup:

bmgr backup com.shadowburst.showr
bmgr run

(o qualunque sia il nome del pacchetto dell'app). Normalmente non è necessario eseguire questa operazione, poiché le app richiedono i propri backup ogni volta che i loro dati cambiano, ma ciò consente di aggirare un'app scritta male. Per ripristinare un pacchetto dai dati di backup, sceglierebbe per impostazione predefinita:

bmgr restore com.shadowburst.showr

ma ancora una volta, questo farà solo ciò che il dispositivo farebbe da solo, quindi non dovresti aver bisogno di usarlo. Si noti inoltre che il dispositivo deve già essere installato per farlo funzionare.

Più controllo

Ora per le cose che il sistema di backup non farà al suo attivo. Per vedere quali set di dati di backup sono disponibili:

bmgr list sets

e otterrai un output come questo:

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

Il numero esadecimale a 64 bit a sinistra è un token . Ne avrai bisogno tra un minuto. La cosa a destra è un nome (relativamente) amichevole per il dispositivo proprietario del set. Ad esempio, manta è il nome in codice del nexus-10 ; TF-101 si riferisce al trasformatore originale asus-eee-pad-pad . Dopo aver capito quale set vuoi, puoi ripristinare un'app da quel set usando il suo token:

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

È possibile aggiungere più nomi di pacchetti alla fine del comando per ripristinare più pacchetti contemporaneamente oppure non è possibile specificare nessun nome di pacchetto (solo il token) per ripristinare ogni app con i dati in quel set (ovvero, fa un sistema completo ristabilire).

Infine, puoi cancellare i dati di un'app dal set corrente:

bmgr wipe com.shadowburst.showr

Questo farà ripartire da zero la sua prossima operazione di backup. Questo potrebbe essere utile dopo aver disinstallato un'app, se un errore nell'app ha danneggiato i suoi dati di backup e non vuoi ripristinarlo.

Non puoi fare in modo che un dispositivo inizi a scrivere in un set diverso, né puoi cancellare un intero set.

Quanto segue non è di gran lunga una risposta alla domanda, ma potrebbe fare luce su alcuni dettagli:

Alcuni pezzi estratti dall'API di backup

Sebbene l'API sia rivolta principalmente agli sviluppatori, ci sono alcuni fatti che potremmo essere in grado di estrarre per il nostro caso. Nell'elenco seguente, il corsivo segna le virgolette dalla documentazione dell'API.

• Android esegue automaticamente un'operazione di ripristino quando l'applicazione è installata e sono presenti dati di backup associati all'utente.
  → questo può significare due cose:
  • se un'app supporta l'API di backup di Google e l'utente ha abilitato il backup di Google, i dati di backup disponibili verranno automaticamente ripristinati al momento dell'installazione. Buona cosa quando installi un'app utilizzata su un singolo dispositivo su un secondo dispositivo per la prima volta.
  • i backup sono associati solo all'account Google, non al dispositivo ( e esistono dati di backup associati all'utente ) oppure l'altro fatto è stato semplicemente ignorato come irrilevante per questo caso speciale ("l'app è installata")
• Il trasporto di backup è il componente lato client del framework di backup di Android, che è personalizzabile dal produttore del dispositivo e dal fornitore di servizi. Il trasporto di backup potrebbe differire da dispositivo a dispositivo [...]
  → ciò potrebbe spiegare l'inaffidabilità quando si tratta di dispositivi diversi (o diverse versioni di Android).
  ^{(enfatizzare il mio)}
• Il backup dei dati non è garantito per essere disponibile su tutti i dispositivi Android.
  (nessun commento)
• Google fornisce un trasporto di backup con il servizio di backup Android per la maggior parte dei dispositivi basati su Android con Android 2.2 o versioni successive.
  → qui è disponibile la versione minima di Android richiesta per Google Backup: Froyo, AKA Android 2.2
• Per ottenere la chiave del servizio di backup, registrati per il servizio di backup Android. [...]
  → ogni app deve avere la propria chiave. Non c'è un "perché" descritto, ma una buona ipotesi: isolare i backup in modo che nessuna app possa leggere i backup di un'altra app (chiave errata; come per i backup di un altro utente: account errato)
• Durante lo sviluppo dell'applicazione, è possibile avviare un'operazione di backup immediata da Gestione backup con lo strumento bmgr.
  → sembra che ci sia un modo per attivare manualmente i backup? Scaviamolo più avanti. ↓
• Quando è il momento di ripristinare i dati dell'applicazione, Gestione backup chiama il onRestore()metodo dell'agente di backup .
  → questo sottolinea ancora una volta il primo elemento di questo elenco: prima l'app deve essere installata, quindi le proprie implementazioni vengono utilizzate per ripristinare i suoi dati. A un secondo sguardo: se il ripristino dell'app non riesce, non ci sarà un ripristino dei dati per le app guaste, fino a quando non le installerai manualmente tramite Google Play. Quindi, come mostrato dal primo elemento, i dati dovrebbero essere ripristinati automaticamente tramite Google Backup nelle condizioni spiegate (deve essere stato eseguito il backup con esso, stesso account, ecc.)
• Eseguire il backup di altri file
  → perdonami non citando i contenuti (tecnici) di quel capitolo, ma in breve: è possibile eseguire il backup solo dei file dalla memoria interna.

Alcuni pezzi estratti dall'API di bmgr

• Fornisce comandi per indurre operazioni di backup e ripristino [...]
  → sembra che qui sia un modo per innescare azioni manualmente se l'automatismo fallisce
• Questi comandi sono accessibili tramite la shell adb.
  → questo non ha bisogno di alcuna spiegazione :)
• adb shell bmgr backup <package>
  → OK, quindi questa azione è legata alle app. Indovina se conosci il nome del pacchetto del fornitore di dati, dovrebbe funzionare anche questo (ad es. com.android.providers.settingsPer le impostazioni di sistema o com.android.providers.telephonyper SMS / MMS ecc.?)
• è possibile forzare l'esecuzione immediata di tutte le operazioni di backup in sospeso utilizzando il bmgr runcomando
  → il primo comando "pianifica" i backup. Avendo attivato tutti i pacchetti, questo può essere usato per eseguirli immediatamente.
• adb shell bmgr restore <package>
  → sembra bello essere vero, vero? Esatto, perché: Gestione backup eseguirà immediatamente un'istanza dell'agente di backup dell'applicazione e lo invocherà per il ripristino. Solo dati, poiché l'app deve già essere presente (come vengono chiamate le sue routine).

Quindi in breve: bmgrpuò essere utilizzato per attivare i backup per le app che supportano Google Backup, che hai installato, e può attivare il ripristino dei dati per lo stesso. Non può essere utilizzato per attivare un ripristino completo, almeno non documentato qui.

Altre informazioni sul backup di Google. Quando ho eseguito il flashing di un firmware personalizzato, le app non sono state ripristinate come previsto. In Impostazioni -> Backup e ripristino mostrava "Backup nella cache privata di solo debug" e bmgr list setsnon ha dato risultati.
Ho risolto il mio problema eseguendo questi passaggi adb shell:
$ bmgr transport com.google.android.backup/.BackupTransportService
$ bmgr list sets 3a0a00a516a1daf1 : LT22i
Tuttavia, non era abbastanza. Non ha iniziato l'installazione di app. Ciò ha mostrato il motivo per cui:
$ bmgr list sets 3179e4ab08d74930 : LT22i 3a0a00a516a1daf1 : LT22i
aveva creato un nuovo set, sebbene l'IMEI fosse ovviamente lo stesso. Comunque, questa è stata la correzione:
$ bmgr restore 3a0a00a516a1daf1(l'ID che ha mostrato la prima volta)
$ bmgr run(per essere sicuri)
Quindi ha iniziato a scaricare le app.

La mia esperienza con questo è stata che ogni dispositivo ha il proprio backup. Ottengo questo da scherzare con il mio Nexus 7 e il mio Galaxy S II. A parte questo, non lo so.

applicazioni:

Il mio Nexus 7 ha queste app Caustic , DC Comics e 20 Minute Meals che al ripristino delle impostazioni di fabbrica del mio Galaxy S II non sono installate sul Galaxy S II.

Il mio Galaxy S II ha queste app DriveDroid e Human Japanese che al ripristino delle impostazioni di fabbrica del mio Nexus 7 non sono installate sul Nexus 7.

Le app sono compatibili con entrambi i dispositivi, quindi l'incompatibilità non può essere la ragione per cui non possono essere installate sul rispettivo altro dispositivo.

Dati:

Per quanto riguarda Wifi e altri dati, non sono sicuro poiché ogni volta che ho impostato Wifi su ciascun dispositivo durante la configurazione iniziale di Android. Per quanto riguarda gli altri account Google che potresti avere, non sembrano essere copiati su ciascun dispositivo e lo stesso vale per gli account Skype e GitHub su ciascun dispositivo.

Ho eseguito il backup delle cose utilizzando sia il backup Google integrato sia il backup Helium prima di cancellare e installare la ROM personalizzata Carbon su un Nexus 4 (dallo stock di KitKat). Si aspettava che Google ripristinasse app, impostazioni, ecc. Come ha fatto prima quando ho ripristinato questo telefono, ma senza gioia.

Ho provato anche Helium, anche nessuna gioia, anche con i ripristini manuali 'Download del PC' - ha detto 'ripristinato' ma i dati di Wifi e app non sono ancora lì.

L'esecuzione del bmgr restore <xxx>ripristino completo e bmgr runcome descritto sopra ha attivato il ripristino completo di Google e ha funzionato a meraviglia: salvavita per me!

Google potrebbe fare uno sforzo migliore, soprattutto se vogliono competere con l'idea di Apple "funziona" ... Adoro comunque l'hackability di Android nonostante le sue insidie!