Image sistem bersama Android

Halaman ini menyajikan beberapa mekanisme yang dapat digunakan OEM perangkat Android untuk memiliki image sistem bersama (SSI) mereka sendiri di seluruh lini produk. Dokumen ini juga mengusulkan prosedur untuk mendasarkan SSI milik OEM pada Generic System Image (GSI) yang di-build AOSP.

Latar belakang

Dengan Project Treble, Android monolitik dibagi menjadi dua bagian: bagian khusus hardware (implementasi vendor) dan bagian OS generik (framework Android OS). Software untuk masing-masing diinstal di partisi terpisah: partisi vendor untuk software khusus hardware, dan partisi sistem untuk software OS generik. Antarmuka berversi, yang disebut antarmuka vendor (VINTF), ditentukan dan diterapkan di kedua partisi. Dengan menggunakan sistem partisi ini, Anda dapat mengubah partisi sistem tanpa mengubah partisi vendor, dan sebaliknya.

Motivasi

Kode framework yang dirilis di AOSP telah mematuhi arsitektur Treble dan mempertahankan kompatibilitas mundur dengan implementasi vendor lama. Misalnya, image sistem generik yang dibuat dari sumber AOSP Android 10 dapat berjalan di perangkat yang mematuhi Treble yang berjalan di Android 8 atau yang lebih tinggi. Versi Android yang dikirimkan di perangkat konsumen dimodifikasi oleh vendor SoC dan OEM. (Lihat Siklus Proses Rilis Android.) Perubahan dan ekstensi yang dilakukan pada framework ini tidak ditulis untuk mempertahankan kompatibilitas mundur, yang menyebabkan peningkatan kompleksitas dan biaya yang lebih tinggi dalam upgrade OS. Perubahan dan modifikasi khusus perangkat menambah biaya dan kerumitan upgrade versi OS Android.

Sebelum Android 11, tidak ada arsitektur yang jelas yang memungkinkan partner membuat ekstensi modular ke framework Android OS. Dokumen ini menjelaskan langkah-langkah yang dapat dilakukan vendor SoC dan OEM untuk membuat SSI. Artinya, satu image, yang dibuat dari sumber framework Android OS untuk digunakan kembali di beberapa perangkat, untuk mempertahankan kompatibilitas mundur dengan implementasi vendor, dan untuk memberikan pengurangan yang signifikan dalam kompleksitas dan biaya upgrade Android OS. Untuk mengetahui langkah-langkah spesifik yang perlu Anda lakukan untuk membuat SSI, lihat bagian Langkah-langkah yang disarankan untuk SSI berbasis GSI, dan perhatikan bahwa Anda tidak harus menggunakan keempat langkah tersebut. Langkah yang Anda pilih (misalnya, hanya Langkah 1) bergantung pada penerapan Anda.

Ringkasan SSI

Dengan SSI, komponen software khusus produk dan ekstensi OEM ditempatkan di partisi /product baru. Komponen dalam partisi /product menggunakan antarmuka yang stabil dan terdefinisi dengan baik untuk berinteraksi dengan komponen dalam partisi /system. OEM dapat memilih untuk membuat satu SSI, atau memiliki sejumlah kecil SSI untuk digunakan di beberapa SKU perangkat. Saat versi baru OS Android dirilis, OEM hanya berinvestasi sekali dalam mengupdate SSI mereka ke rilis Android terbaru. Mereka dapat menggunakan kembali SSI untuk mengupdate beberapa perangkat tanpa mengupdate partisi /product.

Perhatikan bahwa OEM dan vendor SoC membuat SSI yang mencakup semua fitur dan modifikasi kustom yang dibutuhkan OEM. Mekanisme dan praktik terbaik yang disediakan di halaman ini ditujukan untuk digunakan OEM dalam mencapai tujuan utama berikut:

• Gunakan kembali SSI di beberapa SKU perangkat.
• Perbarui sistem Android dengan ekstensi modular untuk mempermudah upgrade OS.

Ide inti untuk memisahkan komponen khusus produk ke dalam partisi produk mirip dengan ide Treble untuk memisahkan komponen khusus SoC ke dalam partisi vendor. Antarmuka produk (mirip dengan VINTF) memungkinkan komunikasi antara SSI dan partisi produk. Perhatikan bahwa terkait SSI, istilah “komponen” menjelaskan semua resource, biner, teks, library, dan sebagainya yang diinstal ke image, yang pada dasarnya menjadi partisi.

Partisi di sekitar SSI

