Mengurangi ukuran OTA

Halaman ini menjelaskan perubahan yang ditambahkan ke AOSP untuk mengurangi perubahan file yang tidak perlu antar-build. Pengimplementasi perangkat yang mengelola sistem build-nya sendiri dapat menggunakan informasi ini sebagai panduan untuk mengurangi ukuran update {i>over-the-air<i} (OTA).

Update OTA Android terkadang berisi file yang diubah yang tidak sesuai dengan perubahan kode. Mereka sebenarnya membangun artefak sistem. Hal ini dapat terjadi ketika kode yang sama, dibuat dengan waktu, dari direktori yang berbeda, atau pada komputer yang berbeda menghasilkan sejumlah besar perubahan . Kelebihan file tersebut memperbesar ukuran patch OTA, dan menyulitkan untuk menentukan kode mana yang berubah.

Agar konten OTA lebih transparan, AOSP menyertakan perubahan sistem build yang dirancang untuk mengurangi ukuran {i>patch<i} OTA. Perubahan file yang tidak diperlukan di antara build telah dihilangkan, dan hanya file terkait {i>patch<i} yang terkandung dalam pembaruan OTA. AOSP juga menyertakan alat perbedaan build, yang memfilter filter umum terkait build perubahan file untuk menyediakan diff file build yang lebih bersih, dan alat pemetaan blok, yang membantu Anda mempertahankan alokasi blok konsisten.

Sistem build bisa membuat patch besar yang tidak perlu dalam beberapa cara. Untuk memitigasi hal ini, Android 8.0 dan yang lebih tinggi, fitur baru diimplementasikan untuk mengurangi ukuran patch file tersebut. Peningkatan yang mengurangi ukuran paket update OTA meliputi:

  • Penggunaan ZSTD, algoritma kompresi lossless dengan tujuan umum untuk file image pada update perangkat non-A/B. ZSTD dapat disesuaikan untuk rasio kompresi dengan meningkatkan tingkat kompresi. Level kompresi disetel selama OTA waktu pembuatan dan dapat diatur dengan meneruskan flag --vabc_compression_param=zstd,$COMPRESSION_LEVEL
  • Meningkatkan ukuran jendela kompresi yang digunakan selama OTA. Ukuran jendela kompresi maksimum dapat ditetapkan dengan menyesuaikan parameter build di file .mk perangkat. Ini variabel diatur sebagai PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 262144
  • Penggunaan kompresi ulang Puffin, alat patching determenistik untuk deflate , yang menangani fungsi kompresi dan diff untuk pembuatan update OTA A/B.
  • Perubahan pada penggunaan alat pembuatan delta, seperti bagaimana bsdiff library digunakan untuk mengompresi patch. Di Android 9 dan yang lebih tinggi, Alat bsdiff memilih algoritma kompresi yang akan memberikan hasil kompresi terbaik untuk patch.
  • Perbaikan pada update_engine mengakibatkan lebih sedikit pemakaian memori saat patch diterapkan untuk update perangkat A/B.

Bagian berikut membahas berbagai masalah yang memengaruhi ukuran update OTA beserta solusinya, dan contoh implementasi di AOSP.

Urutan file

Masalah: Sistem file tidak menjamin urutan file saat diminta untuk memberikan daftar file di direktori, meskipun umumnya sama untuk {i>checkout<i} yang sama. Alat seperti ls mengurutkan hasil secara default, tetapi fungsi karakter pengganti yang digunakan oleh perintah seperti karena find dan make tidak mengurutkan. Sebelum menggunakan alat ini, Anda harus mengurutkan output-nya.

Solusi: Saat Anda menggunakan alat seperti find dan make dengan fungsi karakter pengganti, mengurutkan output perintah ini sebelum menggunakan mereka. Saat menggunakan $(wildcard) atau $(shell find) di Android.mk, mengurutkannya juga. Beberapa alat, seperti Java, melakukan pengurutan input, jadi sebelum mengurutkan file, pastikan alat yang Anda gunakan belum melakukannya.

