Apakah Google menggunakan A/B OTA di perangkat?
Ya. Nama marketing untuk update A/B adalah update lancar. Ponsel Pixel dan Pixel XL
sejak Oktober 2016 dilengkapi dengan A/B, dan semua Chromebook menggunakan implementasi A/B yang sama
update_engine. Implementasi kode platform yang diperlukan bersifat publik di Android 7.1 dan
yang lebih tinggi.
Mengapa A/B OTA lebih baik?
A/B OTA memberikan pengalaman pengguna yang lebih baik saat menerima update. Pengukuran dari update keamanan bulanan menunjukkan bahwa fitur ini telah terbukti berhasil: Pada Mei 2017, 95% pemilik Pixel menjalankan update keamanan terbaru setelah satu bulan dibandingkan dengan 87% pengguna Nexus, dan pengguna Pixel melakukan update lebih cepat daripada pengguna Nexus. Kegagalan untuk memblokir update selama OTA tidak lagi menyebabkan perangkat tidak dapat di-boot; hingga image sistem baru berhasil di-boot, Android mempertahankan kemampuan untuk kembali ke image sistem kerja sebelumnya.
Apa yang dimaksud dengan system_other?
Aplikasi disimpan dalam file .apk, yang sebenarnya adalah arsip ZIP. Setiap file .apk memiliki di dalamnya satu atau beberapa file .dex yang berisi bytecode Dalvik portabel. File .odex (.dex yang dioptimalkan ) berada terpisah dari file .apk dan dapat berisi kode mesin yang khusus untuk perangkat. Jika file .odex tersedia, Android dapat menjalankan aplikasi dengan kecepatan kompilasi ahead-of-time tanpa harus menunggu kode dikompilasi setiap kali aplikasi diluncurkan. File .odex tidak benar-benar diperlukan: Android sebenarnya dapat menjalankan kode .dex secara langsung melalui interpretasi atau kompilasi Just-In-Time (JIT), tetapi file .odex memberikan kombinasi terbaik antara kecepatan peluncuran dan kecepatan runtime jika ruang tersedia.
Contoh: Untuk installed-files.txt dari Nexus 6P yang menjalankan Android 7.1 dengan ukuran image sistem total 2628MiB (2755792836 byte), perincian kontributor terbesar untuk ukuran image sistem keseluruhan berdasarkan jenis file adalah sebagai berikut:
| .odex | 1391770312 byte | 50,5% |
| .apk | 846878259 byte | 30,7% |
| .so (kode C/C++ native) | 202162479 byte | 7,3% |
| file .oat/.image art | 163892188 byte | 5,9% |
| Font | 38952361 byte | 1,4% |
| data lokalitas icu | 27468687 byte | 0,9% |
Angka-angka ini juga serupa untuk perangkat lain, sehingga di perangkat Nexus/Pixel, file .odex menggunakan
sekitar setengah partisi sistem. Artinya, kita dapat terus menggunakan ext4, tetapi menulis
file .odex ke partisi B di pabrik, lalu menyalinnya ke /data saat
booting pertama. Penyimpanan sebenarnya yang digunakan dengan ext4 A/B identik dengan SquashFS A/B, karena jika kita
menggunakan SquashFS, kita akan mengirimkan file .odex yang telah dioptimalkan di system_a, bukan
system_b.
Apakah menyalin file .odex ke /data berarti ruang yang disimpan di /system akan hilang di /data?
Kurang tepat. Di Pixel, sebagian besar ruang yang digunakan oleh file .odex adalah untuk aplikasi, yang biasanya
ada di /data. Aplikasi ini menerima update Google Play, sehingga file .apk dan .odex
di image sistem tidak digunakan selama sebagian besar masa pakai perangkat. File tersebut dapat dikecualikan
sepenuhnya dan diganti dengan file .odex kecil yang didorong oleh profil saat pengguna benar-benar menggunakan setiap
aplikasi (sehingga tidak memerlukan ruang untuk aplikasi yang tidak digunakan pengguna). Untuk mengetahui detailnya, lihat Google
I/O 2016 talk The Evolution of Art.
Perbandingan ini sulit dilakukan karena beberapa alasan utama:
-
Aplikasi yang diupdate oleh Google Play selalu memiliki file .odex di
/datasegera setelah menerima update pertamanya. - Aplikasi yang tidak dijalankan pengguna tidak memerlukan file .odex sama sekali.
- Kompilasi yang didorong oleh profil menghasilkan file .odex yang lebih kecil daripada kompilasi ahead-of-time (karena kompilasi yang didorong oleh profil hanya mengoptimalkan kode yang penting untuk performa).
Untuk mengetahui detail opsi penyesuaian yang tersedia bagi OEM, lihat Mengonfigurasi ART.
Apakah ada dua salinan file .odex di /data?
Sedikit lebih rumit ... Setelah image sistem baru ditulis, versi baru
dex2oat dijalankan terhadap file .dex baru untuk menghasilkan file .odex baru. Hal ini
terjadi saat sistem lama masih berjalan, sehingga file .odex lama dan baru berada di
/data pada waktu yang sama.
Kode di OtaDexoptService (frameworks/base/+/android17-release/services/core/java/com/android/server/pm/OtaDexoptService.java) memanggil getAvailableSpace sebelum mengoptimalkan setiap paket untuk menghindari pengisian berlebihan
/data. Perhatikan bahwa tersedia di sini masih konservatif: jumlah ruang yang tersisa sebelum mencapai batas ruang rendah sistem yang biasa (diukur sebagai persentase dan jumlah byte). Jadi, jika /data penuh, tidak akan ada dua salinan setiap file .odex. Kode yang sama juga memiliki BULK_DELETE_THRESHOLD: Jika perangkat hampir mengisi ruang yang tersedia (seperti yang dijelaskan di atas), file .odex milik aplikasi yang tidak digunakan akan dihapus. Itu adalah kasus lain tanpa dua salinan setiap file .odex.
Dalam kasus terburuk saat /data benar-benar penuh, update akan menunggu hingga perangkat di-reboot ke sistem baru dan tidak lagi memerlukan file .odex sistem lama. PackageManager menangani hal ini: (frameworks/base/+/android17-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215). Setelah sistem baru berhasil di-boot, installd (frameworks/native/+/android17-release/cmds/installd/dexopt.cpp#2422) dapat menghapus file .odex yang digunakan oleh sistem lama, sehingga perangkat kembali ke status stabil dengan hanya satu salinan.
Jadi, meskipun /data mungkin berisi dua salinan semua file .odex, (a) hal ini bersifat sementara dan (b) hanya terjadi jika Anda memiliki banyak ruang kosong di /data anyway. Kecuali selama update, hanya ada satu salinan. Selain itu, sebagai bagian dari
fitur ketahanan umum ART, fitur ini tidak akan mengisi /data dengan file .odex (karena hal tersebut juga akan menjadi masalah pada sistem non-A/B).
Apakah semua penulisan/penyalinan ini meningkatkan keausan flash?
Hanya sebagian kecil flash yang ditulis ulang: update sistem Pixel penuh menulis sekitar 2,3 GiB. (Aplikasi juga dikompilasi ulang, tetapi hal ini juga berlaku untuk non-A/B.) Secara tradisional, OTA penuh berbasis blok menulis jumlah data yang serupa, sehingga tingkat keausan flash akan serupa.
Apakah mem-flash dua partisi sistem meningkatkan waktu flash pabrik?
Tidak. Ukuran image sistem Pixel tidak bertambah (hanya membagi ruang di dua partisi).
Apakah menyimpan file .odex di B membuat reboot setelah reset ke setelan pabrik menjadi lambat?
Ya. Jika Anda benar-benar menggunakan perangkat, menerima OTA, dan melakukan reset ke setelan pabrik, reboot pertama akan lebih lambat daripada biasanya (1 menit 40 detik vs 40 detik di Pixel XL) karena file .odex akan hilang dari B setelah OTA pertama dan tidak dapat disalin ke /data. Itulah konsekuensinya.
Reset ke setelan pabrik seharusnya merupakan operasi yang jarang dilakukan jika dibandingkan dengan booting reguler, sehingga waktu yang diperlukan
menjadi kurang penting. (Hal ini tidak memengaruhi pengguna atau pengulas yang mendapatkan perangkat dari
pabrik, karena dalam hal ini partisi B tersedia.) Penggunaan kompilator JIT berarti kita
tidak perlu mengompilasi ulang semuanya, sehingga tidak seburuk yang Anda kira. Anda juga dapat menandai aplikasi sebagai aplikasi yang memerlukan kompilasi ahead-of-time menggunakan
coreApp="true" dalam manifes: (frameworks/base/+/android17-release/packages/SystemUI/AndroidManifest.xml#23). Hal ini saat ini digunakan oleh system_server karena tidak diizinkan untuk JIT karena
alasan keamanan.
Apakah menyimpan file .odex di /data, bukan /system, membuat reboot setelah OTA menjadi lambat?
Tidak. Seperti yang dijelaskan di atas, dex2oat baru dijalankan saat image sistem lama masih berjalan untuk menghasilkan file yang akan diperlukan oleh sistem baru. Update tidak dianggap tersedia hingga pekerjaan tersebut selesai.
Dapatkah (seharusnya) kita mengirimkan perangkat A/B 32 GiB? 16GiB? 8GiB?
32 GiB berfungsi dengan baik seperti yang terbukti di Pixel, dan 320 MiB dari 16 GiB berarti pengurangan sebesar 2%. Demikian pula, 320 MiB dari 8 GiB berarti pengurangan sebesar 4%. Jelas, A/B tidak akan menjadi pilihan yang direkomendasikan di perangkat dengan 4 GiB, karena overhead 320 MiB hampir 10% dari total ruang yang tersedia.
Apakah AVB2.0 memerlukan A/B OTA?
Tidak. Android Booting Terverifikasi selalu memerlukan update berbasis blok, tetapi tidak harus update A/B.
Apakah A/B OTA memerlukan AVB2.0?
Tidak.
Apakah A/B OTA merusak perlindungan rollback AVB2.0?
Tidak. Ada sedikit kebingungan di sini karena jika sistem A/B gagal di-boot ke image sistem baru sistem akan otomatis kembali ke image sistem "sebelumnya" (setelah beberapa kali percobaan ulang yang ditentukan oleh bootloader Anda). Namun, poin utamanya di sini adalah bahwa "sebelumnya" dalam pengertian A/B sebenarnya masih merupakan image sistem "saat ini". Segera setelah perangkat berhasil mem-boot a image baru, perlindungan rollback akan diaktifkan dan memastikan bahwa Anda tidak dapat kembali. Namun, hingga Anda berhasil mem-boot image baru, perlindungan rollback tidak menganggapnya sebagai image sistem saat ini.
Jika Anda menginstal update saat sistem berjalan, bukankah itu lambat?
Dengan update non-A/B, tujuannya adalah menginstal update secepat mungkin karena pengguna menunggu dan tidak dapat menggunakan perangkatnya saat update diterapkan. Dengan update A/B, hal yang sebaliknya berlaku; karena pengguna masih menggunakan perangkatnya, tujuannya adalah meminimalkan dampak, sehingga update sengaja dibuat lambat. Melalui logika di klien update sistem Java (yang untuk Google adalah GmsCore, paket inti yang disediakan oleh GMS), Android juga mencoba memilih waktu saat pengguna tidak menggunakan perangkatnya sama sekali. Platform ini mendukung update yang dapat dijeda/dilanjutkan, dan klien dapat menggunakannya untuk menjeda update jika pengguna mulai menggunakan perangkat dan melanjutkannya saat perangkat tidak digunakan lagi.
Ada dua fase saat menerima OTA, yang ditampilkan dengan jelas di UI sebagai Langkah 1 dari 2 dan Langkah 2 dari 2 di bawah progres bar. Langkah 1 sesuai dengan penulisan blok data, sedangkan langkah 2 adalah kompilasi awal file .dex. Kedua fase ini cukup berbeda dalam hal dampak performa. Fase pertama adalah I/O sederhana. Hal ini memerlukan sedikit resource (RAM, CPU, I/O) karena hanya menyalin blok secara perlahan.
Fase kedua menjalankan dex2oat untuk mengompilasi awal image sistem baru. Hal ini jelas memiliki batas yang kurang jelas pada persyaratannya karena mengompilasi aplikasi sebenarnya. Selain itu, jelas ada lebih banyak pekerjaan yang terlibat dalam mengompilasi aplikasi besar dan kompleks daripada aplikasi kecil dan sederhana; sedangkan pada fase 1, tidak ada blok disk yang lebih besar atau lebih kompleks daripada yang lain.
Proses ini mirip dengan saat Google Play menginstal update aplikasi di latar belakang sebelum menampilkan notifikasi 5 aplikasi diupdate, seperti yang telah dilakukan selama bertahun-tahun.
Bagaimana jika pengguna benar-benar menunggu update?
Implementasi saat ini di GmsCore tidak membedakan antara update latar belakang dan update yang dimulai pengguna, tetapi mungkin akan melakukannya di masa mendatang. Jika pengguna secara eksplisit meminta update diinstal atau menonton layar progres update, kami akan memprioritaskan pekerjaan update dengan asumsi bahwa mereka secara aktif menunggu update selesai.
Apa yang terjadi jika update gagal diterapkan?
Dengan update non-A/B, jika update gagal diterapkan, pengguna biasanya akan memiliki perangkat yang tidak dapat digunakan. Satu-satunya pengecualian adalah jika kegagalan terjadi sebelum aplikasi dimulai (karena paket gagal diverifikasi, misalnya). Dengan update A/B, kegagalan untuk menerapkan update tidak memengaruhi sistem yang sedang berjalan. Update dapat dicoba lagi nanti.