Uma recuperação personalizada funcionará com um dispositivo criptografado?

Eu queria saber se o uso da criptografia interna do Android (introduzida na 3.0) afetaria minha capacidade de usar uma recuperação personalizada (Clockwork Mod no meu caso).

Mais especificamente, se eu ainda for capaz de executar backups / restaurações Nandroid e atualizar novos arquivos e atualizações?

A resposta da ce4 não funcionou para mim no meu Galaxy Nexus GSM (Maguro) usando o CWM 6.0.1.1. Eu continuava recebendo erros do CWM dizendo que não era possível montar / sdcard mesmo depois de montar um tmpfs lá e usar o adb para enviar o update.zip para lá.

Depois de ler um thread no XDA, descobri que, diferentemente do CWM, o TWRP é capaz de montar uma partição sdcard criptografada. Então eu baixei o TWRP para o GNex e o atualizei usando o fastboot. Quando iniciei a recuperação, ele solicitou a senha da partição sdcard criptografada e pude atualizar a atualização normalmente.

Links: Tópico
TWRP
XDA

Sim, a recuperação personalizada funciona com um dispositivo de favo de mel criptografado. A criptografia embutida não toca na ROM e no firmware. Ele apenas criptografa contas, configurações, aplicativos baixados e seus dados, etc., que podem ser localizados na memória do telefone, no SD interno ou no externo. É por isso que a criptografia não está mais presente após a redefinição de fábrica, porque não há dados criptografados disponíveis.

Os arquivos para o ambiente de recuperação personalizado ficam na ROM como firmware. É por isso que eles sobrevivem à redefinição de fábrica. Como os arquivos / atualizações intermitentes estão relacionados à ROM, você poderá fazê-lo. Quando se trata de backup Nandroid, você também pode fazê-lo, mas a parte dos dados criptografados será copiada nesse formato que não pode ser restaurada usando o Titanium Backup. Sim, você pode fazer o Nandroid restaurar perfeitamente.

No meu Nexus SI criptografado, use uma montagem tmpfs temporária no / sdcard no CWM. Possui RAM suficiente para armazenar a nova ROM na memória durante a atualização:

Faça o download da sua ROM para /tmp/update.zip e inicie a recuperação. Em seguida, efetue login via 'adb shell':

## on the host machine do:
me@workstation:/tmp$ adb shell
## now on the device in 'adb shell' mode...  
~ # mount -t tmpfs none /sdcard/  
## the following command is not needed, it only shows the newly created mount point
~ # df -h
Filesystem                Size      Used Available Use% Mounted on  
[...]  
none                    172.4M         0    172.4M   0% /sdcard  
~ # exit  
## now back on the host machine again
me@workstation:/tmp$ adb push update.zip /sdcard/  
5567 KB/s (131676307 bytes in 23.097s)  

Em seguida, execute as etapas de atualização habituais 'install zip from sdcard'.

EDIT: Começando com ICS / Jelly Bean, existe o novo adb sideload <filename-of-update.zip>método

Ele funciona com o CWM da versão 6.0.1.5 em diante e você precisa das ferramentas da plataforma SDK do Android v16 ou superior. Se você estiver no CWM, poderá ver uma nova entrada, instalar zip do sideload, se for suportada.

O método antigo ainda funciona:
se o sideload não funcionar, você ainda poderá usar o método tmpfs. O CWM espera / data / media como o local para o update.zip agora, no entanto, o ponto de montagem deve ser / data, então você deve fazer isso agora:

me@workstation$ adb shell
~ # mount -t tmpfs none /data
~ # mkdir /data/media
## Go on with 'adb push update.zip /data/media' and then like above

Razão:
A partir do ICS +, o layout da partição proposto foi alterado. Não deve haver mais partição sdcard formatada em FAT, mas o armazenamento externo agora reside em / data / (/ data / media). Para permanecer compatível, uma montagem do FUSE emula as propriedades antigas do FAT (direitos de acesso e outras). Você pode ver isso quando há uma montagem de fusível em / storage / sdcard0, é semelhante a este:

shell @ android: / $ mount | grep fusível
[...]
/ dev / fusível / storage / sdcard0 fusível rw, nosuid, nodev, relatime, user_id = 1023, group_id = 1023, ... 0 0
[...]