Apakah Google telah menggunakan A/B OTA di perangkat apa pun?
Ya. Nama pemasaran untuk pembaruan A/B adalah pembaruan tanpa batas . Ponsel Pixel dan Pixel XL mulai Oktober 2016 dikirimkan dengan A/B, dan semua Chromebook menggunakan implementasi A/B update_engine yang sama. 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 melakukan pembaruan. Pengukuran dari pembaruan keamanan bulanan menunjukkan bahwa fitur ini telah terbukti berhasil: Mulai Mei 2017, 95% pemilik Pixel menjalankan pembaruan keamanan terbaru setelah sebulan dibandingkan dengan 87% pengguna Nexus, dan pengguna Pixel memperbarui lebih cepat daripada pengguna Nexus. Kegagalan memperbarui blok selama OTA tidak lagi mengakibatkan perangkat tidak bisa boot; hingga citra sistem baru berhasil di-boot, Android mempertahankan kemampuan untuk kembali ke citra sistem kerja sebelumnya.
Bagaimana pengaruh A/B terhadap ukuran partisi Pixel 2016?
Tabel berikut berisi detail tentang konfigurasi A/B pengiriman versus konfigurasi non-A/B yang diuji secara internal:
| Ukuran partisi piksel | A/B | Non-A/B |
|---|---|---|
| Pemuat boot | 50*2 | 50 |
| Boot | 32*2 | 32 |
| Pemulihan | 0 | 32 |
| Cache | 0 | 100 |
| Radio | 70*2 | 70 |
| Penjual | 300*2 | 300 |
| Sistem | 2048*2 | 4096 |
| Total | 5000 | 4680 |
Pembaruan A/B memerlukan peningkatan hanya 320 MiB dalam flash, dengan penghematan 32MiB dari penghapusan partisi pemulihan dan 100MiB lainnya dipertahankan dengan menghapus partisi cache. Ini menyeimbangkan biaya partisi B untuk bootloader, partisi boot, dan partisi radio. Partisi vendor berukuran dua kali lipat (sebagian besar ukurannya meningkat). Gambar sistem A/B Pixel berukuran setengah dari gambar sistem non-A/B asli.
Untuk varian Pixel A/B dan non-A/B yang diuji secara internal (hanya A/B yang dikirim), ruang yang digunakan hanya berbeda 320MiB. Pada perangkat 32GiB, ini hanya di bawah 1%. Untuk perangkat 16GiB ini akan kurang dari 2%, dan untuk perangkat 8GiB hampir 4% (dengan asumsi ketiga perangkat memiliki citra sistem yang sama).
Mengapa Anda tidak menggunakan SquashFS?
Kami bereksperimen dengan SquashFS tetapi tidak dapat mencapai kinerja yang diinginkan untuk perangkat kelas atas. Kami tidak menggunakan atau merekomendasikan SquashFS untuk perangkat genggam.
Lebih khusus lagi, SquashFS menyediakan penghematan ukuran sekitar 50% pada partisi sistem, tetapi sebagian besar file yang dikompresi dengan baik adalah file .odex yang telah dikompilasi sebelumnya. File-file tersebut memiliki rasio kompresi yang sangat tinggi (mendekati 80%), tetapi rasio kompresi untuk sisa partisi sistem jauh lebih rendah. Selain itu, SquashFS di Android 7.0 mengangkat masalah kinerja berikut:
- Pixel memiliki flash yang sangat cepat dibandingkan dengan perangkat sebelumnya tetapi tidak banyak siklus CPU cadangan, jadi membaca lebih sedikit byte dari flash tetapi membutuhkan lebih banyak CPU untuk I/O berpotensi menjadi hambatan.
- Perubahan I/O yang berkinerja baik pada benchmark buatan yang dijalankan pada sistem yang tidak dimuat terkadang tidak berfungsi dengan baik pada kasus penggunaan dunia nyata di bawah beban dunia nyata (seperti crypto pada Nexus 6).
- Benchmarking menunjukkan regresi 85% di beberapa tempat.
Saat SquashFS matang dan menambahkan fitur untuk mengurangi dampak CPU (seperti daftar putih file yang sering diakses yang tidak boleh dikompresi), kami akan terus mengevaluasinya dan menawarkan rekomendasi kepada produsen perangkat.
Bagaimana Anda membagi dua ukuran partisi sistem tanpa SquashFS?
Aplikasi disimpan dalam file .apk, yang sebenarnya adalah arsip ZIP. Setiap file .apk memiliki di dalamnya satu atau lebih file .dex yang berisi bytecode Dalvik portabel. File .odex (dioptimalkan .dex) hidup terpisah dari file .apk dan dapat berisi kode mesin khusus untuk perangkat. Jika file .odex tersedia, Android dapat menjalankan aplikasi dengan kecepatan kompilasi sebelumnya tanpa harus menunggu kode dikompilasi setiap kali aplikasi diluncurkan. File .odex tidak sepenuhnya 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 waktu proses jika ruang tersedia.
Contoh: Untuk file yang diinstal.txt dari Nexus 6P yang menjalankan Android 7.1 dengan ukuran citra sistem total 2628MiB (2755792836 byte), perincian kontributor terbesar untuk ukuran citra sistem secara keseluruhan menurut jenis file adalah sebagai berikut:
| .odex | 1391770312 byte | 50,5% |
| .apk | 846878259 byte | 30,7% |
| .so (kode C/C++ asli) | 202162479 byte | 7.3% |
| .oat file/.gambar seni | 163892188 byte | 5,9% |
| font | 38952361 byte | 1,4% |
| data lokal icu | 27468687 byte | 0,9% |
Angka-angka ini juga serupa untuk perangkat lain, jadi pada perangkat Nexus/Pixel, file .odex mengambil kira-kira setengah dari partisi sistem. Ini berarti kita dapat terus menggunakan ext4 tetapi menulis file .odex ke partisi B di pabrik dan kemudian menyalinnya ke /data saat boot pertama. Penyimpanan aktual yang digunakan dengan ext4 A/B identik dengan SquashFS A/B, karena jika kami menggunakan SquashFS, kami akan mengirimkan file .odex yang telah dipilih sebelumnya pada system_a alih-alih system_b.
Bukankah menyalin file .odex ke /data berarti ruang yang disimpan di /sistem hilang di /data?
Tidak persis. Di Pixel, sebagian besar ruang yang diambil oleh file .odex adalah untuk aplikasi, yang biasanya ada di /data . Aplikasi ini mengambil pembaruan Google Play, sehingga file .apk dan .odex pada citra sistem tidak digunakan untuk sebagian besar masa pakai perangkat. File tersebut dapat dikecualikan seluruhnya dan diganti dengan file .odex kecil yang digerakkan oleh profil saat pengguna benar-benar menggunakan setiap aplikasi (sehingga tidak memerlukan ruang untuk aplikasi yang tidak digunakan pengguna). Untuk detailnya, lihat pembicaraan Google I/O 2016 The Evolution of Art .
Perbandingannya sulit karena beberapa alasan utama:
- Aplikasi yang diperbarui oleh Google Play selalu memiliki file .odex di
/datasegera setelah mereka menerima pembaruan pertama. - Aplikasi yang tidak dijalankan pengguna tidak memerlukan file .odex sama sekali.
- Kompilasi berbasis profil menghasilkan file .odex yang lebih kecil daripada kompilasi sebelumnya (karena yang pertama hanya mengoptimalkan kode kinerja-kritis).
Untuk detail tentang opsi penyetelan yang tersedia untuk OEM, lihat Mengonfigurasi ART .
Bukankah ada dua salinan file .odex di /data?
Ini sedikit lebih rumit ... Setelah citra sistem baru ditulis, versi baru dex2oat dijalankan terhadap file .dex baru untuk menghasilkan file .odex baru. Ini terjadi saat sistem lama masih berjalan, sehingga file .odex lama dan baru berada di /data secara bersamaan.
Kode di OtaDexoptService ( frameworks/base/+/master/services/core/java/com/android/server/pm/OtaDexoptService.java ) memanggil getAvailableSpace sebelum mengoptimalkan setiap paket untuk menghindari pengisian yang berlebihan /data . Perhatikan bahwa yang tersedia di sini masih konservatif: ini adalah jumlah ruang yang tersisa sebelum mencapai ambang batas ruang rendah sistem yang biasa (diukur sebagai persentase dan jumlah byte). Jadi jika /data penuh, tidak akan ada dua salinan dari setiap file .odex. Kode yang sama juga memiliki BULK_DELETE_THRESHOLD: Jika perangkat hampir memenuhi ruang yang tersedia (seperti yang baru saja dijelaskan), file .odex milik aplikasi yang tidak digunakan akan dihapus. Itu kasus lain tanpa dua salinan dari setiap file .odex.
Dalam kasus terburuk di mana /data benar-benar penuh, pembaruan menunggu hingga perangkat di-boot ulang ke sistem baru dan tidak lagi memerlukan file .odex sistem lama. PackageManager menangani ini: ( frameworks/base/+/master/services/core/java/com/android/server/pm/PackageManagerService.java#7215 ). Setelah sistem baru berhasil di-boot, installd ( frameworks/native/+/master/cmds/installd/dexopt.cpp#2422 ) dapat menghapus file .odex yang digunakan oleh sistem lama, mengembalikan perangkat ke kondisi stabil di mana hanya ada satu salinan.
Jadi, meskipun mungkin /data berisi dua salinan dari semua file .odex, (a) ini bersifat sementara dan (b) hanya terjadi jika Anda memiliki banyak ruang kosong di /data . Kecuali selama pembaruan, hanya ada satu salinan. Dan sebagai bagian dari fitur ketahanan umum ART, ART tidak akan pernah mengisi /data dengan file .odex (karena itu juga akan menjadi masalah pada sistem non-A/B).
Bukankah semua tulisan/penyalinan ini meningkatkan keausan flash?
Hanya sebagian kecil flash yang ditulis ulang: pembaruan sistem Pixel penuh menulis tentang 2.3GiB. (Aplikasi juga dikompilasi ulang, tetapi itu juga berlaku untuk non-A/B.) Secara tradisional, OTA penuh berbasis blok menulis jumlah data yang serupa, jadi tingkat keausan flash harus serupa.
Apakah mem-flash dua partisi sistem meningkatkan waktu flashing pabrik?
Tidak. Pixel tidak bertambah dalam ukuran gambar sistem (itu hanya membagi ruang di dua partisi).
Tidakkah menyimpan file .odex di B membuat reboot setelah reset data pabrik menjadi lambat?
Ya. Jika Anda benar-benar menggunakan perangkat, mengambil OTA, dan melakukan reset data pabrik, reboot pertama akan lebih lambat daripada yang seharusnya (1m40s vs 40s pada Pixel XL) karena file .odex akan hilang dari B setelah OTA pertama sehingga tidak dapat disalin ke /data . Itulah trade-off.
Reset data pabrik harus menjadi operasi yang jarang jika dibandingkan dengan boot biasa sehingga waktu yang dibutuhkan tidak terlalu penting. (Ini tidak mempengaruhi pengguna atau pengulas yang mendapatkan perangkat mereka dari pabrik, karena dalam hal ini partisi B tersedia.) Penggunaan kompiler JIT berarti kita tidak perlu mengkompilasi ulang semuanya , jadi tidak seburuk Anda mungkin berpikir. Anda juga dapat menandai aplikasi yang memerlukan kompilasi sebelumnya menggunakan coreApp="true" dalam manifes: ( frameworks/base/+/master/packages/SystemUI/AndroidManifest.xml#23 ). Ini saat ini digunakan oleh system_server karena tidak diizinkan untuk JIT karena alasan keamanan.
Tidakkah menyimpan file .odex di /data daripada /sistem membuat reboot setelah OTA lambat?
Tidak. Seperti yang dijelaskan di atas, dex2oat baru dijalankan sementara citra sistem lama masih berjalan untuk menghasilkan file yang akan dibutuhkan oleh sistem baru. Pembaruan tidak dianggap tersedia sampai pekerjaan itu selesai.
Bisakah (harus) kami mengirimkan perangkat A/B 32GiB? 16GiB? 8GiB?
32GiB bekerja dengan baik seperti yang telah terbukti pada Pixel, dan 320MiB dari 16GiB berarti pengurangan 2%. Demikian pula, 320MiB dari 8GiB pengurangan 4%. Jelas A/B tidak akan menjadi pilihan yang disarankan pada perangkat dengan 4GiB, karena overhead 320MiB hampir 10% dari total ruang yang tersedia.
Apakah AVB2.0 memerlukan A/B OTA?
Tidak. Android Verified Boot selalu memerlukan pembaruan berbasis blok, tetapi tidak harus pembaruan A/B.
Apakah A/B OTA memerlukan AVB2.0?
Tidak.
Apakah A/B OTA merusak perlindungan rollback AVB2.0?
Tidak. Ada beberapa kebingungan di sini karena jika sistem A/B gagal melakukan boot ke citra sistem baru, sistem tersebut akan (setelah beberapa kali percobaan ulang yang ditentukan oleh bootloader Anda) secara otomatis kembali ke citra sistem "sebelumnya". Poin kuncinya di sini adalah bahwa "sebelumnya" dalam arti A/B sebenarnya masih merupakan citra sistem "saat ini". Segera setelah perangkat berhasil mem-boot image baru, perlindungan rollback masuk dan memastikan bahwa Anda tidak dapat kembali. Tetapi sampai Anda benar-benar berhasil mem-boot image baru, perlindungan rollback tidak menganggapnya sebagai image sistem saat ini.
Jika Anda menginstal pembaruan saat sistem sedang berjalan, bukankah itu lambat?
Dengan pembaruan non-A/B, tujuannya adalah untuk menginstal pembaruan secepat mungkin karena pengguna menunggu dan tidak dapat menggunakan perangkat mereka saat pembaruan diterapkan. Dengan pembaruan A/B, yang terjadi adalah kebalikannya; karena pengguna masih menggunakan perangkat mereka, dampak sekecil mungkin adalah tujuannya, jadi pembaruannya sengaja lambat. Melalui logika di klien pembaruan sistem Java (yang bagi Google adalah GmsCore, paket inti yang disediakan oleh GMS), Android juga mencoba memilih waktu ketika pengguna tidak menggunakan perangkat mereka sama sekali. Platform mendukung jeda/melanjutkan pembaruan, dan klien dapat menggunakannya untuk menjeda pembaruan jika pengguna mulai menggunakan perangkat dan melanjutkannya saat perangkat tidak digunakan lagi.
Ada dua fase saat mengambil OTA, ditampilkan dengan jelas di UI sebagai Langkah 1 dari 2 dan Langkah 2 dari 2 di bawah bilah kemajuan. Langkah 1 berhubungan dengan penulisan blok data, sedangkan langkah 2 adalah pra-kompilasi file .dex. Kedua fase ini sangat berbeda dalam hal dampak kinerja. Fase pertama adalah I/O sederhana. Ini membutuhkan sedikit sumber daya (RAM, CPU, I/O) karena hanya menyalin blok secara perlahan.
Fase kedua menjalankan dex2oat untuk mengkompilasi citra sistem baru. Ini jelas memiliki batasan yang kurang jelas pada persyaratannya karena mengkompilasi aplikasi yang sebenarnya. Dan jelas ada lebih banyak pekerjaan yang terlibat dalam kompilasi aplikasi besar dan kompleks daripada aplikasi kecil dan sederhana; sedangkan pada fase 1 tidak ada blok disk yang lebih besar atau lebih kompleks dari yang lain.
Prosesnya mirip dengan saat Google Play menginstal pembaruan aplikasi di latar belakang sebelum menampilkan pemberitahuan pembaruan 5 aplikasi , seperti yang telah dilakukan selama bertahun-tahun.
Bagaimana jika pengguna benar-benar menunggu pembaruan?
Implementasi saat ini di GmsCore tidak membedakan antara pembaruan latar belakang dan pembaruan yang dimulai oleh pengguna, tetapi dapat melakukannya di masa mendatang. Dalam kasus di mana pengguna secara eksplisit meminta pembaruan untuk diinstal atau sedang menonton layar kemajuan pembaruan, kami akan memprioritaskan pekerjaan pembaruan dengan asumsi bahwa mereka secara aktif menunggu sampai selesai.
Apa yang terjadi jika ada kegagalan untuk menerapkan pembaruan?
Dengan pembaruan non-A/B, jika pembaruan gagal diterapkan, pengguna biasanya dibiarkan dengan perangkat yang tidak dapat digunakan. Satu-satunya pengecualian adalah jika kegagalan terjadi bahkan sebelum aplikasi dimulai (karena paket gagal untuk memverifikasi, katakanlah). Dengan pembaruan A/B, kegagalan untuk menerapkan pembaruan tidak memengaruhi sistem yang sedang berjalan. Pembaruan hanya dapat dicoba lagi nanti.
Sistem mana pada chip (SoC) yang mendukung A/B?
Pada 2017-03-15, kami memiliki informasi berikut:
| Android 7.x dan sebelumnya | Android 8.x dan yang lebih baru | |
| Qualcomm | Tergantung pada permintaan OEM | Semua chipset akan mendapatkan dukungan |
| Mediatek | Tergantung pada permintaan OEM | Semua chipset akan mendapatkan dukungan |
Untuk detail tentang jadwal, hubungi kontak SoC Anda. Untuk SoC yang tidak tercantum di atas, hubungi SoC Anda secara langsung.