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 image sistem generik (GSI) yang dibuat AOSP.

Latar belakang

Dengan Project Treble, Android monolitik dibagi menjadi dua bagian: bagian khusus hardware (implementasi vendor) dan bagian OS umum (framework Android OS). Software untuk masing-masing diinstal di partisi terpisah: partisi vendor untuk software khusus hardware, dan partisi sistem untuk software OS umum. 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 telah 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 dan berjalan di Android 8 atau yang lebih baru. Versi Android yang dikirimkan di perangkat konsumen dimodifikasi oleh vendor SoC dan OEM. (Lihat Masa Aktif Rilis Android.) Perubahan dan ekstensi yang dibuat pada framework ini tidak ditulis untuk mempertahankan kompatibilitas mundur, yang berarti peningkatan kompleksitas dan biaya yang lebih tinggi dalam upgrade OS. Perubahan dan modifikasi khusus perangkat menambah biaya dan kompleksitas upgrade versi Android OS.

Sebelum Android 11, tidak ada arsitektur yang jelas yang memungkinkan partner mem-build ekstensi modular ke framework Android OS. Dokumen ini menjelaskan langkah-langkah yang dapat dilakukan vendor SoC dan OEM untuk membuat SSI. Ini berarti satu image, yang dibangun 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 tertentu yang diperlukan guna 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 ditentukan 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 Android OS dirilis, OEM hanya perlu berinvestasi sekali untuk 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 mem-build SSI yang menyertakan semua fitur dan modifikasi kustom yang diperlukan OEM. Mekanisme dan praktik terbaik yang diberikan di halaman ini ditujukan untuk digunakan OEM guna mencapai tujuan utama berikut:

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

Ide inti untuk memisahkan komponen khusus produk ke dalam partisi produk mirip dengan ide Treble dalam memisahkan komponen khusus SoC ke dalam partisi vendor. Antarmuka produk (mirip dengan VINTF) memungkinkan komunikasi antara SSI dan partisi produk. Perhatikan bahwa sehubungan dengan 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 berversi di seluruh partisi dan kebijakan di 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 antara istilah image 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 ditentukan sebagai berikut:

• SSI: SSI adalah gambar yang bersifat umum bagi OEM, dan dapat ada di beberapa perangkat. Aplikasi ini tidak memiliki komponen khusus hardware atau komponen khusus produk. Secara definisi, semua yang ada dalam SSI tertentu 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 diimplementasikan, berisi ekstensi serta komponen vendor OEM dan SoC yang dikaitkan erat dengan komponen AOSP. Misalnya, library framework Java OEM yang menyediakan API kustom untuk aplikasi OEM sendiri lebih cocok di partisi /system_ext daripada di partisi /system. Konten untuk partisi /system dan /system_ext dibuat dari sumber Android yang dimodifikasi oleh OEM.

  • Partisi /system_ext bersifat opsional, tetapi sebaiknya gunakan partisi ini untuk fitur dan ekstensi kustom yang terikat 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 mewakili penyesuaian dan ekstensi OEM ke Android OS. Masukkan 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 opsional untuk dikirim 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 board 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 akan digabungkan dalam partisi /vendor.

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. Ini awalnya ditentukan dalam Project Treble, yang membagi image ke dalam 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
  • Android SDK API
  • 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. Antarmuka produk memerlukan antarmuka stabil yang sama dengan VINTF. Namun, hanya VNDK dan Android SDK API 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 diterapkan 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 pengaitan yang erat dengan komponen yang ditentukan AOSP di partisi /system.) Partisi /system_ext diasumsikan sebagai ekstensi khusus OEM untuk partisi /system, tanpa antarmuka yang ditentukan di kedua partisi. Komponen dalam partisi /system_ext dapat melakukan panggilan API pribadi ke dalam partisi /system, dan komponen dalam partisi /system dapat melakukan panggilan API pribadi ke dalam partisi /system_ext.

Karena kedua partisi terkait erat, kedua partisi diupgrade bersama-sama saat versi Android baru dirilis. Partisi /system_ext yang dibuat untuk rilis Android sebelumnya tidak perlu kompatibel dengan partisi /system dalam 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 beberapa histori tentang partisi /system_ext. Sasaran desainnya adalah menempatkan semua komponen khusus OEM, terlepas dari apakah komponen tersebut umum, di partisi /product. Namun, memindahkan semuanya sekaligus tidak memungkinkan, terutama jika beberapa komponen memiliki pengaitan yang erat dengan partisi /system. Untuk memindahkan komponen yang terkait erat ke partisi /product, antarmuka produk harus diperluas. Hal ini sering kali mengharuskan komponen itu sendiri difaktorkan ulang secara ekstensif, yang menghabiskan banyak waktu dan tenaga. Partisi /system_ext dimulai sebagai tempat untuk menghosting komponen tersebut secara sementara yang belum siap dipindahkan ke partisi /product. Tujuan SSI pada akhirnya adalah menghilangkan partisi /system_ext.

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

Memisahkan komponen dari partisi /system dan /system_ext ke dalam partisi /product