Gambar 1 menunjukkan partisi di sekitar SSI, dan antarmuka yang diberi versi di seluruh partisi dan kebijakan pada antarmuka. Bagian ini menjelaskan setiap partisi dan antarmuka secara mendetail.

Gambar 1. Partisi dan antarmuka di sekitar SSI

Gambar dan partisi

Informasi di bagian ini membedakan istilah gambar dan partisi.

• Image adalah bagian software konseptual yang dapat diupdate secara independen.
• Partisi adalah lokasi penyimpanan fisik yang dapat diperbarui secara independen.

Bagian dalam Gambar 1 didefinisikan sebagai berikut:

• SSI: SSI adalah image yang umum untuk OEM, dan dapat ada di beberapa perangkat. Tidak memiliki komponen khusus hardware atau khusus produk. Semua yang ada di SSI tertentu, menurut definisi, dibagikan di antara semua perangkat yang menggunakan SSI tersebut. SSI terdiri dari satu gambar /system, atau partisi /system dan /system_ext, seperti yang terlihat pada Gambar 1.

  • Partisi /system berisi komponen berbasis AOSP, sedangkan /system_ext, jika diterapkan, berisi ekstensi dan komponen OEM dan vendor SoC yang terintegrasi erat dengan komponen AOSP. Misalnya, library framework Java OEM yang menyediakan API kustom untuk aplikasi OEM sendiri lebih cocok di /system_ext daripada di partisi /system. Konten untuk partisi /system dan /system_ext dibangun dari sumber Android yang dimodifikasi OEM.

  • Partisi /system_ext bersifat opsional, tetapi sebaiknya gunakan partisi ini untuk fitur dan ekstensi kustom apa pun yang terintegrasi erat dengan komponen berbasis AOSP. Perbedaan ini membantu Anda mengidentifikasi perubahan yang perlu dilakukan, untuk memindahkan komponen tersebut dari partisi /system_ext ke partisi /product selama jangka waktu tertentu.

• Produk: Kumpulan komponen khusus produk atau perangkat yang merepresentasikan penyesuaian dan ekstensi OEM pada OS Android. Tempatkan komponen khusus SoC di partisi /vendor. Vendor SoC juga dapat menggunakan partisi /product untuk komponen yang sesuai, seperti komponen yang independen dari SoC. Misalnya, jika vendor SoC menyediakan komponen independen SoC kepada pelanggan OEM mereka (yang bersifat opsional untuk dikirimkan bersama produk), vendor SoC dapat menempatkan komponen tersebut dalam gambar produk. Lokasi komponen tidak ditentukan oleh kepemilikannya, tetapi ditentukan oleh tujuannya.

• Vendor: Kumpulan komponen khusus SoC.

• ODM: Kumpulan komponen khusus papan yang tidak disediakan oleh SoC. Biasanya, vendor SoC memiliki image vendor, sedangkan pembuat perangkat memiliki image ODM. Jika tidak ada partisi /odm terpisah, gambar vendor SoC dan ODM digabungkan dalam partisi /vendor.

Antarmuka antar-gambar

Ada dua antarmuka utama untuk gambar vendor dan produk di sekitar SSI:

• Antarmuka Vendor (VINTF): VINTF adalah antarmuka ke komponen yang ada di vendor dan image ODM. Komponen dalam gambar produk dan sistem hanya dapat berinteraksi dengan gambar vendor dan ODM melalui antarmuka ini. Misalnya, image vendor tidak dapat bergantung pada bagian pribadi dari image sistem, dan begitu pun sebaliknya. Ini awalnya ditentukan dalam Project Treble, yang membagi image menjadi partisi sistem dan vendor. Antarmuka dijelaskan menggunakan mekanisme berikut:

  • HIDL (HAL passthrough hanya tersedia untuk modul system dan system_ext)
  • AIDL Stabil
  • Konfigurasi
    • API properti sistem
    • API skema file konfigurasi
  • VNDK
  • API Android SDK
  • Library SDK Java

• Antarmuka produk: Antarmuka produk adalah antarmuka antara SSI dan gambar produk. Menentukan antarmuka yang stabil akan memisahkan komponen produk dari komponen sistem dalam SSI. Antarmuka produk memerlukan antarmuka stabil yang sama dengan VINTF. Namun, hanya API VNDK dan Android SDK yang diterapkan untuk perangkat yang diluncurkan dengan Android 11 (dan yang lebih tinggi).

Mengaktifkan SSI di Android 11

Bagian ini menjelaskan cara menggunakan fitur baru yang ada untuk mendukung SSI di Android 11.

Partisi /system_ext

