¿Funcionará una recuperación personalizada con un dispositivo encriptado?

Quería saber si el uso del cifrado integrado de Android (introducido en 3.0) afectaría mi capacidad de usar una recuperación personalizada (Clockwork Mod en mi caso).

Más específicamente si aún podré realizar copias de seguridad / restauraciones de Nandroid y actualizar nuevos archivos y actualizaciones.

La respuesta de ce4 no funcionó para mí en mi Galaxy Nexus GSM (Maguro) usando CWM 6.0.1.1. Seguí recibiendo errores de CWM diciéndome que no podía montar / sdcard incluso después de que monté un tmpfs allí y usé adb para empujar el update.zip allí.

Después de leer un hilo en XDA descubrí que, a diferencia de CWM, TWRP es capaz de montar una partición sdcard encriptada. Así que descargué TWRP para GNex y lo actualicé usando fastboot. Cuando inicié la recuperación, me pidió la contraseña para la partición sdcard encriptada y pude actualizar la actualización normalmente.

Enlaces: Hilo
TWRP
XDA

Sí, la recuperación personalizada funciona con un dispositivo de panal cifrado. El cifrado incorporado no toca ROM y firmware en absoluto. Simplemente encripta cuentas, configuraciones, aplicaciones descargadas y sus datos, etc.que se pueden ubicar en la memoria del teléfono, SD interna o SD externa. Es por eso que el cifrado ya no está presente después del restablecimiento de fábrica porque no hay datos cifrados disponibles.

Los archivos para el entorno de recuperación personalizado viven en ROM como firmware. Por eso sobreviven al restablecimiento de fábrica. Como los archivos / actualizaciones intermitentes tienen que ver con la ROM, se le permitirá hacerlo. Cuando se trata de la copia de seguridad de Nandroid, también puede hacerlo, pero la porción de datos cifrados se copiará en esa forma que no se puede restaurar con Titanium Backup. Sí, podrías restaurar Nandroid sin problemas.

En mi Nexus SI encriptado, use un montaje temporal tmpfs en / sdcard en CWM. Tiene suficiente RAM para mantener la nueva ROM en la memoria durante la actualización:

Descargue su ROM a /tmp/update.zip y arranque en recovery. Luego inicie sesión a través de '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)  

Luego realice los pasos habituales de actualización 'instalar zip desde sdcard'.

EDITAR: a partir de ICS / Jelly Bean, existe el nuevo adb sideload <filename-of-update.zip>método

Funciona con CWM desde la versión 6.0.1.5 en adelante y necesita las herramientas de plataforma Android SDK v16 o superior. Si está en CWM, puede ver una nueva entrada, instalar zip desde la carga lateral si es compatible.

El método anterior todavía funciona:
si la carga lateral no funciona, aún puede usar el método tmpfs. CWM espera / data / media como la ubicación para el archivo update.zip ahora, sin embargo, el punto de montaje debe ser / data, por lo que debe hacer esto ahora:

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

Motivo: a
partir de ICS +, el diseño de partición propuesto ha cambiado. Ya no debería haber una partición sdcard con formato FAT, pero el almacenamiento externo ahora reside en / data / (/ data / media). Para seguir siendo compatible, un montaje FUSE emula las antiguas propiedades FAT (derechos de acceso y demás). Puede ver esto cuando hay un montaje de fusible en / storage / sdcard0, se parece a esto:

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