Pertanyaan umum (FAQ)

Apakah Google telah menggunakan A/B OTA pada 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 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 satu bulan dibandingkan dengan 87% pengguna Nexus, dan pengguna Pixel melakukan pembaruan lebih cepat dibandingkan pengguna Nexus. Kegagalan memperbarui blok selama OTA tidak lagi mengakibatkan perangkat tidak bisa boot; hingga image sistem baru berhasil di-boot, Android tetap memiliki kemampuan untuk kembali ke image sistem kerja sebelumnya.

Bagaimana pengaruh A/B terhadap ukuran partisi Pixel 2016?

Tabel berikut berisi detail tentang konfigurasi pengiriman A/B versus konfigurasi non-A/B yang diuji secara internal:

Pembaruan A/B hanya memerlukan peningkatan sebesar 320 MiB dalam flash, dengan penghematan sebesar 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 bertambah). 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 dikirimkan), ruang yang digunakan hanya berbeda sebesar 320MiB. Pada perangkat 32GiB, angka ini hanya di bawah 1%. Untuk perangkat 16GiB, angka ini akan kurang dari 2%, dan untuk perangkat 8GiB hampir 4% (dengan asumsi ketiga perangkat memiliki image 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 memberikan penghematan ukuran sekitar 50% pada partisi sistem, namun 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%), namun rasio kompresi untuk partisi sistem lainnya jauh lebih rendah. Selain itu, SquashFS di Android 7.0 mengemukakan masalah kinerja berikut:

• Pixel memiliki flash yang sangat cepat dibandingkan perangkat sebelumnya, namun siklus CPU cadangannya tidak banyak, jadi membaca byte yang lebih sedikit dari flash namun memerlukan lebih banyak CPU untuk I/O merupakan potensi hambatan.
• Perubahan I/O yang berkinerja baik pada tolok ukur buatan yang dijalankan pada sistem tanpa muatan terkadang tidak berfungsi dengan baik pada kasus penggunaan dunia nyata dengan beban dunia nyata (seperti kripto di Nexus 6).
• Pembandingan menunjukkan regresi sebesar 85% di beberapa tempat.

Saat SquashFS semakin matang dan menambahkan fitur untuk mengurangi dampak CPU (seperti daftar putih file yang sering diakses dan 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 merupakan arsip ZIP. Setiap file .apk di dalamnya terdapat satu atau lebih file .dex yang berisi bytecode Dalvik portabel. File .odex (.dex yang dioptimalkan) berada secara 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), namun file .odex memberikan kombinasi terbaik antara kecepatan peluncuran dan kecepatan run-time jika ruang tersedia.

Contoh: Untuk file-files.txt yang diinstal dari Nexus 6P yang menjalankan Android 7.1 dengan total ukuran citra sistem sebesar 2628MiB (2755792836 byte), perincian kontributor terbesar terhadap ukuran citra sistem secara keseluruhan berdasarkan jenis file adalah sebagai berikut:

Angka-angka ini serupa untuk perangkat lain juga, jadi pada perangkat Nexus/Pixel, file .odex menempati sekitar setengah partisi sistem. Ini berarti kita dapat terus menggunakan ext4 tetapi menulis file .odex ke partisi B di pabrik dan kemudian menyalinnya ke /data pada boot pertama. Penyimpanan sebenarnya yang digunakan dengan ext4 A/B identik dengan SquashFS A/B, karena jika kami menggunakan SquashFS kami akan mengirimkan file .odex yang sudah dipilih sebelumnya di system_a, bukan di system_b.

Bukankah menyalin file .odex ke/data berarti ruang yang disimpan di/sistem hilang di/data?

Tidak tepat. Di Pixel, sebagian besar ruang yang digunakan oleh file .odex ditujukan untuk aplikasi, yang biasanya ada di /data . Aplikasi ini memerlukan pembaruan Google Play, sehingga file .apk dan .odex pada image sistem tidak digunakan hampir sepanjang masa pakai perangkat. File tersebut dapat dikecualikan seluruhnya dan diganti dengan file .odex kecil yang berdasarkan profil ketika 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 .

Perbandingan ini sulit dilakukan karena beberapa alasan utama:

• Aplikasi yang diperbarui oleh Google Play selalu memiliki file .odex di /data segera setelah menerima pembaruan pertama.
• Aplikasi yang tidak dijalankan pengguna tidak memerlukan file .odex sama sekali.
• Kompilasi berbasis profil menghasilkan file .odex yang lebih kecil dibandingkan kompilasi sebelumnya (karena kompilasi sebelumnya hanya mengoptimalkan kode yang kritis terhadap kinerja).

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 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 secara bersamaan.

