Não é novidade que se possa usar vários dispositivos Android com uma única conta do Google . A ativação de um novo dispositivo pela primeira vez pergunta se alguém deseja armazenar seus dados com o Google, que sempre sincronizaria "algumas coisas" com os servidores do Google, basicamente

• alguns dados do aplicativo (se os aplicativos o suportarem explicitamente)
• Senhas de Wi-Fi
• favoritos do navegador
• uma lista dos aplicativos instalados no Google Play
• palavras adicionadas ao dicionário usado pelo teclado na tela
• a maioria das suas configurações personalizadas

Detalhes podem ser encontrados no Google Dashboard . As perguntas relevantes aqui abordando esses problemas incluem:

• Quais informações o Google faz backup?
• O que exatamente é sincronizado com o Google?
• Como o Android sincroniza os perfis de WiFi?

A API do desenvolvedor no Google Backup fornece algumas informações adicionais sobre como o material de backup deve funcionar (e várias perguntas aqui mostram como ele realmente funciona - ou seja, às vezes funciona, às vezes apenas parcialmente e às vezes não funciona). Além da confiabilidade e do fato de que nem todo mundo deseja seus dados privados na nuvem (e até a referência mencionada na API ² adverte: o Android não garante a segurança dos seus dados ao usar o backup. Você deve sempre ter cuidado ao usar o backup para armazenar informações confidenciais). dados, como nomes de usuário e senhas. ), minha pergunta principal é:

Depois de fazer backup de dados de vários dispositivos usando a mesma conta:

• o que aconteceria com um dispositivo de redefinição de fábrica sendo usado dessa maneira antes? Seria reconhecido, e somente serão restauradas as coisas que já foram usadas antes?
  ^{(a identificação do dispositivo pode, por exemplo, ocorrer por exemplo, via IMEI (mas não pelo Android_ID, pois isso pode ter ocorrido com uma redefinição de fábrica ) - e esse pode ser o motivo do comportamento descrito na resposta de Nalum )}
• o que seria restaurado para um dispositivo (novo / redefinido de fábrica) que você acabou de inicializar pela primeira vez com esta Conta do Google?
  ^{(se os dispositivos forem identificados com backups na Conta do Google usada, isso poderá desencadear uma ação especial para "novo dispositivo", por exemplo, "restaurar tudo, dispositivo alterado!" - ou "restaurar todos do dispositivo X não conectado mais, como provavelmente foi substituído! "- mas continue com" restaurar apenas o que estava no dispositivo "no caso de uma redefinição de fábrica)}

O negócio é: se um possui vários dispositivos, eles geralmente são usados ​​para problemas específicos; portanto, não se deseja tudo em todos os dispositivos. Como eu não vi nenhuma maneira de escolher quais dados fazer backup (por exemplo, para excluir os "dados confidenciais" sobre os quais fomos avisados: as senhas de WiFi pertenceriam a essa categoria), presumo que também não há opção de restauração? Então, como isso é tratado?

Vamos falar sobre conjuntos, baby

O serviço de backup do Android tem um conceito chamado conjunto : o conjunto de todos os dados armazenados em backup de um dispositivo (em um transporte , mas isso é um detalhe). Cada conjunto é identificado por uma sequência única, como o IMEI no dispositivo. Quando um aplicativo (ou a lista de aplicativos instalados) é copiado, seus dados de backup entram no conjunto associado ao dispositivo do qual está sendo copiado. Todos os conjuntos ainda são específicos da conta do Google do usuário. Se você limpar seu dispositivo e vendê-lo para outra pessoa, ele não poderá acessar o conjunto desse dispositivo, a menos que possa fazer login na sua conta do Google.

Comportamento padrão

Quando um aplicativo é instalado ou um dispositivo tem sua lista de aplicativos restaurados, o sistema de backup primeiro procura no conjunto desse dispositivo os dados de backup desse pacote. Se não encontrar nenhum (seja por ser um dispositivo completamente novo sem dados de backup ou porque esse pacote nunca foi instalado nesse dispositivo), ele expandirá a pesquisa para outros conjuntos. (Se houver uma opção, ele usará o último conjunto usado para uma restauração de dispositivo completo.)

Assim, quando você configura um novo dispositivo, ele restaura a lista de aplicativos do backup de um dispositivo antigo e restaura cada aplicativo do backup do dispositivo antigo. Se você tinha um aplicativo instalado em um dispositivo e o instalou em outro dispositivo, o aplicativo será restaurado com seus dados do dispositivo antigo. Em ambos os casos, os dados agora são armazenados em backup no novo conjunto de dispositivos, o que significa que os dados de backup dos dois dispositivos são separados daqui para a frente.

Após a redefinição de fábrica de um dispositivo, ele será restaurado a partir do último backup desse dispositivo, se houver, e, na sua falta, a partir do backup de outro dispositivo, se houver um, mas começará a criar seu próprio conjunto a partir de então. É por isso que os dois dispositivos da Nalum não veem os aplicativos de backup um do outro: eles estão restaurando a partir de seus últimos backups.

Fonte