Partisi /system_ext diperkenalkan di Android 11 sebagai partisi opsional. (Ini adalah tempat untuk komponen non-AOSP yang memiliki coupling erat dengan komponen yang ditentukan AOSP di partisi /system.) Partisi /system_ext dianggap sebagai ekstensi khusus OEM untuk partisi /system, tanpa antarmuka yang ditentukan di kedua partisi. Komponen di partisi /system_ext dapat melakukan panggilan API pribadi ke partisi /system, dan komponen di partisi /system dapat melakukan panggilan API pribadi ke partisi /system_ext.

Karena kedua partisi terhubung erat, kedua partisi diupgrade bersamaan saat versi Android baru dirilis. Partisi /system_ext yang dibuat untuk rilis Android sebelumnya tidak perlu kompatibel dengan partisi /system di rilis Android berikutnya.

Untuk menginstal modul ke partisi /system_ext, tambahkan system_ext_specific: true ke file Android.bp. Untuk perangkat yang tidak memiliki partisi /system_ext, instal modul tersebut ke subdirektori ./system_ext di partisi /system.

Histori

Berikut adalah beberapa histori tentang partisi /system_ext. Tujuan desainnya adalah menempatkan semua komponen khusus OEM, terlepas dari apakah komponen tersebut umum atau tidak, di partisi /product. Namun, memindahkan semuanya sekaligus tidak memungkinkan, terutama saat beberapa komponen memiliki keterikatan yang kuat dengan partisi /system. Untuk memindahkan komponen yang terhubung erat ke partisi /product, antarmuka produk harus diperluas. Hal ini sering kali mengharuskan komponen itu sendiri di-refactor secara ekstensif, yang menghabiskan banyak waktu dan tenaga. Partisi /system_ext dimulai sebagai tempat untuk menghosting sementara komponen yang belum siap dipindahkan ke partisi /product. Tujuan SSI adalah untuk menghapus partisi /system_ext pada akhirnya.

Namun, partisi /system_ext berguna untuk menjaga partisi /system sedekat mungkin dengan AOSP. Dengan SSI, sebagian besar upaya upgrade dilakukan pada komponen di partisi /system dan /system_ext. Jika image sistem dibangun dari sumber yang semirip mungkin dengan yang ada di AOSP, Anda dapat memfokuskan upaya upgrade pada image system_ext.

Membatalkan penggabungan komponen dari partisi /system dan /system_ext ke dalam partisi /product

Android 9 memperkenalkan partisi /product yang digabungkan dengan partisi /system. Modul di partisi /product menggunakan resource sistem tanpa batasan apa pun, dan sebaliknya. Untuk memungkinkan SSI di Android 10, komponen produk dibagi menjadi partisi /system_ext dan /product. Partisi /system_ext tidak harus mematuhi batasan penggunaan komponen sistem yang /product lakukan di Android 9. Mulai Android 10, partisi /product harus dipisahkan dari partisi /system dan harus menggunakan antarmuka stabil dari partisi /system dan /system_ext.

Tujuan utama partisi /system_ext adalah untuk memperluas fitur sistem, bukan untuk menginstal modul produk yang di-bundle, seperti yang dijelaskan di bagian /system_ext partition. Untuk melakukannya, pisahkan modul khusus produk dan pindahkan ke partisi /product. Memisahkan modul khusus produk membuat /system_ext umum untuk perangkat. (Untuk mengetahui detail selengkapnya, lihat Membuat partisi /system_ext umum.)

Untuk memisahkan partisi /product dari komponen sistem, partisi /product harus memiliki kebijakan penegakan yang sama dengan partisi /vendor yang sudah dipisahkan dengan Project Treble.

Mulai Android 11, antarmuka native dan Java untuk partisi /product diterapkan seperti yang dijelaskan di bawah. Untuk mengetahui informasi selengkapnya, lihat Menerapkan Antarmuka Partisi Produk.

• Antarmuka native: Modul native di partisi /product harus dilepaskan dari partisi lainnya. Satu-satunya dependensi yang diizinkan dari modul produk adalah beberapa library VNDK (termasuk LLNDK) dari partisi /system. Library JNI yang diandalkan oleh aplikasi produk harus berupa library NDK.
• Antarmuka Java: Modul Java (aplikasi) di partisi /product tidak dapat menggunakan API tersembunyi karena tidak stabil. Modul ini hanya boleh menggunakan API publik dan API sistem dari partisi /system, serta library Java SDK di partisi /system atau /system_ext. Anda dapat menentukan library Java SDK untuk API kustom.

Langkah-langkah yang disarankan untuk SSI berbasis GSI

Gambar 2. Partisi yang disarankan untuk SSI berbasis GSI

