Generic system image (GSI)

Generic system image (GSI) adalah image sistem dengan konfigurasi yang disesuaikan. untuk perangkat Android. Ini dianggap sebagai implementasi Android murni dengan kode Proyek Open Source Android (AOSP) tanpa modifikasi yang diambil perangkat yang menjalankan Android 9 atau yang lebih tinggi dapat dijalankan dengan sukses.

GSI digunakan untuk menjalankan pengujian VTS dan CTS-on-GSI. Image sistem dari Perangkat Android diganti dengan GSI, lalu diuji dengan Paket Pengujian Vendor (VTS) dan Compatibility Test Suite (CTS) untuk memastikan bahwa perangkat menerapkan antarmuka vendor dengan benar dengan versi terbaru Android.

Untuk mulai menggunakan GSI, tinjau bagian berikut untuk mengetahui detail tentang Konfigurasi GSI (dan diizinkan varians) dan jenis. Saat Anda siap menggunakan GSI, mendownload dan membuat GSI untuk perangkat Anda target, lalu flash GSI ke perangkat Android perangkat seluler.

Konfigurasi dan varian GSI

GSI Android saat ini memiliki konfigurasi berikut:

• Treble. GSI mencakup dukungan penuh untuk Perubahan arsitektur berbasis AIDL/HIDL (juga dikenal sebagai Treble), termasuk dukungan untuk Antarmuka AIDL dan Antarmuka HiDL. Anda dapat menggunakan GSI di perangkat Android yang menggunakan antarmuka vendor AIDL/HIDL. (Untuk detail selengkapnya, lihat Referensi arsitektur.)
• Sistem file. GSI menggunakan sistem file ext4.

GSI Android saat ini mencakup varians utama berikut:

• arsitektur CPU. Dukungan untuk petunjuk CPU yang berbeda (ARM, x86, dll.) dan bitness CPU (32 bit atau 64 bit).

Target GSI untuk pengujian kepatuhan Treble

GSI yang digunakan untuk pengujian kepatuhan ditentukan oleh versi Android yang yang digunakan perangkat.

Semua GSI dibuat dari codebase Android 12, dan setiap arsitektur CPU memiliki biner GSI yang sesuai (lihat daftar build target dalam Membangun GSI).

Perubahan GSI Android 12

Perangkat yang diluncurkan dengan atau yang diupdate ke Android 12 harus menggunakan Android 12 GSI untuk pengujian kepatuhan. Pembaruan ini mencakup berikut perubahan besar dari GSI sebelumnya:

• Nama target. Nama target GSI untuk kepatuhan pengujian diubah menjadi gsi_$arch. GSI dengan nama target aosp_$arch disimpan untuk developer aplikasi Android. Rencana pengujian CTS-on-GSI juga dikurangi untuk menguji antarmuka vendor.
• GSI lama dihentikan. GSI 12 menghapus solusi yang mengakomodasi perangkat Android 8.0 atau 8.1 yang tidak sepenuhnya Treblized.
• Userdebug SEPolicy. GSI gsi_$arch berisi userdebug_plat_sepolicy.cil. Saat berkedip vendor_boot-debug.img khusus OEM atau boot-debug.img, /system/bin/init akan dimuat userdebug_plat_sepolicy.cil dari GSI system.img. Referensi Pengujian VTS dengan Debug Ramdisk untuk mengetahui detailnya.

Perubahan GSI Android 11

Perangkat yang diluncurkan dengan atau yang diupdate ke Android 11 harus menggunakan Android 11 GSI untuk pengujian kepatuhan. Pembaruan ini mencakup berikut perubahan besar dari GSI sebelumnya:

• system_ext. Android Angka 11 menentukan partisi baru system_ext. GSI menempatkan konten ekstensi sistem ke dalam folder system/system_ext.
• APEX. GSI berisi APEX yang diratakan dan dikompresi. Properti yang akan digunakan ditentukan oleh properti sistem ro.apex.updatable di partisi vendor pada runtime. Referensi Mengonfigurasi sistem agar mendukung update APEX untuk mengetahui detailnya.

