Будет ли Custom Recovery работать с зашифрованным устройством?

Ответ ce4 не работал у меня на моем Galaxy Nexus GSM (Maguro) с использованием CWM 6.0.1.1. Я продолжал получать сообщения об ошибках от CWM, говорящих мне, что он не может смонтировать /sdcard даже после того, как я смонтировал там tmpfs и использовал adb для отправки туда update.zip.

Прочитав ветку на XDA, я узнал, что, в отличие от CWM, TWRP может монтировать зашифрованный раздел SD-карты. Поэтому я скачал TWRP для GNex и прошил его с помощью fastboot. Когда я загрузился для восстановления, он попросил меня ввести пароль для зашифрованного раздела SD-карты, и я смог нормально установить обновление.

Ссылки: Тема
TWRP
XDA

Да, пользовательское восстановление работает с зашифрованным сотовым устройством. Встроенное шифрование вообще не затрагивает ПЗУ и прошивку. Он просто шифрует учетные записи, настройки, загруженные приложения, их данные и т. д., которые могут находиться в памяти телефона, на внутренней SD или внешней SD. Вот почему шифрование больше не присутствует после сброса настроек, потому что зашифрованные данные недоступны.

Файлы пользовательской среды восстановления живут в ПЗУ как прошивка. Вот почему они выживают при сбросе к заводским настройкам. Поскольку перепрошивка файлов/обновлений связана с ПЗУ, вам будет разрешено это сделать. Когда дело доходит до резервного копирования Nandroid, вы тоже можете это сделать, но часть зашифрованных данных будет сохранена в той форме, которую нельзя восстановить с помощью Titanium Backup. Да, вы можете безупречно восстановить Nandroid.

На моем зашифрованном Nexus SI используйте временное монтирование tmpfs на /sdcard в CWM. У него достаточно оперативной памяти для хранения нового ПЗУ в памяти во время обновления:

Загрузите ПЗУ в /tmp/update.zip и загрузитесь в рекавери. Затем войдите в систему через «оболочку adb»:

## 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)  

Затем выполните обычные шаги обновления «установить zip с SD-карты».

РЕДАКТИРОВАТЬ: Начиная с ICS/Jelly Bean, есть новый adb sideload <filename-of-update.zip>метод

Он работает с CWM, начиная с версии 6.0.1.5, и вам потребуются инструменты платформы Android SDK v16 или выше. Если вы используете CWM, вы можете увидеть новую запись install zip из боковой загрузки , если она поддерживается.

Старый метод все еще работает:
если боковая загрузка не работает, вы все равно можете использовать метод tmpfs. CWM теперь ожидает /data/media в качестве местоположения для update.zip, однако точка монтирования должна быть /data, поэтому вы должны сделать это сейчас:

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

Причина:
Начиная с ICS+, предлагаемая структура разделов изменилась. Раздела SD-карты, отформатированного в FAT, больше не должно быть, но внешнее хранилище теперь находится в /data/ (/data/media). Чтобы сохранить совместимость, монтирование FUSE эмулирует старые свойства FAT (права доступа и т. д.). Вы можете увидеть это, когда на /storage/sdcard0 есть крепление предохранителя, это выглядит примерно так:

оболочка@android:/ $ монтировать | grep fuse
[...]
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,... 0 0
[...]