Generic System Image (GSI) adalah image sistem yang dibangun langsung dari AOSP. GSI digunakan untuk pengujian kepatuhan Treble (misalnya, CTS-on-GSI) dan sebagai platform referensi yang dapat digunakan oleh developer aplikasi untuk menguji kompatibilitas aplikasi mereka saat mereka tidak memiliki perangkat sebenarnya yang menjalankan Android versi yang diperlukan.

OEM juga dapat menggunakan GSI untuk membuat SSI mereka. Seperti yang dijelaskan dalam Image dan partisi, SSI terdiri dari image sistem untuk komponen yang ditentukan AOSP dan image system_ext untuk komponen yang ditentukan OEM. Jika GSI digunakan sebagai image system, OEM dapat berfokus pada image system_ext untuk upgrade.

Bagian ini memberikan panduan bagi OEM yang ingin memodularisasi penyesuaian mereka ke dalam partisi /system_ext dan /product saat menggunakan image sistem AOSP atau hampir AOSP. Jika OEM membangun image sistem dari sumber AOSP, mereka dapat mengganti image sistem yang mereka bangun dengan GSI yang disediakan oleh AOSP. Namun, OEM tidak perlu mencapai langkah terakhir (menggunakan GSI apa adanya) sekaligus.

Langkah 1. Mewarisi generic_system.mk untuk image sistem OEM (OEM GSI)

Dengan mewarisi generic_system.mk (yang diberi nama mainline_system.mk di Android 11, dan diganti namanya menjadi generic_system.mk di AOSP), image sistem (GSI OEM) mencakup semua file yang dimiliki GSI AOSP. File ini dapat dimodifikasi oleh OEM, sehingga GSI OEM dapat berisi file eksklusif OEM selain file GSI AOSP. Namun, OEM tidak diizinkan untuk mengubah file generic_system.mk itu sendiri.

Gambar 3. Mewarisi generic_system.mk untuk image sistem OEM

Langkah 2. Memastikan GSI OEM memiliki daftar file yang sama dengan GSI AOSP

GSI OEM tidak dapat memiliki file tambahan pada tahap ini. File eksklusif OEM harus dipindahkan ke partisi system_ext atau product.

Gambar 4. Memindahkan file yang ditambahkan dari GSI OEM

Langkah 3. Tentukan daftar yang diizinkan untuk membatasi file yang diubah di OEM GSI

Untuk memeriksa file yang diubah, OEM dapat menggunakan alat compare_images dan membandingkan GSI AOSP dengan GSI OEM. Dapatkan GSI AOSP dari target peluncuran AOSP generic_system_*.

Dengan menjalankan alat compare_images secara berkala dengan parameter allowlist, Anda dapat memantau perbedaan di luar daftar yang diizinkan. Hal ini mencegah diperlukannya modifikasi tambahan pada GSI OEM.

Gambar 5. Menentukan daftar yang diizinkan untuk mengurangi daftar file yang diubah di OEM GSI

Langkah 4. Pastikan GSI OEM memiliki biner yang sama dengan GSI AOSP

Membersihkan daftar yang diizinkan memungkinkan OEM menggunakan GSI AOSP sebagai image sistem untuk produk mereka sendiri. Untuk membersihkan daftar yang diizinkan, OEM dapat membatalkan perubahan di GSI OEM, atau mengirimkan perubahan ke AOSP agar GSI AOSP menyertakan perubahan tersebut.

Gambar 6. Membuat GSI OEM memiliki biner yang sama dengan GSI AOSP

Menentukan SSI untuk OEM

Melindungi partisi /system pada waktu build

Untuk menghindari perubahan khusus produk di partisi /system dan menentukan GSI OEM, OEM dapat menggunakan makro makefile yang disebut require-artifacts-in-path untuk mencegah deklarasi modul sistem setelah makro dipanggil. Lihat contoh Create makefile dan aktifkan pemeriksaan jalur artefak.

OEM dapat menentukan daftar untuk mengizinkan modul khusus produk diinstal di partisi /system untuk sementara. Namun, daftar harus kosong agar OEM GSI umum untuk semua produk OEM. Proses ini adalah untuk menentukan OEM GSI dan dapat terpisah dari langkah-langkah untuk AOSP GSI.

Menerapkan antarmuka produk

Untuk menjamin partisi /product tidak digabungkan, OEM dapat memastikan perangkat mereka menerapkan antarmuka produk dengan menyetel PRODUCT_PRODUCT_VNDK_VERSION:= current untuk modul native, dan PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true untuk modul Java. Variabel ini otomatis ditetapkan jika PRODUCT_SHIPPING_API_LEVEL perangkat lebih besar dari atau sama dengan 30. Untuk informasi mendetail, lihat Menerapkan Antarmuka Partisi Produk.