Perubahan GSI Android 10

Perangkat yang diluncurkan dengan atau yang diupdate ke Android 10 harus menggunakan Android 10 GSI untuk pengujian kepatuhan. Pembaruan ini mencakup berikut perubahan besar dari GSI sebelumnya:

• Build pengguna. GSI memiliki build pengguna dari Android 10. Di Android 10, GSI build pengguna dapat digunakan dalam pengujian kepatuhan CTS-on-GSI/VTS. Referensi Pengujian VTS dengan Debug Ramdisk untuk mengetahui detailnya.
• Format tidak diurai. GSI dengan target aosp_$arch dibuat dengan format tidak diurai. Anda dapat menggunakan img2simg untuk mengonversi GSI tidak terurai menjadi format renggang jika diperlukan.
• Sistem sebagai root. Target build GSI lama bernama aosp_$arch_a telah dihentikan. Untuk perangkat yang diupgrade dari Android 8 atau 8.1 ke Android 10 dengan ramdisk dan non-sistem-sebagai-root, gunakan aosp_$arch_ab GSI lama. init yang diupgrade di ramdisk mendukung sistem OEM.img dengan tata letak {i>system-as-root<i}.
• Verifikasi booting. Dengan menggunakan GSI, Anda hanya perlu membuka kunci perangkat. Anda tidak perlu menonaktifkan booting verifikasi.

Perubahan GSI Android 9

Perangkat yang diluncurkan dengan atau yang diupdate ke Android 9 harus menggunakan Android 9 GSI untuk pengujian kepatuhan. Pembaruan ini mencakup berikut perubahan besar dari GSI sebelumnya:

• Menggabungkan GSI dan emulator. GSI dibangun dari sistem gambar produk emulator, misalnya aosp_arm64 dan aosp_x86.
• Sistem sebagai root. Di versi Android sebelumnya, perangkat yang tidak mendukung pembaruan A/B dapat memasang {i>image<i} sistem di bawah Direktori /system. Di Android 9, {i>root <i}dari{i> image<i} sistem sudah dipasang sebagai {i>root<i} perangkat.
• Antarmuka binder 64-bit. Di Android 8.x, GSI 32-bit menggunakan antarmuka binder 32-bit. Android 9 tidak mendukung antarmuka pengikat 32-bit, sehingga GSI 32-bit dan GSI 64-bit menggunakan antarmuka binder 64-bit.
• Penerapan VNDK. Di Android 8.1, VNDK bersifat opsional. Mulai dari Android 9, VNDK bersifat wajib, jadi BOARD_VNDK_VERSION harus ditetapkan.
• Properti sistem yang kompatibel. Android 9 mengaktifkan pemeriksaan akses untuk properti sistem (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Android 9 Perubahan Keymaster

Di versi Android sebelumnya, perangkat yang mengimplementasikan Keymaster 3 atau lebih rendah adalah diperlukan untuk memverifikasi bahwa info versi (ro.build.version.release dan ro.build.version.security_patch) yang dilaporkan oleh sistem yang sedang berjalan cocok dengan info versi yang dilaporkan oleh bootloader. Informasi tersebut yang biasanya diperoleh dari header image booting.

Di Android 9 dan yang lebih tinggi, persyaratan ini telah diubah untuk mengaktifkan vendor untuk mem-booting GSI. Secara khusus, Keymaster tidak boleh melakukan verifikasi karena info versi yang dilaporkan oleh GSI mungkin tidak cocok dengan info versi yang dilaporkan oleh {i>bootloader<i} vendor. Untuk perangkat yang mengimplementasikan Keymaster 3 atau lebih rendah, vendor harus memodifikasi implementasi Keymaster untuk melewati verifikasi (atau upgrade ke Keymaster 4). Untuk mengetahui detail tentang Keymaster, lihat Keystore yang didukung hardware.

Mendownload GSI

Anda dapat mendownload GSI bawaan dari AOSP continuous integration (CI) situs di ci.android.com. Jika jenis GSI untuk hardware Anda platform tidak tersedia untuk diunduh, lihat bagian berikut untuk detail tentang cara membangun GSI untuk target tertentu.

Mem-build GSI

Mulai Android 9, setiap versi Android memiliki Cabang GSI bernama DESSERT-gsi pada AOSP (misalnya, android12-gsi adalah cabang GSI di Android 12.) Cabang GSI mencakup konten Android dengan semua patch keamanan dan Patch GSI diterapkan.

Untuk mem-build GSI, siapkan hierarki sumber Android dengan mendownload dari cabang GSI dan memilih build GSI target layanan. Gunakan tabel target build di bawah ini untuk menentukan GSI yang tepat untuk perangkat Anda. Setelah build selesai, GSI adalah sistem gambar (yaitu, system.img) dan muncul di folder output out/target/product/generic_arm64.

Misalnya, untuk membangun target build GSI gsi_arm64-userdebug di cabang GSI android12-gsi, jalankan perintah berikut.

$ repo init -u https://android.googlesource.com/platform/manifest -b android12-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch gsi_arm64-userdebug
$ make -j4

Target build GSI Android

Target build GSI berikut adalah untuk perangkat yang diluncurkan di Android 9 atau lebih tinggi.

Persyaratan untuk melakukan flash GSI

Perangkat Android dapat memiliki desain yang berbeda, jadi tidak ada perintah generik atau instruksi untuk melakukan flash GSI ke semua perangkat. Hubungi produsen perangkat Android untuk petunjuk flash yang eksplisit. Gunakan langkah-langkah berikut sebagai panduan umum:

1. Pastikan perangkat memiliki hal berikut:
   • Treblized
   • Metode untuk membuka kunci perangkat (sehingga dapat di-flash menggunakan fastboot)
   • Status tidak terkunci agar dapat di-flash melalui fastboot (Untuk memastikan Anda memiliki fastboot versi terbaru, build dari hierarki sumber Android.)
2. Hapus partisi sistem saat ini, lalu flash GSI ke sistem partisi.
3. Menghapus data pengguna dan menghapus data dari partisi lain yang diperlukan (untuk misalnya, data pengguna dan partisi sistem).
4. Boot ulang perangkat.

Misalnya, untuk melakukan flash GSI ke perangkat Pixel apa pun:

1. Boot ke Mode fastboot dan buka kunci bootloader.
2. Perangkat yang mendukung fastbootd juga harus melakukan booting ke fastbootd dengan:

   $ fastboot reboot fastboot

3. Hapus dan flash GSI ke partisi sistem:

   $ fastboot erase system
   $ fastboot flash system system.img
   

4. Menghapus data pengguna dan menghapus data dari partisi lain yang diperlukan (untuk contoh, data pengguna dan partisi sistem):

   $ fastboot -w

5. Mulai ulang:

   $ fastboot reboot

    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed

$ fastboot delete-logical-partition product_a

Berkontribusi pada GSI

Android menyambut baik kontribusi Anda pada pengembangan GSI. Anda bisa ikut serta serta membantu meningkatkan GSI dengan:

• Membuat patch GSI. DESSERT-gsi bukan cabang pengembangan dan hanya menerima pilihan terbaik dari cabang utama AOSP, jadi untuk mengirimkan patch GSI, Anda harus:
  1. Kirim patch ke AOSP Cabang main.
  2. Pilih patch ke DESSERT-gsi.
  3. Laporkan bug agar produk ceri ditinjau.
• Melaporkan bug GSI atau memberikan saran lain. Tinjau instruksi di Melaporkan bug, lalu cari atau file GSI {i>bugs<i}.

Tips

Mengubah mode menu navigasi menggunakan adb

Saat melakukan booting dengan GSI, mode menu navigasi dikonfigurasi oleh penggantian vendor. Anda dapat ubah mode menu navigasi dengan menjalankan perintah adb berikut dalam runtime.

adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode

Dengan mode dapat berupa threebutton, twobutton, gestural, dan seterusnya.