O backup do ADB cria um arquivo de 0 byte; solicita a senha de backup atual, mesmo que eu nunca tenha definido uma; “Falha ao definir a senha” para a senha de backup da área de trabalho


49

O problema:

Toda vez que executo o backup do ADB, recebo uma mensagem na parte inferior da tela inicial dizendo Backup starting..., seguida por uma mensagem dizendo Backup finished alguns segundos depois, apesar de estar usando 17 GB de memória do dispositivo e o arquivo de backup resultante ser criado com um tamanho de 0 bytes. Não recebo mensagens de erro, nenhum feedback indicando que algo está errado, muito menos o que está errado. Parece funcionar, mas rápido demais, e o arquivo de backup está vazio.

O processo:

  1. Confirmo que o dispositivo é reconhecido pelo ADB usando o adb devicescomando e recebo a seguinte saída:

    List of devices attached
    8e1f368a        device
    
  2. Emito o comando de backup do ADB (detalhes a seguir).

  3. Recebo a seguinte mensagem no prompt de comando:

    Now unlock your device and confirm the backup operation.
    

    ... e o seguinte aviso no telefone:

    insira a descrição da imagem aqui

    Não faz diferença o que faço aqui (detalhes a seguir).

  4. Toco no Back up my databotão (canto inferior direito).

  5. O telefone retorna à tela inicial e mostra a Backup starting...mensagem, depois a Backup finishedmensagem alguns segundos depois. Um arquivo de 0 byte é criado, nomeado como backup.ab padrão ou o que eu especificou com a opção -f .

O comando de backup do ADB (usado na etapa 2):

Eu tentei várias combinações de opções, variando de tão simples quanto

adb backup -all

para coisas como

adb backup -all -apk -s 8e1f368a -f 'C:\Data Files\PDA\Backups\ADB\GalaxyS4_20140919.ab'

Eu também tentei adicionar o -nosysteminterruptor depois de ler este e este , que indicam que a tentativa de incluir um sistema de backup em um dispositivo não enraizadas pode resultar em um arquivo de 0 bytes, e que esta opção deve ser usada. Não faz diferença, o processo ainda é concluído em questão de segundos e ainda recebo um arquivo de 0 byte.

O prompt da senha "Backup completo" (etapa 3):

Tenho certeza de que nunca defini uma senha de backup antes. Nunca tive a oportunidade de definir essa senha ou acessar essa configuração de qualquer forma antes. No entanto, tentei o seguinte:

  • Deixando as duas senhas em branco
  • Deixando a "senha de backup atual" em branco e inserindo uma nova senha na segunda caixa
  • Inserir o PIN de bloqueio de tela atual e todos os PINs que já usei no passado como "senha de backup atual".
  • Digitando todas as senhas que eu possa imaginar que eu já teria usado para qualquer coisa neste dispositivo

Em todos os casos, o comportamento é exatamente o mesmo descrito na etapa 5. Não recebo erros ou qualquer tipo de indicação de que algo esteja errado ou que minhas senhas sejam inválidas e nenhuma dica sobre se realmente está esperando uma senha atual ou se campo deve ser deixado em branco. (A captura de tela nesta resposta e em vários outros fóruns de suporte que eu analisei parece implicar que a caixa "senha de backup atual" não seria exibida se não houver senha atual, mas isso é apenas uma inferência; nada deixa claro se uma senha atual é realmente necessária.)

Suspeito que a senha solicitada possa ser a "Senha de backup da área de trabalho" definida nas opções do desenvolvedor:

insira a descrição da imagem aqui

Eu nunca defini essa senha antes. Se eu tentar definir um, recebo uma mensagem dizendoFailed to set backup password.

Ao procurar informações sobre esse erro, encontrei pelo menos outro caso em que alguém que estava com esse problema disse que isso o impedia de usar o backup do ADB, mas ele não era específico sobre o que acontece quando tenta usar o ADB cópia de segurança.

A maioria das pessoas que recebeu essa mensagem nunca definindo a senha antes diz que a solução foi deixar a senha atual em branco, mas tentei isso em primeiro lugar e não funcionou. Encontrei uma pergunta de outra pessoa que encontrou esse problema e tinha certeza de que não havia definido a senha antes . Infelizmente, parece que ele nunca conseguiu uma solução ou mesmo uma explicação.