Esse mecanismo não possui nenhuma documentação voltada ao usuário, pois ele deve fazer automaticamente a coisa certa, mas o código está disponível .

bmgr: uso básico

Como Izzy descobriu, a bmgrferramenta fornece algum controle sobre esse processo. O objetivo é ajudar os programadores a testar e depurar a integração de backup em seus aplicativos. Você pode usar esta ferramenta adb shellpara acionar backups e restaurações de pacotes escolhidos, limpar os dados de backup dos pacotes e até mesmo uma restauração do dispositivo inteiro.

Não tente usá-lo em um shell no dispositivo, exceto como root : você precisa do nível do sistema android.permission.BACKUPpara fazer algo interessante com ele.

Você pode fazer um aplicativo atualizar seus dados de backup imediatamente:

bmgr backup com.shadowburst.showr
bmgr run

(ou qualquer que seja o nome do pacote do aplicativo). Normalmente, não é necessário fazer isso, pois os aplicativos solicitam seus próprios backups sempre que os dados são alterados, mas isso permite que você trabalhe com um aplicativo mal escrito. Para restaurar um pacote a partir dos dados de backup, ele escolheria por padrão:

bmgr restore com.shadowburst.showr

mas, novamente, isso fará apenas o que o dispositivo faria sozinho, portanto você não precisará usá-lo. Observe também que o dispositivo já precisa estar instalado para fazer isso funcionar.

Mais controle

Agora, as coisas que o sistema de backup não fará por si só. Para ver quais conjuntos de dados de backup estão disponíveis:

bmgr list sets

e você obterá uma saída como esta:

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

O número hexadecimal de 64 bits à esquerda é um token . Você precisará disso em um minuto. O que está à direita é um nome (relativamente) amigável para o dispositivo que possui o aparelho. Por exemplo, manta é o nome de código para o nexus-10 ; TF-101 refere - se ao transformador asus-eee-pad original . Depois de descobrir qual conjunto você deseja, você pode restaurar um aplicativo desse conjunto usando seu token:

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

Você pode adicionar mais nomes de pacotes ao final do comando para restaurar vários pacotes de uma só vez ou não pode especificar nenhum nome de pacote (apenas o token) para restaurar todos os aplicativos com dados nesse conjunto (ou seja, ele faz um sistema completo restaurar).

Por fim, você pode limpar os dados de um aplicativo do conjunto atual:

bmgr wipe com.shadowburst.showr

Isso fará com que sua próxima operação de backup comece do zero. Isso pode ser útil após a desinstalação de um aplicativo, se um erro no aplicativo corromper seus dados de backup e você não desejar que ele seja restaurado.

Você não pode fazer um dispositivo começar a gravar em um conjunto diferente, nem pode limpar um conjunto inteiro.

De longe, não há resposta para a pergunta, mas pode esclarecer alguns detalhes:

Algumas peças extraídas da API de backup

Embora a API seja direcionada principalmente aos desenvolvedores, há alguns fatos que podemos extrair para o nosso caso. Na lista a seguir, o itálico marca aspas da documentação da API.

• O Android executa automaticamente uma operação de restauração quando seu aplicativo está instalado e existem dados de backup associados ao usuário.
  → isso pode significar duas coisas:
  • se um aplicativo suportar a API de backup do Google e o usuário tiver o Google Backup ativado, os dados de backup disponíveis serão restaurados automaticamente na instalação. Ainda bem que você instala um aplicativo usado em um único dispositivo em um segundo dispositivo pela primeira vez.
  • os backups são associados apenas à Conta do Google, não ao dispositivo ( e existem dados de backup associados ao usuário ) - ou o outro fato foi ignorado como irrelevante para este caso especial ("o aplicativo está instalado")
• O transporte de backup é o componente do cliente da estrutura de backup do Android, personalizável pelo fabricante do dispositivo e pelo provedor de serviços. O transporte de backup pode diferir de dispositivo para dispositivo [...]
  → isso pode explicar a falta de confiabilidade quando se trata de dispositivos diferentes (ou versões diferentes do Android).
  ^{(ênfase minha)}
• Não há garantia de que o backup de dados esteja disponível em todos os dispositivos Android.
  (sem comentários)
• O Google fornece um transporte de backup com o Serviço de backup do Android para a maioria dos dispositivos Android com Android 2.2 ou superior.
  → aqui temos a versão mínima do Android necessária para que o Google Backup esteja disponível: Froyo, AKA Android 2.2
• Para obter sua chave do serviço de backup, registre-se no serviço de backup do Android. [...]
  → cada aplicativo deve ter sua própria chave. Não há um "porquê" descrito, mas um bom palpite: isolar os backups para que nenhum aplicativo possa ler backups de outro aplicativo (chave errada; como para backups de outro usuário: conta errada)
• Ao desenvolver seu aplicativo, você pode iniciar uma operação de backup imediato no Gerenciador de Backup com a ferramenta bmgr.
  → parece que existe uma maneira de acionar backups manualmente? Vamos investigar isso mais tarde. ↓