Android 9 memperkenalkan partisi /product yang digabungkan dengan partisi /system. Modul dalam 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 dilakukan partisi /product 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 menginstal modul produk yang dipaketkan, seperti yang dijelaskan di bagian /system_ext partition. Untuk melakukannya, uraikan modul khusus produk dan pindahkan ke partisi /product. Memisahkan modul khusus produk akan membuat /system_ext umum untuk perangkat. (Untuk mengetahui detail selengkapnya, lihat Membuat partisi /system_ext umum.)

Untuk membatalkan pengelompokan partisi /product dari komponen sistem, partisi /product harus memiliki kebijakan penerapan yang sama dengan partisi /vendor yang sudah di-unbundle dengan Project Treble.

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

• Antarmuka native: Modul native di partisi /product harus di-unbundle dari partisi lainnya. Satu-satunya dependensi yang diizinkan dari modul produk adalah beberapa library VNDK (termasuk LLNDK) dari partisi /system. Library JNI yang menjadi dependensi 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. Alat ini digunakan untuk pengujian kepatuhan Treble (misalnya, CTS-on-GSI) dan sebagai platform referensi yang dapat digunakan developer aplikasi untuk menguji kompatibilitas aplikasi mereka saat tidak memiliki perangkat nyata yang menjalankan versi Android 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. Saat GSI digunakan sebagai gambar system, OEM dapat berfokus pada gambar 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 mendekati AOSP. Jika OEM membangun image sistem dari sumber AOSP, OEM dapat mengganti image sistem yang mereka build dengan GSI yang disediakan oleh AOSP. Namun, OEM tidak perlu mencapai langkah akhir (menggunakan GSI seperti 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 (GSI OEM) 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. Namun, OEM tidak diizinkan untuk mengubah file generic_system.mk itu sendiri.

Gambar 3. Mewarisi generic_system.mk untuk image sistem OEM

Langkah 2. Membuat 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. Menentukan 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 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 perlunya modifikasi tambahan pada GSI OEM.

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

Langkah 4. Membuat 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 mengabaikan perubahan mereka di GSI OEM, atau mengupload perubahan mereka ke AOSP sehingga GSI AOSP menyertakan perubahan mereka.

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 OEM GSI, OEM dapat menggunakan makro makefile yang disebut require-artifacts-in-path untuk mencegah deklarasi modul sistem setelah makro dipanggil. Lihat contoh Membuat makefile dan mengaktifkan pemeriksaan jalur artefak.

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

Terapkan antarmuka produk

Untuk menjamin bahwa partisi /product di-unbundle, OEM dapat memastikan perangkat mereka menerapkan antarmuka produk dengan menetapkan PRODUCT_PRODUCT_VNDK_VERSION:= current untuk modul native, dan PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true untuk modul Java. Variabel ini ditetapkan secara otomatis jika PRODUCT_SHIPPING_API_LEVEL perangkat lebih besar dari atau sama dengan 30. Untuk mengetahui informasi selengkapnya, lihat Menerapkan Antarmuka Partisi Produk.

Membuat partisi /system_ext umum

Partisi /system_ext mungkin berbeda di antara perangkat, karena dapat memiliki modul yang dipaketkan sistem khusus perangkat. Karena SSI terdiri dari partisi /system dan /system_ext, perbedaan dalam partisi /system_ext menghambat OEM untuk menentukan SSI. OEM dapat memiliki SSI sendiri dan dapat membagikan SSI tersebut di antara beberapa perangkat dengan menghapus perbedaan apa pun dan membuat partisi /system_ext menjadi umum.

Bagian ini memberikan rekomendasi untuk membuat partisi /system_ext 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 disukai untuk menghapus API tersembunyi dari aplikasi adalah dengan menemukan API publik atau sistem alternatif untuk menggantikannya. Jika tidak ada API untuk mengganti API tersembunyi, OEM dapat berkontribusi pada AOSP untuk menentukan API sistem baru untuk perangkat mereka.

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

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

Paket tertentu yang dipaketkan dengan sistem tidak umum di seluruh perangkat. Membatalkan penggabungan modul APK ini untuk memindahkannya ke produk atau partisi vendor mungkin 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 ulang resource framework config_disableApkUnlessMatchedSku_skus_list dan config_disableApksUnlessMatchedSku_apk_list.

Untuk setelan yang lebih akurat, 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 overlay. Namun, hal ini dapat menghambat penentuan SSI, jadi pastikan properti untuk RRO diaktifkan dan ditetapkan dengan benar. Dengan menetapkan properti sebagai berikut, OEM dapat menetapkan semua overlay yang dihasilkan 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 otomatis. Untuk 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?

Itu bergantung pada kesamaan dan karakteristik perangkat (atau kelompok perangkat). OEM dapat mencoba membuat partisi system_ext menjadi umum, seperti yang dijelaskan dalam Membuat partisi system_ext menjadi 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. Sebagai contoh, lihat Menerapkan Antarmuka Partisi Produk.

Dapatkah saya menghapus modul dari generik_system.mk yang bertentangan dengan implementasi saya?

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