Kode di OtaDexoptService ( frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java ) memanggil getAvailableSpace sebelum mengoptimalkan setiap paket untuk menghindari pengisian yang berlebihan /data . Perhatikan bahwa 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 untuk 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 ketika /data benar-benar penuh, pembaruan menunggu hingga perangkat telah di-boot ulang ke sistem baru dan tidak lagi memerlukan file .odex sistem lama. PackageManager menangani ini: ( frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215 ). Setelah sistem baru berhasil di-boot, installd ( frameworks/native/+/main/cmds/installd/dexopt.cpp#2422 ) dapat menghapus file .odex yang digunakan oleh sistem lama, sehingga perangkat kembali ke kondisi stabil dimana 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 saat update, 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 penulisan/penyalinan ini meningkatkan keausan flash?

Hanya sebagian kecil dari flash yang ditulis ulang: pembaruan sistem Pixel lengkap menulis sekitar 2.3GiB. (Aplikasi juga dikompilasi ulang, tetapi hal ini juga berlaku untuk non-A/B.) Secara tradisional, OTA lengkap berbasis blok menulis jumlah data yang sama, sehingga tingkat keausan flash harus serupa.

Apakah mem-flash dua partisi sistem meningkatkan waktu flashing pabrik?

Tidak. Pixel tidak menambah ukuran image sistem (hanya membagi ruang menjadi dua partisi).

Tidakkah menyimpan file .odex di B membuat reboot setelah reset data pabrik menjadi lambat?

Ya. Jika Anda benar-benar menggunakan perangkat, menggunakan OTA, dan melakukan reset data pabrik, reboot pertama akan lebih lambat dibandingkan seharusnya (1m40s vs 40s pada Pixel XL) karena file .odex akan hilang dari B setelah OTA pertama dan seterusnya tidak dapat disalin ke /data . Itulah trade-offnya.

Reset data pabrik seharusnya merupakan operasi yang jarang terjadi jika dibandingkan dengan boot biasa sehingga waktu yang dibutuhkan tidak terlalu penting. (Ini tidak mempengaruhi pengguna atau pengulas yang mendapatkan perangkatnya 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 sebagai memerlukan kompilasi sebelumnya menggunakan coreApp="true" dalam manifes: ( frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23 ). Saat ini digunakan oleh system_server karena tidak diizinkan untuk JIT karena alasan keamanan.

Tidakkah menyimpan file .odex di /data daripada /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-file yang akan dibutuhkan oleh sistem baru. Pembaruan tidak dianggap tersedia sampai pekerjaan tersebut selesai.

Bisakah (harus) kami mengirimkan perangkat A/B 32GiB? 16 GiB? 8GiB?

32GiB berfungsi dengan baik seperti yang dibuktikan pada Pixel, dan 320MiB dari 16GiB berarti pengurangan sebesar 2%. Demikian pula, 320MiB dari 8GiB mengalami pengurangan sebesar 4%. Tentu saja A/B bukan pilihan yang direkomendasikan pada perangkat dengan 4GiB, karena overhead 320MiB hampir 10% dari total ruang yang tersedia.

Apakah AVB2.0 memerlukan OTA A/B?

Tidak. Boot Terverifikasi Android selalu memerlukan pembaruan berbasis blok, namun belum tentu pembaruan A/B.

Apakah OTA A/B 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 yang baru, sistem tersebut akan (setelah beberapa kali percobaan ulang yang ditentukan oleh bootloader Anda) secara otomatis kembali ke image sistem "sebelumnya". Poin kuncinya di sini adalah bahwa "sebelumnya" dalam pengertian A/B sebenarnya masih merupakan citra sistem "saat ini". Segera setelah perangkat berhasil mem-boot gambar baru, perlindungan rollback akan aktif dan memastikan Anda tidak dapat kembali. Namun hingga 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 menginstal pembaruan secepat mungkin karena pengguna menunggu dan tidak dapat menggunakan perangkat mereka saat pembaruan diterapkan. Dengan pembaruan A/B, yang terjadi justru sebaliknya; karena pengguna masih menggunakan perangkatnya, tujuannya adalah sesedikit mungkin dampaknya, sehingga pembaruan sengaja dilakukan lambat. Melalui logika di klien pembaruan sistem Java (untuk Google adalah GmsCore, paket inti yang disediakan oleh GMS), Android juga mencoba memilih waktu ketika pengguna tidak menggunakan perangkat mereka sama sekali. Platform ini 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, yang 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 memerlukan sedikit sumber daya (RAM, CPU, I/O) karena hanya menyalin blok secara perlahan.

Fase kedua menjalankan dex2oat untuk melakukan prakompilasi image sistem baru. Ini jelas memiliki batasan yang kurang jelas pada persyaratannya karena ini mengkompilasi aplikasi sebenarnya. Dan jelas ada lebih banyak pekerjaan yang harus dilakukan dalam mengompilasi aplikasi yang besar dan kompleks dibandingkan 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 memasang pembaruan aplikasi di latar belakang sebelum menampilkan pemberitahuan pembaruan 5 aplikasi , seperti yang telah dilakukan selama bertahun-tahun.

Bagaimana jika pengguna sebenarnya menunggu pembaruan?

Implementasi saat ini di GmsCore tidak membedakan antara pembaruan latar belakang dan pembaruan yang dilakukan pengguna, namun mungkin akan membedakannya di masa mendatang. Jika pengguna secara eksplisit meminta pembaruan untuk diinstal atau melihat layar kemajuan pembaruan, kami akan memprioritaskan pekerjaan pembaruan dengan asumsi bahwa mereka secara aktif menunggu hingga pembaruan selesai.

Apa yang terjadi jika terjadi kegagalan dalam menerapkan pembaruan?

Dengan pembaruan non-A/B, jika pembaruan gagal diterapkan, perangkat pengguna biasanya tidak dapat digunakan. Satu-satunya pengecualian adalah jika kegagalan terjadi bahkan sebelum aplikasi dimulai (misalnya karena paket gagal diverifikasi). Dengan pembaruan A/B, kegagalan menerapkan pembaruan tidak memengaruhi sistem yang sedang berjalan. Pembaruan dapat dicoba lagi nanti.

Sistem pada chip (SoC) mana yang mendukung A/B?

Pada 15-03-2017, kami memiliki informasi berikut:

Untuk detail tentang jadwal, hubungi kontak SoC Anda. Untuk SoC yang tidak tercantum di atas, hubungi langsung SoC Anda.