• Quando é hora de restaurar os dados do aplicativo, o Gerenciador de backup chama o onRestore()método do seu agente de backup .
  → isso sublinha novamente o primeiro item desta lista: primeiro o aplicativo deve ser instalado e, em seguida, suas próprias implementações são usadas para restaurar seus dados. Em uma segunda olhada: se a restauração do aplicativo falhar, não haverá uma restauração de dados para os aplicativos com falha - até você instalá-los manualmente pelo Google Play. Em seguida, como o primeiro item mostrou, os dados devem ser restaurados automaticamente pelo Google Backup nas condições explicadas (é necessário fazer backup com ele, a mesma conta etc.)
• Fazendo backup de outros arquivos
  → perdoe-me não citando o conteúdo (técnico) desse capítulo, mas resumindo: somente arquivos do armazenamento interno podem ser copiados de acordo com ele.

Algumas peças extraídas da API bmgr

• Ele fornece comandos para induzir operações de backup e restauração
  → [...] parece que aqui está uma maneira de acionar ações manualmente se o "automatismo" falhar
• Esses comandos são acessados ​​através do shell adb.
  → isso não precisa de explicação :)
• adb shell bmgr backup <package>
  → OK, então esta ação está vinculada aos aplicativos. Acho que se você souber o nome do pacote do provedor de dados, isso também deve funcionar (por exemplo, com.android.providers.settingspara as configurações do sistema ou com.android.providers.telephonypara SMS / MMS, etc?)
• você pode forçar a execução imediata de todas as operações de backup pendentes usando o bmgr runcomando
  → o primeiro comando apenas "agenda" os backups. Após acionar todos os pacotes, isso pode ser usado para executá-los imediatamente.
• adb shell bmgr restore <package>
  → parece bom demais para ser verdade, certo? Exatamente porque: O Gerenciador de Backup instancia imediatamente o agente de backup do aplicativo e o invoca para restauração. Somente dados, pois o aplicativo já precisa estar lá (como são chamadas suas rotinas).

Em resumo: bmgrpode ser usado para acionar backups de aplicativos compatíveis com o Google Backup, que você instalou - e pode acionar a restauração de dados para o mesmo. Não pode ser usado para acionar uma restauração completa - pelo menos isso não está documentado aqui.

Mais algumas informações sobre o backup do Google. Quando eu atualizei um firmware personalizado, ele não restaurou os aplicativos como eu esperava. Em Configurações -> Fazer backup e redefinir , estava mostrando "Fazendo backup em cache privado somente de depuração" e bmgr list setsnão deu resultados.
Resolvi meu problema executando estas etapas adb shell:
$ bmgr transport com.google.android.backup/.BackupTransportService
$ bmgr list sets 3a0a00a516a1daf1 : LT22i
Porém, isso não foi suficiente. Não começou a instalar aplicativos. Isso mostrou o motivo:
$ bmgr list sets 3179e4ab08d74930 : LT22i 3a0a00a516a1daf1 : LT22i
criou um novo conjunto, embora o IMEI obviamente fosse o mesmo. De qualquer forma, essa foi a correção:
$ bmgr restore 3a0a00a516a1daf1(o ID exibido pela primeira vez)
$ bmgr run(com certeza)
Em seguida, começou a baixar os aplicativos.

Minha experiência com isso foi que cada dispositivo tem seu próprio backup. Eu entendo isso de brincar com meu Nexus 7 e meu Galaxy S II. Fora isso eu não sei.

Apps:

Meu Nexus 7 possui esses aplicativos Caustic , DC Comics e 20 Minute Meals que, após a redefinição de fábrica do meu Galaxy S II, não estão instalados no Galaxy S II.

O My Galaxy S II possui os aplicativos DriveDroid e Human Japanese que, após a redefinição de fábrica do meu Nexus 7, não são instalados no Nexus 7.

Os aplicativos são compatíveis com os dois dispositivos, portanto, a incompatibilidade não pode ser o motivo para eles não serem instalados no outro dispositivo.

Dados:

Quanto ao Wifi e outros dados, não tenho certeza, pois toda vez que eu configuro o Wifi em cada dispositivo durante a configuração inicial do Android. Quanto às outras contas do Google que você possa ter, elas parecem não ser copiadas para cada dispositivo e o mesmo ocorre com as contas do Skype e GitHub em cada dispositivo.

Fiz backup das coisas usando o backup interno do Google e o Helium antes de limpar e instalar a ROM personalizada do Carbon em um Nexus 4 (do estoque KitKat). O Google esperava restaurar aplicativos, configurações etc., como antes, quando restaurei este telefone, mas sem alegria.

Tentei o Hélio também, também sem alegria, mesmo com as restaurações manuais do 'PC Download' - disse 'restaurado', mas os dados de Wifi e de aplicativos ainda não estão lá.

A execução da bmgr restore <xxx>restauração completa e, bmgr runconforme detalhado acima, acionou a restauração completa do Google e funcionou como um deleite para toda a vida!

O Google poderia fazer um esforço melhor, especialmente se eles quiserem competir com a idéia "simplesmente funciona" da Apple ... Mesmo assim, eu amo a capacidade de hackers do Android, apesar de suas armadilhas!