Apakah Google telah menggunakan OTA A/B di perangkat apa pun?
Ya. Nama pemasaran untuk update A/B adalah update lancar. Ponsel Pixel dan Pixel XL
dari Oktober 2016 dikirimkan 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 OTA A/B lebih baik?
OTA A/B memberikan pengalaman pengguna yang lebih baik saat melakukan 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 mengupdate lebih cepat daripada pengguna Nexus. Kegagalan untuk mengupdate blok 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 sebelumnya yang berfungsi.
Apa itu system_other?
Aplikasi disimpan dalam file .apk, yang sebenarnya merupakan 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 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 kecepatan peluncuran dan kecepatan runtime terbaik jika ruang tersedia.
Contoh: Untuk installed-files.txt dari Nexus 6P yang menjalankan Android 7.1 dengan total ukuran image sistem 2628 MiB (2755792836 byte), perincian kontributor terbesar terhadap keseluruhan ukuran image sistem menurut 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 ini juga serupa untuk perangkat lain, jadi 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
boot pertama. Penyimpanan aktual yang digunakan dengan A/B ext4 identik dengan A/B SquashFS, karena jika kita
menggunakan SquashFS, kita akan mengirimkan file .odex yang telah dioptimalkan di system_a, bukan
system_b.
Bukankah menyalin file .odex ke /data berarti ruang yang disimpan di /system 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 masa pakai perangkat. File tersebut dapat sepenuhnya dikecualikan 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 presentasi Google I/O 2016 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 profil menghasilkan file .odex yang lebih kecil daripada kompilasi ahead-of-time (karena yang pertama hanya mengoptimalkan kode yang penting untuk performa).
Untuk mengetahui detail tentang opsi penyetelan yang tersedia bagi OEM, lihat Mengonfigurasi ART.
Bukankah ada dua salinan file .odex di /data?
Prosesnya sedikit lebih rumit ... Setelah image sistem baru ditulis, versi dex2oat baru 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 secara bersamaan.
Kode di OtaDexoptService (frameworks/base/+/android16-release/services/core/java/com/android/server/pm/OtaDexoptService.java) memanggil getAvailableSpace sebelum mengoptimalkan setiap paket untuk menghindari pengisian berlebih
/data. Perhatikan bahwa tersedia di sini masih konservatif: ini adalah 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 memenuhi 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 sudah penuh, update akan menunggu hingga
perangkat dimulai ulang ke sistem baru dan tidak lagi memerlukan file .odex sistem lama. PackageManager menangani hal ini: (frameworks/base/+/android16-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215). Setelah sistem baru berhasil di-boot, installd (frameworks/native/+/android16-release/cmds/installd/dexopt.cpp#2422) dapat menghapus file .odex yang digunakan oleh sistem lama, sehingga perangkat kembali ke
status stabil yang hanya memiliki 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. Kecuali selama update, hanya ada satu salinan. Sebagai bagian dari
fitur keandalan umum ART, ART tidak akan pernah mengisi /data dengan file .odex (karena hal itu 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 itu juga berlaku untuk non-A/B.) Biasanya, OTA penuh berbasis blok menulis data dalam jumlah yang serupa, sehingga tingkat keausan flash akan serupa.
Apakah mem-flash dua partisi sistem akan meningkatkan waktu flashing pabrik?
Tidak. Pixel tidak bertambah dalam ukuran image sistem (hanya membagi ruang di dua partisi).
Apakah menyimpan file .odex di B membuat booting ulang setelah reset ke setelan pabrik menjadi lambat?
Ya. Jika Anda benar-benar telah menggunakan perangkat, melakukan OTA, dan melakukan reset data ke setelan pabrik, reboot pertama akan lebih lambat daripada biasanya (1m40d vs 40d di Pixel XL) karena file .odex akan hilang dari B setelah OTA pertama dan tidak dapat disalin ke /data. Itulah komprominya.
Reset data pabrik harus menjadi operasi yang jarang dilakukan dibandingkan dengan booting reguler, sehingga waktu yang diperlukan tidak terlalu penting. (Hal ini tidak memengaruhi pengguna atau pengulas yang mendapatkan perangkat mereka dari
pabrik, karena dalam hal ini partisi B tersedia.) Penggunaan compiler JIT berarti kita
tidak perlu mengompilasi ulang semuanya, jadi tidak seburuk yang Anda kira. Anda juga dapat menandai aplikasi sebagai memerlukan kompilasi sebelum waktu menggunakan coreApp="true" dalam manifes: (frameworks/base/+/android16-release/packages/SystemUI/AndroidManifest.xml#23). Saat ini, hal ini digunakan oleh system_server karena tidak diizinkan untuk JIT karena alasan keamanan.
Apakah menyimpan file .odex di /data, bukan di /system, membuat booting ulang setelah OTA menjadi lambat?
Tidak. Seperti yang dijelaskan di atas, dex2oat baru dijalankan saat image sistem lama masih berjalan untuk membuat file yang akan diperlukan oleh sistem baru. Update tidak dianggap tersedia hingga pekerjaan tersebut selesai.
Dapatkah (haruskah) kita mengirimkan perangkat A/B 32 GiB? 16GiB? 8GiB?
32 GiB berfungsi dengan baik karena telah terbukti di Pixel, dan 320 MiB dari 16 GiB berarti pengurangan sebesar 2%. Demikian pula, 320 MiB dari 8 GiB adalah 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 OTA A/B?
Tidak. Booting Terverifikasi Android selalu memerlukan update berbasis blok, tetapi tidak harus update A/B.
Apakah A/B OTA memerlukan AVB2.0?
Tidak.
Apakah OTA A/B merusak perlindungan rollback AVB2.0?
Tidak. Ada beberapa kebingungan di sini karena jika sistem A/B gagal melakukan booting ke image sistem baru, sistem akan (setelah beberapa kali percobaan ulang yang ditentukan oleh bootloader Anda) otomatis kembali ke image sistem "sebelumnya". Namun, poin penting di sini adalah bahwa "sebelumnya" dalam konteks A/B sebenarnya masih merupakan image sistem "saat ini". Segera setelah perangkat berhasil mem-boot image baru, perlindungan rollback akan diaktifkan dan memastikan 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 sedang berjalan, bukankah itu lambat?
Dengan update non-A/B, tujuannya adalah menginstal update secepat mungkin karena pengguna sedang menunggu dan tidak dapat menggunakan perangkatnya saat update diterapkan. Dengan update A/B, hal sebaliknya berlaku; karena pengguna masih menggunakan perangkatnya, tujuannya adalah meminimalkan dampak, sehingga update dilakukan dengan sengaja secara perlahan. 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 penjedaan/pelanjutan update, dan klien dapat menggunakannya untuk menjeda update jika pengguna mulai menggunakan perangkat dan melanjutkannya saat perangkat tidak digunakan lagi.
Ada dua fase saat melakukan OTA, yang ditampilkan dengan jelas di UI sebagai Langkah 1 dari 2 dan Langkah 2 dari 2 di bawah status progres. Langkah 1 sesuai dengan penulisan blok data, sedangkan langkah 2 adalah pra-kompilasi 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 melakukan pra-kompilasi image sistem baru. Hal ini jelas memiliki batas yang kurang jelas pada persyaratannya karena mengompilasi aplikasi sebenarnya. Dan jelas ada lebih banyak pekerjaan yang terlibat dalam mengompilasi aplikasi yang besar dan kompleks daripada aplikasi yang kecil dan sederhana; sedangkan pada fase 1 tidak ada blok disk yang lebih besar atau lebih kompleks daripada yang lain.
Prosesnya 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 sebenarnya sedang menunggu update?
Implementasi saat ini di GmsCore tidak membedakan antara update latar belakang dan update yang dimulai pengguna, tetapi mungkin akan melakukannya pada masa mendatang. Jika pengguna secara eksplisit meminta update diinstal atau sedang melihat layar progres update, kami akan memprioritaskan tugas update dengan asumsi bahwa pengguna sedang menunggu update selesai.
Apa yang terjadi jika pembaruan 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 menerapkan update tidak memengaruhi sistem yang sedang berjalan. Update dapat dicoba lagi nanti.