Gambar sistem bersama

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

Latar belakang

Framework Project Open Source Android (AOSP) mematuhi arsitektur Mainline untuk mempertahankan kompatibilitas mundur dengan implementasi vendor yang lebih lama. Misalnya, Generic System Image (GSI) yang dibangun dari sumber AOSP Android 10 dapat berjalan di perangkat yang kompatibel dengan Treble yang menjalankan Android 8 atau yang lebih tinggi.

Mainline mencapai hal ini dengan membagi Android menjadi dua bagian yang berbeda: implementasi vendor khusus hardware dan framework OS Android generik. Setiap komponen diinstal di partisi terpisah—partisi vendor untuk software khusus hardware dan partisi sistem untuk OS generik. Antarmuka berversi, yang disebut antarmuka vendor (VINTF), diterapkan di antara keduanya. Sistem partisi ini memungkinkan OEM memodifikasi partisi sistem tanpa menyentuh partisi vendor, dan sebaliknya.

Sebelumnya, vendor SoC dan OEM memodifikasi versi framework Android yang dikirimkan di perangkat konsumen secara besar-besaran (untuk mengetahui detailnya, lihat Siklus Proses Rilis Android). Karena ekstensi framework ini jarang didesain dengan mempertimbangkan kompatibilitas mundur, modifikasi khusus perangkat secara dramatis meningkatkan kompleksitas dan biaya finansial upgrade OS berikutnya. Di Android 10 (level API 29) dan yang lebih rendah, ekosistem tidak memiliki arsitektur yang jelas dan standar yang memungkinkan partner membuat ekstensi modular ke framework Android.

Halaman ini menguraikan cara vendor SoC dan OEM dapat membuat image sistem bersama (SSI). SSI adalah image framework terpadu yang dibangun dari sumber Android OS yang dapat digunakan kembali di beberapa perangkat. Dengan mempertahankan kompatibilitas mundur yang bersih dengan penerapan vendor melalui arsitektur yang dipartisi ini, SSI secara signifikan menurunkan biaya dan kompleksitas upgrade OS Android.

Untuk mengetahui detail penerapan, lihat Langkah-langkah yang disarankan untuk SSI berbasis GSI. Langkah-langkahnya bersifat modular; bergantung pada arsitektur Anda, Anda dapat memilih untuk menerapkan tahap tertentu (seperti Langkah 1: Mewarisi generic_system.mk untuk image sistem OEM (GSI OEM)) daripada semua tahap.

Ringkasan SSI

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

OEM dan vendor SoC dapat membuat SSI yang menyertakan fitur dan modifikasi kustom. Mekanisme dan praktik terbaik yang disediakan di halaman ini ditujukan untuk digunakan OEM dalam mencapai sasaran utama berikut:

• Gunakan kembali SSI di beberapa SKU perangkat.
• Update sistem Android dengan ekstensi modular untuk membuat upgrade OS lebih mudah.

Ide inti untuk memisahkan komponen khusus produk ke dalam partisi produk mirip dengan Mainline yang memisahkan komponen khusus SoC ke dalam partisi vendor. Antarmuka produk (mirip dengan VINTF) memungkinkan komunikasi antara SSI dan partisi produk. Sehubungan dengan SSI, istilah komponen menjelaskan semua resource, biner, teks, dan library yang diinstal ke image, yang 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 image dan partisi.

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

Bagian dalam Gambar 1 didefinisikan sebagai berikut:

• SSI: Gambar yang umum untuk OEM, dan yang dapat ada di beberapa perangkat. Tidak memiliki komponen khusus hardware atau khusus produk. Semua yang ada dalam 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.

• Gambar produk: Kumpulan komponen khusus produk atau perangkat yang merepresentasikan penyesuaian dan ekstensi OEM pada Android OS. Tempatkan komponen khusus SoC di partisi /vendor. Vendor SoC juga dapat menggunakan partisi /product untuk komponen yang sesuai, seperti komponen yang tidak bergantung pada 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 ditentukan oleh tujuannya, bukan kepemilikannya.

• Gambar vendor: Kumpulan komponen khusus SoC.

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

