Чи працюватиме спеціальне відновлення із зашифрованим пристроєм?

Мені хотілося знати, чи вплине використання вбудованого шифрування Android (представленого в 3.0) на мою здатність використовувати користувальницьке відновлення (Clockwork Mod у моєму випадку).

Більш конкретно, чи зможу я виконувати резервні копії / відновлення Nandroid та прошивати нові файли та оновлення?

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

Прочитавши потік у XDA, я з’ясував, що на відміну від CWM, TWRP здатний монтувати зашифрований розділ sdcard. Тому я завантажив TWRP для GNex і прошив його за допомогою fastboot. Коли я завантажився до відновлення, він попросив мене для пароля зашифрованого розділу sdcard, і я зміг нормально прошивати оновлення.

Посилання:
TWRP
XDA Thread

Так, спеціальне відновлення працює із зашифрованим пристроєм соти. Вбудоване шифрування зовсім не торкається ПЗУ та мікропрограмного забезпечення. Він просто шифрує акаунти, налаштування, завантажені програми та їх дані тощо, які можуть бути розміщені на пам'яті телефону, внутрішній або зовнішній SD. Ось чому шифрування більше не існує після скидання заводських налаштувань, оскільки немає зашифрованих даних.

Файли для користувальницького середовища відновлення живуть на ROM як програмне забезпечення. Тому вони переживають скидання заводу. Оскільки миготливі файли / оновлення пов'язані з ROM, вам це дозволять. Що стосується резервної копії Nandroid, ви можете це робити, але фрагмент зашифрованих даних буде створено в резервній формі в тій формі, яку неможливо відновити за допомогою резервного копіювання Titanium. Так, ви могли б зробити відновлення Nandroid бездоганно.

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

Завантажте свій ROM на /tmp/update.zip та завантажте його на відновлення. Потім увійдіть через '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)  

Потім виконайте звичайні кроки оновлення "встановити zip з sdcard".

EDIT: Починаючи з ICS / Jelly Bean є новий adb sideload <filename-of-update.zip>метод

Він працює з CWM від версії 6.0.1.5 і вам потрібні платформи Android SDK v16 або новіші. Якщо ви знаходитесь у CWM, ви можете побачити новий запис для встановлення zip з бічного завантаження, якщо він підтримується.

Старий метод все ще працює:
якщо бічне завантаження не працює, ви все одно можете використовувати метод tmpfs. CWM очікує / дані / медіа як місце для update.zip зараз, але монтовою точкою повинні бути / дані, тому ви повинні зробити це зараз:

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 + запропонований макет розділу змінився. Більше не має бути формату SDC, відформатованого FAT, але зовнішнє сховище тепер знаходиться в / data / (/ data / media). Щоб залишатися сумісним, кріплення FUSE імітує старі властивості FAT (права доступу та інші). Це ви можете побачити, коли на / зберігання / sdcard0 є кріплення запобіжника, це схоже на це:

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