Menjadikan partisi /system_ext umum

Partisi /system_ext mungkin berbeda di antara perangkat, karena dapat memiliki modul spesifik per perangkat yang dibundel sistem. Karena SSI terdiri dari partisi /system dan /system_ext, perbedaan dalam partisi /system_ext menghalangi OEM untuk menentukan SSI. OEM dapat memiliki SSI sendiri dan dapat membagikan SSI tersebut di beberapa perangkat dengan menghilangkan perbedaan dan membuat partisi /system_ext menjadi umum.

Bagian ini memberikan rekomendasi untuk membuat partisi /system_ext menjadi umum.

Mengekspos API tersembunyi di partisi sistem

Banyak aplikasi khusus produk tidak dapat diinstal di partisi produk karena menggunakan API tersembunyi, yang dilarang di partisi produk. Untuk memindahkan aplikasi khusus perangkat ke partisi produk, hapus penggunaan API tersembunyi.

Cara yang lebih disarankan untuk menghapus API tersembunyi dari aplikasi adalah dengan menemukan API publik atau sistem alternatif untuk menggantikannya. Jika tidak ada API untuk menggantikan API tersembunyi, OEM dapat berkontribusi ke AOSP untuk menentukan API sistem baru bagi perangkat mereka.

Atau, OEM dapat menentukan API kustom dengan membuat library Java SDK sendiri di partisi /system_ext. Dapat menggunakan API tersembunyi di partisi sistem, dan dapat menyediakan API ke aplikasi di partisi produk atau vendor. OEM harus membekukan API yang menghadap produk untuk kompatibilitas mundur.

Menyertakan superset semua APK dan melewati beberapa penginstalan paket untuk setiap perangkat

Paket tertentu yang dibundel dengan sistem tidak umum di seluruh perangkat. Membatalkan penggabungan modul APK ini untuk memindahkannya ke produk atau partisi vendor bisa jadi sulit. Sebagai solusi sementara, OEM dapat membuat SSI menyertakan semua modul, lalu memfilter modul yang tidak diinginkan menggunakan properti SKU (ro.boot.hardware.sku). Untuk menggunakan filter, OEM menempatkan resource framework config_disableApkUnlessMatchedSku_skus_list dan config_disableApksUnlessMatchedSku_apk_list.

Untuk setelan yang lebih presisi, deklarasikan penerima siaran yang menonaktifkan paket yang tidak diperlukan. Penerima siaran memanggil setApplicationEnabledSetting untuk menonaktifkan paket saat menerima pesan ACTION_BOOT_COMPLETED.

Menentukan RRO, bukan menggunakan overlay resource statis

Overlay resource statis memanipulasi paket yang di-overlay. Namun, hal ini dapat menghambat penentuan SSI, jadi pastikan properti untuk RRO diaktifkan dan disetel dengan benar. Dengan menetapkan properti sebagai berikut, OEM dapat memiliki semua overlay yang dibuat secara otomatis sebagai RRO.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

Jika konfigurasi mendetail diperlukan, tentukan RRO secara manual, bukan mengandalkan RRO yang dibuat secara otomatis. Untuk mengetahui informasi mendetail, lihat Overlay Resource Runtime (RRO). OEM juga dapat menentukan RRO bersyarat yang bergantung pada properti sistem dengan menggunakan atribut android:requiredSystemPropertyName dan android:requiredSystemPropertyValue.

Pertanyaan umum (FAQ)

Dapatkah saya menentukan beberapa SSI?

Hal ini bergantung pada kesamaan dan karakteristik perangkat (atau grup perangkat). OEM dapat mencoba membuat partisi system_ext umum, seperti yang dijelaskan dalam Membuat partisi system_ext umum. Jika grup perangkat memiliki banyak perbedaan, sebaiknya tentukan beberapa SSI.

Dapatkah saya mengubah generic_system.mk (mainline_system.mk) untuk GSI OEM?

Tidak. Namun, OEM dapat menentukan makefile baru untuk GSI OEM yang mewarisi file generic_system.mk dan menggunakan makefile baru tersebut. Sebagai contoh, lihat Menerapkan Antarmuka Partisi Produk.

Dapatkah saya menghapus modul dari generic_system.mk yang bertentangan dengan penerapan saya?

Tidak. GSI memiliki serangkaian modul minimum yang dapat di-boot dan diuji. Jika Anda merasa modul tidak penting, ajukan bug untuk memperbarui file generic_system.mk di AOSP.