Independentemente de o ADB estar procurando a "Senha de backup da área de trabalho" ou a senha de criptografia do ADB ser algo separado, me surpreende por que o ADB exigiria que você digite uma senha anterior para iniciar um novo backup. Não estou tentando restaurar, substituir ou de nenhuma forma acessar dados criptografados anteriormente, portanto, mesmo que uma senha de criptografia para um backup tenha sido definida anteriormente, não consigo imaginar por que alguém pensaria que seria uma boa idéia impedir você de fazendo backup do seu dispositivo se você não se lembra da senha usada para criptografar backups no passado.

Informação adicional:

Modelo: Samsung Galaxy S4 SCH-I545
Versão do kernel: 3.4.0
Versão do SO: 4.4.2 Versão do
Android SDK Tools: 1.16 A
depuração USB está ativada.

Observe que minha razão para usar o backup do ADB é fazer um backup completo do meu telefone para ficar seguro antes de fazer o root *, para que eu possa usar ferramentas de backup nandroid, como o backup do Titanium. Portanto, qualquer sugestão que envolva fazer o root do meu telefone seria um Catch-22, não uma solução. Desnecessário dizer que uma redefinição de fábrica também não é uma solução, uma vez que anularia todo o objetivo de executar o backup.

O telefone está configurado para sincronizar com os servidores Exchange da minha empresa, e há algumas políticas aplicadas pelo servidor. Eu pensava que o dispositivo estava criptografado quando configurei a sincronização com a conta da empresa, mas aparentemente ele não está criptografado no momento. De fato, foi isso que pôs em movimento essa cadeia de eventos: estou recebendo uma mensagem dizendo que preciso criptografar o dispositivo para continuar a conectar-me aos servidores da empresa. Quero fazer um backup nandroid antes da criptografia, o que exige o enraizamento, e quero usar o backup do ADB antes do enraizamento.


* Sim, estou ciente de que Towelroot é considerado seguro, mas prefiro não me arriscar e gostaria de resolver ou pelo menos entender esse problema caso ocorram problemas relacionados no futuro.


Eu tive vários problemas com o ADB em um dos meus tablets (enraizados ou não, em ambos os casos) que eram semelhantes (ao contrário: enquanto adb backupfuncionava bem, adb restoresempre falhava). Acabou que era um problema de permissão (o fabricante havia estragado a ROM) e, portanto, adb restorenão conseguiu ler o arquivo de backup depois de transferido para o dispositivo. Foi um pouco difícil de encontrar, e não tenho certeza se algo semelhante realmente é o caso aqui; mas pode valer a pena conferir.
Izzy

2
Para aqueles que acabariam aqui com o mesmo problema de 0 bytes: Eu tive esse problema porque uma vez eu configurei a senha da área de trabalho em Configurações e a esqueci. Como o dispositivo está enraizado, segui esta resposta (minha) e tudo correu bem.
Firelord

Você também pode consultar: code.google.com/p/android/issues/detail?id=47009 - Se você criptografou seu telefone, poderá usar sua senha de criptografia como a "senha atual" em todos os prompts: na tela "Backup completo" ou na "Senha de backup da área de trabalho".
Marco Leogrande

@AdiInbar você já resolveu isso?
Codecowboy

Na verdade, demorei um pouco para encontrar isso. Não sei se não estava usando as palavras corretas, mas era exatamente isso que eu precisava!
Thomas

Respostas:


31

Resposta curta

Tente usar uma versão anterior do adb. 1.0.32 não funcionou para mim, mas 1.0.31 funcionou.

Resposta longa

Acabei de encontrar esse problema em um Nexus 5 executando o CyanogenMod 11 (baseado no Android 4.4) usando a versão atual do Platform Tools e ADB (Android Debug Bridge versão 1.0.32 Revisão eac51f2bb6a8-android).

Usando adb logcatpara assistir os logs do dispositivo, notei que, depois de invocar, adb backup -apk -obb -shared -all -nosystemhavia algumas entradas suspeitas de log:

V/BackupManagerService(  811): Requesting full backup: apks=false obb=false shared=false all=false pkgs=[Ljava.lang.String;@4181ffc8
W/BackupManagerService(  811): Unknown package  '-apk' '-obb' '-shared' '-all' '-nosystem', skipping

Onde parece que o dispositivo está interpretando as opções da linha de comandos como argumentos não opcionais e produzindo um erro porque eles não são nomes de pacotes instalados. Isso me fez suspeitar que o protocolo adb ou as opções de chamada de comando / serviço foram alteradas no dispositivo em relação ao host, então tentei uma versão mais antiga do adb e voilà, funcionou.

Pesquisei um pouco e me deparei com uma alteração em Usar escape_arg no "adb backup" , que agora faz com que todos os argumentos sejam citados com uma única frase ao invocar /system/bin/bu backup. Isso explica o comportamento e os argumentos de aspas simples na mensagem de log. No entanto, não parece coincidir com o horário em que você encontrou o erro. Também sugeriria que a questão fosse muito mais difundida do que parece. Por isso, hesito em chamar isso de causa, mas pode ser um bom ponto de partida para uma investigação mais aprofundada.


2
O uso de uma versão anterior (1.0.31) resolveu meu problema. Esta pergunta stackoverflow.com/q/9555337/1741542 e especialmente esta resposta stackoverflow.com/a/23022718/1741542 me ajudaram a encontrar uma versão anterior, por exemplo, platform-tools_r20-linux.zip.
Olaf Dietsche

Parece que não funciona com todos os modelos. Embora eu tenha feito um backup completo de um Samsung S3 mini (Android 4.2) sem nenhum problema, não o fiz com um tablet, que está no Android 4.0. Eu tentei tudo, desde o adb-r10 até o adb-r23 (excluindo adb-r15) sem sucesso.
Olaf Dietsche

4
Eu tive um problema semelhante com o adb 1.0.32 e um Nexus 5 (Android 6). Eu resolvi isso citando explicitamente os argumentos de backup, ou seja, executando em adb backup '-noapk -noshared -all -nosystem'vez de adb backup -noapk -noshared -all -nosystem(dentro de um shell bash). Sem as aspas, recebo mensagens de logcat como esta: 'flag de backup desconhecido -all: -nosystem: -noapk', 'nenhum pacote de backup é fornecido e nem -shared nem -all dado' e, finalmente, 'Finalizado'.
maxschlepzig

Finalmente, também recebi um backup completo do Android 4.0. Me estúpido, foi apenas uma reinicialização do tablet, o que me levou a ir.
Olaf Dietsche

5
Obrigado! A propósito, você pode baixar o adb 1.0.31 para todas as plataformas aqui: ftp.mozilla.org/pub/labs/r2d2b2g
eWolf

16

Com base na resposta do kevenoid, isso pode depender de qual versão do adb está sendo executada no telefone.

Você pode descobrir qual versão o telefone está executando nativamente, fazendo o seguinte:

Primeiro descubra qual versão você está executando na sua área de trabalho

adb version

Em seguida, abra a concha no seu telefone

adb shell

Depois que o shell estiver aberto, você poderá executar

adb version

Em seguida, saia do shell executando

exit

Descobri que meu telefone estava executando a versão 1.0.31 e não 1.0.32 (é uma nota 2 da samsung)

Tentei usar aspas ou caracteres de escape como Hunter mostrou, mas nenhum deles funcionou na linha de comando do Windows. No entanto, o downgrade corrigiu o problema de incompatibilidade entre as duas versões.

Consegui encontrar a versão mais antiga seguindo as instruções aqui: https://stackoverflow.com/a/23022718/1741542

O link para download que usei foi:
http://dl-ssl.google.com/android/repository/platform-tools_r20-windows.zip

Outras plataformas:


Existe alguma maneira de atualizar a versão adb no telefone?
Bin Wang

10

As outras respostas sobre os argumentos de comando citados são precisas. Descobri que, se você escapar dos espaços entre os argumentos, funcionará.

Como isso: adb backup -apk\ -shared\ -all\ -system


Pode não ser a solução para o problema do OP, mas é uma solução melhor para o problema do @ Kevinoid do que usar um ADB mais antigo, que não funcionou para mim.
Hunter Perrin

Esta é uma duplicata da resposta de Kevinoid sem a justificativa. No entanto, funcionou bem para mim, e eu prefiro usar \ to '
Neil Mayhew

11
Esta solução funcionou para mim, não há necessidade de adb rebaixamento
livre-pensador

Posso confirmar a suspeita @HunterPerrin 's que este é um problema diferente porque eu tentei este primeiro e não resolver o meu problema, mas o segundo eu fui para 1.0.31 adb começou a copiar corretamente
Sirens

7

Nenhuma das soluções alternativas funcionou para mim aqui e não quero fazer o downgrade das minhas ferramentas do SDK. Aqui está o que eu vim com: pule adb backupno computador e vá direto para o dispositivo via adb shell.

$adb version
Android Debug Bridge version 1.0.35
Revision fc2a139a55f5-android

$ adb shell
shell@jflte:/ $ bu 1 backup -apk app.package.name > /sdcard/backup.ab
shell@jflte:/ $ exit

$adb pull /sdcard/backup.ab
[100%] /sdcard/backup.ab

Isso chama /system/bin/bue despeja o arquivo de backup no STDOUT (descritor de arquivo nº 1). Os parâmetros são os mesmos adb backup <params>-> bu 1 backup <params>. A saída é redirecionada para um arquivo no dispositivo e pode ser puxada como qualquer arquivo.

A única desvantagem é que você não pode fazer um backup completo se o dispositivo estiver com mais da metade da capacidade. Isso pode ser contornado se você tiver um slot SdCard externo. bupode escrever lá, mesmo no Android 4.4.2, porque é um aplicativo do sistema. /mnt/extSdCard/backup.abfuncionou o mesmo para mim como /sdcard.


4

suspiro Sinto muito se esse for o caso, e você parece ter cuidado ao julgar pelas capturas de tela e pelas linhas de comando, mas descobri para meu desgosto os mesmos sintomas e pensei em publicar apenas no caso de futuros descobridores chegarem aqui. Acontece que o adb é muito exigente quanto aos traços únicos x duplos em suas opções. Para mim, traços duplos reproduziam exatamente este caso: o mesmo prompt no telefone, o mesmo arquivo de 0 byte. Traços simples , embora existam nomes de argumentos longos, funcionaram como um encanto.

Caso isso aconteça, meu telefone é um Samsung Galazy Note 2 AT&T SGH-i317 com Android 5.1 / Cyanogenmod 12.1.


2
Estou meio confuso se isso deve ser publicado como resposta ou comentário. O OP mostra que ele está usando um traço, não um traço duplo, então sua resposta provavelmente errou o alvo. Admito que esta resposta é informativa (valor adicional), mas parece não responder à questão da OP.
Andrew T.

Isso resolveu meu problema.
John Freeman

Poste suas linhas de comando reais.
RoboJ1M 02/02

2

Você precisa executar o comando adb backup no adb versão 1.0.31.

Para windows eu fiz:

Registro:

$ adb backup -apk -obb -shared -all -system -f bckp.ab

O servidor adb está desatualizado. matando...

  • daemon iniciado com sucesso *

Agora desbloqueie seu dispositivo e confirme a operação de backup.

... então coloque tudo de volta ao normal.


1

OK, foi assim que consertei o meu.

Tentei a solução de Hunter Perrin:

adb backup -apk\ -shared\ -all\ -system

Mas ele voltou imediatamente, sem erros, sem tela de backup no telefone.

Por tentativa e erro, isso funcionou para mim:

adb backup -all\

1

Eu acho que tenho uma solução para aqueles que usam 1.0.32:

digite uma senha quando solicitado na tela do Android

Apesar de dizer que usará a senha padrão se você não digitar nenhuma, acredito que não e o adb 1.0.32 talvez não permita a criação de backups não criptografados.

Digitando uma senha que funcionou para mim, acabei usando o "Extrator de backup Android" (Warning Sourceforge) e a "Política de jurisdição de força ilimitada da Java Cryptography Extension (JCE)" para extraí-la em um arquivo tar.


1

Corri para o problema inverso: 1.0.31 com um telefone mais recente (Android 7) também falha. 1.0.31 usa: como separador ao passar argumentos para o telefone. Como adb logcat -s BackupManagerServicemostra o adb mais recente do telefone, também não é possível lidar com o estilo antigo: 02-19 01:59:44.330 1100 9830 W BackupManagerService: Unknown package com.gameloft.android.ANMP.GloftPOHM:-apk, skipping felizmente, o adb mais novo também aceita espaços como separador, portanto, incluir os argumentos entre aspas duplas funciona, por exemplo: adb.exe backup "com.gameloft.android.ANMP.GloftPOHM -apk" -f game-backup.ab

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.