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) yang tidak dimodifikasi yang dapat dijalankan dengan sukses oleh perangkat Android apa pun yang menjalankan Android 9 atau yang lebih tinggi.
GSI digunakan untuk menjalankan pengujian VTS dan CTS-on-GSI. Image sistem perangkat Android diganti dengan GSI, lalu diuji dengan Vendor Test Suite (VTS) dan Compatibility Test Suite (CTS) untuk memastikan bahwa perangkat mengimplementasikan antarmuka vendor dengan benar menggunakan Android versi terbaru.
Untuk mulai menggunakan GSI, tinjau bagian berikut untuk mengetahui detail tentang konfigurasi GSI (dan variasi yang diizinkan) serta jenis. Saat Anda siap menggunakan GSI, download dan bangun GSI untuk target perangkat Anda, lalu flash GSI ke perangkat Android.
Konfigurasi dan variasi 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 apa pun yang menggunakan antarmuka vendor AIDL/HIDL. (Untuk mengetahui detail selengkapnya, lihat Resource arsitektur.)
- Sistem file. GSI menggunakan sistem file ext4.
GSI Android saat ini mencakup perbedaan utama berikut:
- Arsitektur CPU. Dukungan untuk berbagai instruksi CPU (ARM, x86, dll.) dan bit CPU (32 bit atau 64 bit).
Target GSI untuk pengujian kepatuhan Treble
GSI yang digunakan untuk pengujian kepatuhan ditentukan oleh versi Android yang digunakan perangkat saat diluncurkan.
Jenis perangkat | Membangun target |
---|---|
Perangkat yang diluncurkan dengan Android 15 | gsi_$arch-user (Ditandatangani) |
Perangkat yang diluncurkan dengan Android 14 | gsi_$arch-user (Ditandatangani) |
Perangkat yang diluncurkan dengan Android 13 | gsi_$arch-user (Ditandatangani) |
Perangkat yang diluncurkan dengan Android 12L | gsi_$arch-user (Ditandatangani) |
Perangkat yang diluncurkan dengan Android 12 | gsi_$arch-user (Ditandatangani) |
Perangkat yang diluncurkan dengan Android 11 | gsi_$arch-user (Ditandatangani) |
Semua GSI dibangun dari codebase Android 12, dan setiap arsitektur CPU memiliki biner GSI yang sesuai (lihat daftar target build di Membangun GSI).
Perubahan GSI Android 12
Perangkat yang diluncurkan dengan atau diupdate ke Android 12 harus menggunakan GSI Android 12 untuk pengujian kepatuhan. Hal ini mencakup perubahan besar berikut dari GSI sebelumnya:
- Nama target. Nama target GSI untuk pengujian
kepatuhan diubah menjadi
gsi_$arch
. GSI dengan nama targetaosp_$arch
disimpan untuk developer aplikasi Android. Rencana pengujianCTS-on-GSI
juga dikurangi untuk menguji antarmuka vendor. - GSI lama tidak digunakan lagi. GSI 12 menghapus solusi untuk mengakomodasi perangkat Android 8.0 atau 8.1 yang tidak sepenuhnya Treblized.
- SEPolicy Userdebug. GSI
gsi_$arch
berisiuserdebug_plat_sepolicy.cil
. Saat mem-flashvendor_boot-debug.img
atauboot-debug.img
khusus OEM,/system/bin/init
akan memuatuserdebug_plat_sepolicy.cil
dari GSIsystem.img
. Lihat Pengujian VTS dengan Debug Ramdisk untuk mengetahui detailnya.
Perubahan GSI Android 11
Perangkat yang diluncurkan dengan atau diupdate ke Android 11 harus menggunakan GSI Android 11 untuk pengujian kepatuhan. Hal ini mencakup perubahan besar berikut dari GSI sebelumnya:
- konten system_ext. Android
11 menentukan partisi
system_ext
baru. GSI menempatkan konten ekstensi sistem di foldersystem/system_ext
. - APEX. GSI berisi APEX yang diratakan dan dikompresi.
Yang mana yang akan digunakan ditentukan oleh properti sistem
ro.apex.updatable
di partisi vendor saat runtime. Lihat Mengonfigurasi sistem untuk mendukung update APEX untuk mengetahui detailnya.
Perubahan GSI Android 10
Perangkat yang diluncurkan dengan atau diupdate ke Android 10 harus menggunakan GSI Android 10 untuk pengujian kepatuhan. Hal ini mencakup perubahan besar berikut 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. Lihat Pengujian VTS dengan Debug Ramdisk untuk mengetahui detailnya.
- Format tidak diuraikan. GSI dengan target
aosp_$arch
dibuat dengan format tidak jarang. Anda dapat menggunakanimg2simg
untuk mengonversi GSI yang tidak di-sparse ke format sparse jika diperlukan. - System-as-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-system-as-root, gunakan GSI lamaaosp_$arch_ab
.init
yang diupgrade di ramdisk mendukung OEM system.img dengan tata letak system-as-root. - Verifikasi booting. Dengan GSI, Anda hanya perlu membuka kunci perangkat. Anda tidak perlu menonaktifkan verifikasi booting.
Perubahan GSI Android 9
Perangkat yang diluncurkan dengan atau diupdate ke Android 9 harus menggunakan GSI Android 9 untuk pengujian kepatuhan. Hal ini mencakup perubahan besar berikut dari GSI sebelumnya:
- Menggabungkan GSI dan emulator. GSI dibuat dari image sistem produk emulator, misalnya,
aosp_arm64
danaosp_x86
. - System-as-root. Pada versi Android sebelumnya, perangkat
yang tidak mendukung update A/B dapat memasang image sistem di direktori
/system
. Di Android 9, root image sistem dipasang sebagai root perangkat. - Antarmuka binder 64-bit. Di Android 8.x, GSI 32-bit menggunakan antarmuka binder 32-bit. Android 9 tidak mendukung antarmuka binder 32-bit, sehingga GSI 32-bit dan GSI 64-bit menggunakan antarmuka binder 64-bit.
- Penegakan VNDK. Di Android 8.1, VNDK bersifat opsional.
Mulai dari Android 9, VNDK bersifat wajib, sehingga
BOARD_VNDK_VERSION
harus ditetapkan. - Properti sistem yang kompatibel. Android
9 mengaktifkan pemeriksaan akses untuk properti
sistem yang kompatibel (
PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true
).
Android 9 Perubahan Keymaster
Pada versi Android yang lebih lama, perangkat yang menerapkan Keymaster 3 atau yang lebih rendah
diwajibkan 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 biasanya diperoleh dari header image booting.
Di Android 9 dan yang lebih tinggi, persyaratan ini telah berubah untuk memungkinkan vendor mem-boot GSI. Secara khusus, Keymaster tidak boleh melakukan verifikasi karena info versi yang dilaporkan oleh GSI mungkin tidak cocok dengan info versi yang dilaporkan oleh bootloader vendor. Untuk perangkat yang menerapkan Keymaster 3 atau yang lebih rendah, vendor harus mengubah implementasi Keymaster untuk melewati verifikasi (atau mengupgrade ke Keymaster 4). Untuk mengetahui detail tentang Keymaster, lihat Keystore yang didukung hardware.
Mendownload GSI
Anda dapat mendownload GSI siap pakai dari situs continuous integration (CI) AOSP di ci.android.com. Jika jenis GSI untuk platform hardware Anda tidak tersedia untuk didownload, lihat bagian berikut untuk mengetahui detail tentang cara membuat GSI untuk target tertentu.
Membangun GSI
Mulai Android 9, setiap versi Android memiliki
cabang GSI bernama DESSERT-gsi
di AOSP (misalnya,
android12-gsi
adalah cabang GSI di Android
12). Cabang GSI mencakup konten Android dengan
semua patch keamanan dan
patch GSI yang diterapkan.
Untuk membuat GSI, siapkan hierarki sumber Android dengan
mendownload dari cabang GSI dan
memilih target
build GSI. Gunakan tabel target build di bawah untuk menentukan versi GSI yang tepat untuk perangkat Anda. Setelah build selesai, GSI adalah image
sistem (yaitu, system.img
) dan muncul di folder output
out/target/product/generic_arm64
.
Misalnya, untuk membuat 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 ditujukan untuk perangkat yang diluncurkan di Android 9 atau yang lebih tinggi.
Nama GSI | Arsitektur CPU | Bitness antarmuka Binder | System-as-root | Membangun target |
---|---|---|---|---|
gsi_arm |
ARM | 32 | Y | gsi_arm-user gsi_arm-userdebug |
gsi_arm64 |
ARM64 | 64 | Y | gsi_arm64-user gsi_arm64-userdebug |
gsi_x86 |
x86 | 32 | Y | gsi_x86-user gsi_x86-userdebug |
gsi_x86_64 |
x86-64 | 64 | Y | gsi_x86_64-user gsi_x86_64-userdebug |
Persyaratan untuk melakukan flash GSI
Perangkat Android dapat memiliki desain yang berbeda, sehingga tidak ada perintah atau kumpulan petunjuk umum untuk mem-flash GSI yang dapat diterapkan ke semua perangkat. Hubungi produsen perangkat Android untuk mendapatkan petunjuk flashing yang jelas. Gunakan langkah-langkah berikut sebagai panduan umum:
- Pastikan perangkat memiliki hal berikut:
- Treblized
- Metode untuk membuka kunci perangkat (sehingga perangkat dapat di-flash menggunakan
fastboot
) - Status tidak terkunci agar dapat di-flash melalui
fastboot
(Untuk memastikan Anda memilikifastboot
versi terbaru, bangun dari pohon sumber Android.)
- Hapus partisi sistem saat ini, lalu flash GSI ke partisi sistem.
- Hapus data pengguna dan hapus data dari partisi lain yang diperlukan (misalnya, data pengguna dan partisi sistem).
- Boot ulang perangkat.
Misalnya, untuk mem-flash GSI ke perangkat Pixel:
- Boot ke
mode
fastboot
dan buka kunci bootloader. - Perangkat yang mendukung
fastbootd
juga harus melakukan booting kefastbootd
dengan:$ fastboot reboot fastboot
- Hapus dan flash GSI ke partisi sistem:
$ fastboot erase system $ fastboot flash system system.img
- Jika perangkat Anda mendukung Android Virtual Framework, flash Firmware Virtual Machine yang Dilindungi:
$ fastboot flash pvmfw pvmfw.img
- Hapus data pengguna dan hapus data dari partisi lain yang diperlukan (misalnya, data pengguna dan partisi sistem):
$ fastboot -w
- Mulai ulang kembali ke bootloader:
$ fastboot reboot-bootloader
- Nonaktifkan verifikasi Booting Terverifikasi saat mem-flash vbmeta yang disediakan:
$ fastboot --disable-verification flash vbmeta vbmeta.img
- Reboot:
$ fastboot reboot
Resizing 'system_a' FAILED (remote: 'Not enough space to resize partition') fastboot: error: Command failed
$ fastboot delete-logical-partition product_a
_a
harus cocok dengan ID slot partisi sistem,
seperti system_a
dalam contoh ini.
Berkontribusi pada GSI
Android menyambut kontribusi Anda untuk pengembangan GSI. Anda dapat berpartisipasi dan membantu meningkatkan kualitas GSI dengan:
- Membuat patch GSI.
DESSERT-gsi
bukan cabang pengembangan dan hanya menerima cherrypick dari cabang rilis terbaru AOSP (android16-release
), jadi untuk mengirimkan patch GSI, Anda harus:- Kirim patch ke cabang
AOSP
android16-release
. - Pilih patch ke
DESSERT-gsi
. - Laporkan bug untuk meminta peninjauan cherrypick.
- Kirim patch ke cabang
AOSP
- Melaporkan bug GSI atau memberikan saran lainnya. Tinjau petunjuk di Melaporkan bug, lalu jelajahi atau ajukan bug GSI.
Tips
Mengubah mode menu navigasi menggunakan adb
Saat melakukan booting dengan GSI, mode menu navigasi dikonfigurasi dengan penggantian vendor. Anda dapat mengubah mode panel navigasi dengan menjalankan perintah adb berikut di runtime.
adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode
Dengan mode dapat berupa threebutton
, twobutton
,
gestural
, dan sebagainya.