Partisi /system_ext

Partisi /system_ext bersifat opsional. Gunakan partisi ini untuk fitur dan ekstensi kustom apa pun yang terintegrasi erat dengan komponen berbasis AOSP. Partisi ini 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. Di perangkat yang tidak memiliki partisi /system_ext, instal modul tersebut ke subdirektori ./system_ext di partisi /system.

Histori: Tujuan desain awal partisi /system_ext adalah untuk menempatkan semua komponen khusus OEM, terlepas dari apakah komponen tersebut umum, di partisi /product. Namun, memindahkan semuanya sekaligus tidak memungkinkan, terutama saat beberapa komponen memiliki keterikatan yang kuat dengan partisi /system. Untuk memindahkan komponen yang terikat kuat 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 sementara menghosting komponen yang belum siap dipindahkan ke partisi /product. Tujuan SSI adalah untuk akhirnya menghilangkan partisi /system_ext.

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 dibuat dari sumber yang semirip mungkin dengan yang ada di AOSP, Anda dapat memfokuskan upaya upgrade pada image system_ext.

Antarmuka antar-gambar

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

• Vendor Interface (VINTF): VINTF adalah antarmuka untuk komponen yang berada 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 sebaliknya. Hal ini didefinisikan dalam arsitektur Treble (sekarang menjadi bagian dari arsitektur Mainline yang lebih luas), yang membagi image menjadi partisi sistem dan vendor. Antarmuka dijelaskan menggunakan mekanisme berikut:

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

• Antarmuka produk: Antarmuka produk adalah antarmuka antara SSI dan gambar produk. Menentukan antarmuka yang stabil akan memisahkan komponen produk dari komponen sistem dalam SSI.

Mengaktifkan SSI

Bagian ini menjelaskan cara mendukung SSI di Android 11 dan yang lebih tinggi.

Membatalkan penggabungan komponen

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

• Antarmuka bawaan: Modul bawaan di partisi /product harus dipisahkan 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 SDK Java untuk API kustom.

Menerapkan antarmuka produk

Untuk memastikan partisi /product tidak digabungkan, OEM dapat membuat perangkat mereka menerapkan antarmuka produk dengan menyetel PRODUCT_PRODUCT_VNDK_VERSION:= current untuk modul bawaan, dan PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true untuk modul Java. Variabel ini disetel secara otomatis jika PRODUCT_SHIPPING_API_LEVEL perangkat lebih besar dari atau sama dengan 30. Untuk mengetahui informasi mendetail, lihat Menerapkan antarmuka partisi produk.

Langkah-langkah yang disarankan untuk SSI berbasis GSI

Gambar 2. Partisi yang disarankan untuk SSI berbasis GSI.

