Akankah Pemulihan Kustom berfungsi dengan perangkat terenkripsi?

Saya ingin tahu apakah menggunakan enkripsi bawaan Android (diperkenalkan pada 3.0) akan memengaruhi kemampuan saya untuk menggunakan pemulihan khusus (Clockwork Mod dalam kasus saya).

Lebih khusus lagi jika saya masih dapat melakukan backup / restore Nandroid dan flash file baru dan pembaruan?

Jawaban ce4 tidak bekerja untuk saya di Galaxy Nexus GSM (Maguro) menggunakan CWM 6.0.1.1. Saya terus mendapatkan kesalahan dari CWM mengatakan kepada saya tidak bisa me-mount / sdcard bahkan setelah saya memasang tmpfs di sana dan menggunakan adb untuk mendorong pembaruan.zip di sana.

Setelah membaca utas di XDA saya menemukan bahwa tidak seperti CWM, TWRP mampu memasang partisi sdcard terenkripsi. Jadi saya mengunduh TWRP untuk GNex dan menginstalnya menggunakan fastboot. Ketika saya boot ke pemulihan, ia meminta saya untuk kata sandi partisi sdcard terenkripsi dan saya dapat mem-flash pembaruan secara normal.

Tautan:
TWRP
XDA Thread

Ya, pemulihan khusus berfungsi dengan perangkat honeycomb terenkripsi. Enkripsi bawaan tidak menyentuh ROM & firmware sama sekali. Itu hanya mengenkripsi akun, pengaturan, aplikasi yang diunduh & data mereka dll. Yang dapat ditemukan di memori ponsel, SD internal atau SD eksternal. Itu sebabnya enkripsi tidak lagi ada setelah reset pabrik karena tidak ada data terenkripsi yang tersedia.

File untuk lingkungan pemulihan tersuai langsung di ROM sebagai firmware. Itu sebabnya mereka selamat dari reset pabrik. Karena Flashing file / pembaruan berkaitan dengan ROM, Anda akan diizinkan untuk melakukannya. Ketika datang ke cadangan Nandroid, Anda dapat melakukannya juga, tetapi potongan data yang dienkripsi akan dicadangkan dalam bentuk yang tidak dapat dipulihkan menggunakan Titanium Backup. Ya, Anda bisa melakukan pengembalian Nandroid dengan sempurna.

Pada Nexus SI terenkripsi saya menggunakan tmpfs sementara mount / sdcard di CWM. Ini memiliki RAM yang cukup untuk menyimpan ROM baru dalam memori selama pembaruan:

Unduh ROM Anda ke /tmp/update.zip dan boot ke pemulihan. Kemudian masuk melalui '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)  

Kemudian lakukan langkah-langkah pembaruan biasa 'instal zip dari sdcard'.

EDIT: Dimulai dengan ICS / Jelly Bean ada adb sideload <filename-of-update.zip>metode baru

Ini bekerja dengan CWM dari versi 6.0.1.5 dan seterusnya dan Anda memerlukan Android SDK platform-tools v16 atau lebih baik. Jika Anda berada di CWM, Anda dapat melihat entri baru menginstal zip dari sideload jika didukung.

Metode lama masih berfungsi:
Jika sideload tidak berfungsi, Anda masih dapat menggunakan metode tmpfs. CWM mengharapkan / data / media sebagai lokasi untuk pembaruan.zip sekarang, mountpoint telah menjadi / data sehingga Anda harus melakukan ini sekarang:

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

Alasan:
Dimulai dengan ICS + tata letak partisi yang diusulkan telah berubah. Seharusnya tidak ada partisi sdcard yang diformat FAT lagi tetapi penyimpanan eksternal sekarang berada di / data / (/ data / media). Agar tetap kompatibel, mount FUSE mengemulasi properti FAT lama (hak akses dan semacamnya). Anda dapat melihat ini ketika ada mount sekering di / storage / sdcard0, tampilannya mirip dengan ini:

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