Une restauration personnalisée fonctionnera-t-elle avec un appareil crypté ?

Oui, la récupération personnalisée fonctionne avec un appareil Honeycomb crypté. Le cryptage intégré ne touche pas la ROM et le firmware du tout. Il crypte juste les comptes, les paramètres, les applications téléchargées et leurs données, etc. qui peuvent se trouver dans la mémoire du téléphone, la carte SD interne ou externe. C'est pourquoi le cryptage n'est plus présent après une réinitialisation d'usine car il n'y a plus de données cryptées disponibles.

Les fichiers pour l'environnement de récupération personnalisé se trouvent sur la ROM en tant que firmware. C'est pourquoi ils survivent aux réinitialisations d'usine. Comme le flashage des fichiers/mises à jour a à voir avec la ROM, vous serez autorisé à le faire. Quand il s'agit de la sauvegarde Nandroid, vous pouvez le faire aussi, mais le morceau de données cryptées sera sauvegardé sous cette forme qui ne peut pas être restauré en utilisant Titanium Backup. Oui, vous pouvez restaurer Nandroid sans problème.

Sur mon Nexus S crypté, j'utilise un montage temporaire tmpfs sur /sdcard dans CWM. Il a assez de RAM pour garder la nouvelle ROM en mémoire pendant la mise à jour :

Téléchargez votre ROM dans /tmp/update.zip et démarrez en mode récupération. Puis connectez-vous 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)  

Ensuite, faites les étapes habituelles de mise à jour "installer le zip depuis la carte SD".

EDIT : A partir de ICS/Jelly Bean, il y a la nouvelle fonction adb sideload <filename-of-update.zip> método

Il fonctionne avec CWM à partir de la version 6.0.1.5 et vous avez besoin de l'Android SDK platform-tools v16 ou mieux. Si vous êtes dans CWM vous pouvez voir une nouvelle entrée installer zip depuis sideload si elle est prise en charge.

L'ancienne méthode fonctionne toujours :
Si sideload ne fonctionne pas, vous pouvez toujours utiliser la méthode tmpfs. CWM s'attend à ce que /data/media soit l'emplacement pour le fichier update.zip maintenant, le point de montage doit cependant être /data donc vous devez faire cela maintenant :

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

Raison :
À partir d'ICS+, la disposition des partitions proposée a changé. Il ne devrait plus y avoir de partition sdcard au format FAT mais le stockage externe réside désormais dans /data/ (/data/media). Pour rester compatible, un montage FUSE émule les anciennes propriétés FAT (droits d'accès et autres). Vous pouvez le voir lorsqu'il y a un montage FUSE sur /storage/sdcard0, il ressemble à ceci :

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