Image sistem generik (GSI) adalah image sistem yang dibangun langsung dari AOSP. Image ini digunakan untuk pengujian kepatuhan (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 Gambar 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 gambar system, OEM dapat berfokus pada gambar system_ext untuk upgrade.

Bagian ini memberikan panduan kepada OEM yang ingin memodularisasi penyesuaian mereka ke dalam partisi /system_ext dan /product saat menggunakan image sistem AOSP atau yang mirip 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 (GSI OEM)

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 (OEM GSI) menyertakan semua file yang dimiliki GSI AOSP. File ini dapat diubah oleh OEM, sehingga GSI OEM dapat berisi file eksklusif OEM selain file GSI AOSP.

Gambar 3. Mewarisi generic_system.mk untuk image sistem OEM.

Langkah 2: Pastikan GSI OEM memiliki daftar file yang sama dengan GSI AOSP

GSI OEM tidak boleh memiliki file tambahan pada tahap ini, jadi pindahkan file milik OEM ke partisi system_ext atau product.

Gambar 4. Pindahkan file yang ditambahkan dari GSI OEM.

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

Untuk memeriksa file yang diubah, OEM dapat menggunakan alat compare_images, dan membandingkan GSI AOSP dengan GSI OEM. Dapatkan GSI AOSP dari target lunch 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 modifikasi tambahan pada GSI OEM.

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

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 perubahannya di GSI OEM, atau mengirimkan perubahannya ke AOSP agar GSI AOSP menyertakan perubahannya.

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

Menentukan SSI

OEM dapat menggunakan panduan berikut untuk menentukan SSI mereka.

Melindungi partisi /system saat 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 di Langkah 1: Buat 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 GSI OEM umum untuk semua produk OEM. Proses ini adalah untuk menentukan GSI OEM dan dapat terpisah dari langkah-langkah untuk GSI AOSP.

Membuat partisi /system_ext umum

Partisi /system_ext mungkin berbeda di antara perangkat, karena dapat memiliki modul yang disertakan sistem dan khusus perangkat. Karena SSI terdiri dari partisi /system dan /system_ext, perbedaan pada partisi /system_ext menghalangi OEM untuk menentukan SSI. OEM dapat memiliki SSI sendiri dan dapat membagikan SSI tersebut di antara beberapa perangkat dengan menghapus 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 spesifik per 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 disukai 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. Library ini 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.

Mengganti penonaktifan aplikasi khusus SKU

Android 16 menghentikan penggunaan dan menghapus mekanisme lama untuk menonaktifkan APK secara selektif berdasarkan SKU hardware menggunakan overlay resource framework (config_disableApksUnlessMatchedSku_apk_list dan config_disableApkUnlessMatchedSku_skus_list). Untuk mengetahui detailnya, lihat aosp/3444399.

Penggantian yang direkomendasikan adalah menggunakan konfigurasi sistem install-in-user-type dalam direktori khusus SKU. Pendekatan ini mencegah paket diinstal untuk pengguna mana pun di SKU tertentu, bukan hanya menonaktifkannya setelah penginstalan.

1. Sertakan semua APK (superkumpulan semua aplikasi potensial untuk semua SKU dalam image sistem Anda) dalam image, biasanya di partisi /product.

2. Pastikan SKU perangkat disetel dengan benar di properti sistem ro.boot.hardware.sku (digunakan oleh sistem untuk mengidentifikasi SKU perangkat saat waktu booting).

3. Buat subdirektori sysconfig khusus SKU di bagian /product/etc/sysconfig/ menggunakan konvensi penamaan sku_<SKU_NAME>. Sistem akan otomatis memuat konfigurasi dari direktori yang cocok dengan properti ro.boot.hardware.sku. Contoh jalur: /product/etc/sysconfig/sku_basic_model/.

4. Mengonfigurasi pencegahan penginstalan aplikasi. Di dalam direktori khusus SKU, buat file konfigurasi XML (misalnya, disabled_apps.xml) dan gunakan tag <do-not-install-in> untuk mengecualikan paket tertentu.

Contoh XML (/product/etc/sysconfig/sku_basic_model/disabled_apps.xml):

<?xml version="1.0" encoding="utf-8"?>
<config>
    <!-- Prevents this package from being installed for ANY user on this SKU -->
    <install-in-user-type package="com.example.premium.feature.app" >
        <do-not-install-in user-type="FULL" />
        <do-not-install-in user-type="SYSTEM" />
    </install-in-user-type>
</config>

Berikut perbandingan kedua metode tersebut:

Untuk kasus yang memerlukan kontrol yang lebih terperinci (yaitu, menonaktifkan aplikasi yang biasanya diinstal secara default di semua SKU), Android juga mendukung tag disabled-in-sku dan enabled-in-sku-override di sysconfig:

• <disabled-in-sku package="com.example.app" /> menonaktifkan aplikasi secara global.

• <enabled-in-sku-override package="com.example.app" /> mengaktifkan kembali aplikasi untuk SKU tertentu saat ditempatkan di direktori sku_<name> yang sesuai.

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 Mengubah nilai resource aplikasi saat runtime. OEM juga dapat menentukan RRO bersyarat yang bergantung pada properti sistem dengan menggunakan atribut android:requiredSystemPropertyName dan android:requiredSystemPropertyValue.

Pertanyaan umum (FAQ)

Berikut adalah pertanyaan umum (FAQ) tentang SSI.

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