Contoh: Banyak instance yang diperbaiki dalam sistem build inti menggunakan makro all-*-files-under bawaan, yang mencakup all-cpp-files-under (karena beberapa definisi tersebar di makefile lain). Untuk mengetahui detailnya, lihat referensi berikut:

Direktori build

Masalah: Mengubah direktori tempat file dibuat dapat menyebabkan biner berbeda. Sebagian besar jalur di build Android adalah jalur relatif sehingga __FILE__ di C/C++ tidak masalah. Namun, simbol debug mengenkode nama jalur secara default, dan .note.gnu.build-id dihasilkan dari proses hashing, biner yang sudah dihilangkan, sehingga akan berubah jika simbol debug berubah.

Solusi: AOSP kini membuat jalur debug bersifat relatif. Untuk mengetahui detailnya, lihat CL: https://android.googlesource.com/platform/build/+/6a66a887baadc9eb3d0d60e26f748b8453e27a02.

Stempel waktu

Masalah: Stempel waktu dalam output build menyebabkan perubahan file yang tidak perlu. Hal ini mungkin terjadi di lokasi berikut:

  • Makro __DATE__/__TIME__/__TIMESTAMP__ dalam kode C atau C++.
  • Stempel waktu yang disematkan dalam arsip berbasis zip.

Solusi/Contoh: Untuk menghapus stempel waktu dari output build, gunakan petunjuk yang diberikan di bawah ini dalam __DATE__/__TIME__/__TIMESTAMP__ di C/C++. dan Stempel waktu yang disematkan dalam arsip.

__DATE__/__TIME__/__TIMESTAMP__ dalam C/C++

Makro ini selalu menghasilkan output yang berbeda untuk build yang berbeda, jadi jangan menggunakannya. Di sini, adalah beberapa opsi untuk menghilangkan makro ini:

Stempel waktu yang disematkan dalam arsip (zip, jar)

Android 7.0 memperbaiki masalah stempel waktu yang disematkan dalam arsip zip dengan menambahkan -X untuk semua penggunaan perintah zip. Tindakan ini menghapus UID/GID dan penanda waktu Unix yang diperluas dari file {i>zip<i}.

Alat baru, ziptime (yang terletak di /platform/build/+/main/tools/ziptime/) mereset stempel waktu normal di header zip. Untuk mengetahui detailnya, lihat File README.

Alat signapk menyetel stempel waktu untuk file APK yang dapat bervariasi, bergantung pada zona waktu server tertentu. Untuk mengetahui detailnya, lihat CL https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.

Alat signapk menyetel stempel waktu untuk file APK yang dapat bervariasi, bergantung pada zona waktu server tertentu. Untuk mengetahui detailnya, lihat CL https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.

String versi

Masalah: String versi APK sering kali ditambahi BUILD_NUMBER ke versi hardcode. Bahkan jika tidak ada yang berubah dalam APK, maka APK masih akan berbeda.

Solusi: Hapus nomor build dari string versi APK.

Contoh:

Mengaktifkan komputasi verifikasi di perangkat

Jika dm-verity diaktifkan di perangkat Anda, maka alat OTA secara otomatis mengambil konfigurasi verifikasi Anda, dan mengaktifkan komputasi verifikasi di perangkat. Hal ini memungkinkan blok verifikasi dihitung di Android perangkat Anda, alih-alih disimpan sebagai byte mentah di paket OTA Anda. Blok Verity dapat menggunakan sekitar 16 MB untuk partisi 2 GB.

Namun, kecepatan komputasi di perangkat dapat memerlukan waktu lama. Secara khusus, opsi Forward Kode koreksi error dapat memerlukan waktu yang lama. Pada perangkat Pixel, memerlukan waktu hingga 10 menit. Pada perangkat kelas bawah, waktu yang diperlukan bisa lebih lama. Jika Anda ingin menonaktifkan verifikasi di perangkat komputasi ini, tetapi masih mengaktifkan {i> dm-verity<i}, Anda dapat melakukannya dengan meneruskan --disable_fec_computation ke alat ota_from_target_files saat melakukan update OTA. Tanda ini menonaktifkan komputasi verifikasi di perangkat selama update OTA. Mengurangi waktu penginstalan OTA, tetapi meningkatkan ukuran paket OTA. Jika perangkat Anda tidak mengaktifkan dm-verity, meneruskan tanda ini tidak akan memberikan pengaruh apa pun.

Alat build yang konsisten

Masalah: Alat yang menghasilkan file terinstal harus konsisten ( input sebelumnya seharusnya selalu menghasilkan output yang sama).

Solusi/Contoh: Perubahan diperlukan pada alat build berikut:

Menggunakan alat perbedaan build

Jika tidak mungkin untuk menghilangkan perubahan file terkait build, AOSP menyertakan build diff, target_files_diff.py untuk digunakan dalam membandingkan dua paket file. Alat ini melakukan operasi beda rekursif antara dua build, kecuali perubahan file terkait build umum, seperti

  • Perubahan yang diharapkan dalam output build (misalnya, karena perubahan nomor build).
  • Perubahan karena masalah umum dalam sistem build saat ini.

Untuk menggunakan alat build diff, jalankan perintah berikut:

target_files_diff.py dir1 dir2

dir1 dan dir2 adalah direktori dasar yang berisi target yang diekstrak untuk setiap build.

Menjaga alokasi blok tetap konsisten

Untuk file tertentu, meskipun kontennya tetap sama di antara dua build, blok sebenarnya yang menyimpan data mungkin telah berubah. Akibatnya, updater harus melakukan I/O yang tidak perlu untuk memindahkan blok untuk pembaruan OTA.

Dalam update A/B OTA Virtual, I/O yang tidak perlu bisa sangat meningkatkan ruang penyimpanan yang diperlukan untuk menyimpan {i>snapshot<i} {i>copy-on-write<i}. Dalam update OTA non-A/B, memindahkan blok untuk Update OTA berkontribusi pada waktu update karena ada lebih banyak I/O karena perpindahan blok.

Untuk mengatasi masalah ini, di Android 7.0, Google memperluas alat make_ext4fs untuk menjaga alokasi blok tetap konsisten di seluruh build. Alat make_ext4fs menerima flag -d base_fs opsional yang mencoba mengalokasikan file ke blok yang sama saat membuat gambar ext4. Anda dapat mengekstrak file pemetaan blok (seperti base_fs file peta) dari file target build sebelumnya file ZIP. Untuk setiap Partisi ext4, ada file .map di Direktori IMAGES (misalnya, IMAGES/system.map sesuai dengan partisi system). base_fs file ini kemudian dapat diperiksa dan ditentukan melalui PRODUCT_<partition>_BASE_FS_PATH, seperti dalam contoh ini: 

  PRODUCT_SYSTEM_BASE_FS_PATH := path/to/base_fs_files/base_system.map
  PRODUCT_SYSTEM_EXT_BASE_FS_PATH := path/to/base_fs_files/base_system_ext.map
  PRODUCT_VENDOR_BASE_FS_PATH := path/to/base_fs_files/base_vendor.map
  PRODUCT_PRODUCT_BASE_FS_PATH := path/to/base_fs_files/base_product.map
  PRODUCT_ODM_BASE_FS_PATH := path/to/base_fs_files/base_odm.map

Meskipun ini tidak membantu mengurangi ukuran paket OTA secara keseluruhan, ini dapat memperbaiki pembaruan OTA dengan mengurangi jumlah I/O. Untuk update A/B Virtual, ini secara drastis mengurangi jumlah ruang penyimpanan yang diperlukan untuk menerapkan OTA.

Hindari mengupdate aplikasi

Selain meminimalkan perbedaan build, Anda dapat mengurangi ukuran update OTA dengan mengecualikan update untuk aplikasi yang mendapatkan update melalui app store. APK sering kali merupakan bagian penting dari berbagai partisi pada perangkat. Termasuk versi terbaru aplikasi yang diupdate oleh aplikasi menyimpan pembaruan OTA mungkin berdampak besar pada paket OTA, dan menyediakan sedikit manfaat produk. Pada saat pengguna menerima paket OTA, mereka mungkin sudah memiliki aplikasi yang diperbarui, atau versi yang lebih baru, yang diterima langsung dari {i>app store<i}.