Gambar Sistem Bersama Android

Halaman ini menyajikan beberapa mekanisme yang dapat digunakan oleh OEM perangkat Android untuk memiliki citra sistem bersama (SSI) di seluruh lini produk. Hal ini juga mengusulkan prosedur untuk mendasarkan SSI milik OEM pada citra sistem generik (GSI) yang dibuat oleh AOSP.

Latar belakang

Dengan Project Treble , Android monolitik dipecah menjadi dua bagian: bagian khusus perangkat keras (implementasi vendor) dan bagian OS generik (kerangka kerja OS Android). Perangkat lunak untuk masing-masing diinstal dalam partisi terpisah: partisi vendor untuk perangkat lunak khusus perangkat keras, dan partisi sistem untuk perangkat lunak OS generik. Antarmuka berversi, yang disebut antarmuka vendor ( VINTF ), didefinisikan dan diterapkan di dua partisi. Dengan menggunakan sistem partisi ini, Anda dapat memodifikasi partisi sistem tanpa memodifikasi partisi vendor, begitu pula sebaliknya.

Motivasi

Kode kerangka kerja yang dirilis di AOSP telah sesuai dengan arsitektur Treble dan mempertahankan kompatibilitas dengan implementasi vendor lama. Misalnya, image sistem umum yang dibuat dari sumber Android 10 AOSP dapat berjalan di perangkat apa pun yang mendukung Treble dan menjalankan Android 8 atau lebih tinggi. Versi Android yang dikirimkan pada perangkat konsumen dimodifikasi oleh vendor SoC dan OEM. (Lihat Kehidupan Rilis Android .) Perubahan dan ekstensi yang dibuat pada kerangka kerja ini tidak ditulis untuk menjaga kompatibilitas ke belakang, yang berarti peningkatan kompleksitas dan biaya yang lebih tinggi dalam peningkatan OS. Perubahan dan modifikasi khusus perangkat menambah biaya dan kerumitan dalam mengupgrade versi OS Android.

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

Ikhtisar SSI

Dengan SSI, komponen perangkat lunak khusus produk dan ekstensi OEM ditempatkan di partisi /product baru. Komponen di partisi /product menggunakan antarmuka yang terdefinisi dengan baik dan stabil 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 OS Android dirilis, OEM hanya berinvestasi satu kali dalam memperbarui SSI mereka ke rilis Android terbaru. Mereka dapat menggunakan kembali SSI untuk memperbarui beberapa perangkat tanpa memperbarui partisi /product .

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

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

Ide inti untuk memisahkan komponen khusus produk ke dalam partisi produk mirip dengan ide Treble yang 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” menggambarkan semua sumber daya, biner, teks, perpustakaan, dan sebagainya yang diinstal pada gambar, yang pada dasarnya menjadi partisi.

Partisi di sekitar SSI

Gambar 1 menunjukkan partisi di sekitar SSI, dan antarmuka berversi di seluruh partisi dan kebijakan pada antarmuka. Bagian ini menjelaskan masing-masing partisi dan antarmuka secara rinci.

Gambar 1. Partisi dan antarmuka di sekitar SSI

Gambar dan partisi

Informasi di bagian ini membedakan antara istilah image dan partisi .

• Gambar adalah perangkat lunak konseptual yang dapat diperbarui secara mandiri.
• Partisi adalah lokasi penyimpanan fisik yang dapat diperbarui secara mandiri.

Bagian pada Gambar 1 didefinisikan sebagai berikut:

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

  • Partisi /system berisi komponen berbasis AOSP, sedangkan /system_ext , ketika diimplementasikan, berisi ekstensi dan komponen vendor OEM dan SoC yang digabungkan erat dengan komponen AOSP. Misalnya, pustaka kerangka kerja Java OEM yang menyediakan API khusus untuk aplikasi milik OEM lebih cocok di /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, namun akan bermanfaat jika digunakan untuk fitur kustom dan ekstensi apa pun yang terkait erat dengan komponen berbasis AOSP. Perbedaan ini membantu Anda mengidentifikasi perubahan yang perlu Anda lakukan, 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 OS Android. Letakkan 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 di gambar produk. Lokasi suatu komponen tidak ditentukan oleh kepemilikannya , namun 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 yang terpisah, vendor SoC dan image ODM digabungkan bersama di partisi /vendor .

Antarmuka antar gambar

Dua antarmuka utama untuk vendor dan gambar produk ada di sekitar SSI:

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

  • HIDL (Passthrough HAL hanya tersedia untuk modul system dan system_ext )
  • AIDL yang stabil
  • Konfigurasi
    • API properti sistem
    • API skema file konfigurasi
  • VNDK
  • API SDK Android
  • Perpustakaan Java SDK

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

Mengaktifkan SSI di Android 11

Bagian ini menjelaskan cara menggunakan fitur baru 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 hubungan erat dengan komponen yang ditentukan AOSP di partisi /system .) Partisi /system_ext diasumsikan sebagai ekstensi khusus OEM ke partisi /system , tanpa antarmuka yang ditentukan di seluruh kedua partisi tersebut. Komponen di partisi /system_ext dapat melakukan panggilan API pribadi ke partisi /system , dan komponen di partisi /system dapat membuat panggilan API pribadi ke partisi /system_ext .

Karena kedua partisi tersebut digabungkan secara erat, kedua partisi tersebut ditingkatkan secara bersamaan ketika versi Android baru dirilis. Partisi /system_ext yang dibuat untuk rilis Android sebelumnya tidak harus 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 .

Sejarah

Berikut adalah beberapa sejarah tentang partisi /system_ext . Tujuan desainnya adalah untuk menempatkan semua komponen khusus OEM, terlepas dari apakah komponen tersebut umum, di partisi /product . Namun, memindahkan semuanya sekaligus tidak mungkin dilakukan, terutama ketika beberapa komponen mempunyai hubungan erat dengan partisi /system . Untuk memindahkan komponen yang digabungkan erat ke partisi /product , antarmuka produk harus diperluas. Hal ini sering kali mengharuskan komponen itu sendiri difaktorkan ulang secara ekstensif, sehingga menghabiskan banyak waktu dan tenaga. Partisi /system_ext dimulai sebagai tempat untuk menampung sementara komponen-komponen yang belum siap untuk 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 pada komponen di partisi /system dan /system_ext . Ketika image sistem dibuat dari sumber yang semirip mungkin dengan yang ada di AOSP, Anda dapat memfokuskan upaya peningkatan 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 di partisi /product menggunakan sumber daya sistem tanpa batasan apa pun, dan sebaliknya. Untuk memungkinkan SSI di Android 10, komponen produk dipecah menjadi partisi /system_ext dan /product . Partisi /system_ext tidak harus mematuhi batasan penggunaan komponen sistem seperti yang dilakukan partisi /product di Android 9. Mulai Android 10, partisi /product harus dipisahkan dari partisi /system dan harus menggunakan antarmuka yang stabil dari partisi /system dan /system_ext .

Tujuan utama partisi /system_ext adalah untuk memperluas fitur sistem, bukan untuk menginstal modul produk yang dibundel, seperti yang dijelaskan di bagian /system_ext partition . Untuk melakukannya, pisahkan modul khusus produk dan pindahkan ke partisi /product . Memisahkan modul khusus produk menjadikan /system_ext umum untuk perangkat. (Untuk detail lebih lanjut, lihat Membuat partisi /system_ext menjadi umum .)

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

Mulai Android 11, antarmuka asli dan Java untuk partisi /product diterapkan seperti dijelaskan di bawah. Untuk informasi lebih lanjut, lihat Menerapkan Antarmuka Partisi Produk .

• Antarmuka asli : Modul asli di partisi /product harus dipisahkan dari partisi lain. Satu-satunya dependensi yang diperbolehkan dari modul produk adalah beberapa pustaka VNDK (termasuk LLNDK) dari partisi /system . Pustaka JNI yang diandalkan oleh aplikasi produk harus berupa pustaka 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 , dan pustaka Java SDK di partisi /system atau /system_ext . Anda dapat menentukan pustaka Java SDK untuk API khusus.

Langkah-langkah yang disarankan untuk SSI berbasis GSI

Gambar 2. Partisi yang disarankan untuk SSI berbasis GSI

Citra sistem generik (GSI) adalah citra sistem yang dibuat langsung dari AOSP. Ini digunakan untuk pengujian kepatuhan Treble (misalnya, CTS-on-GSI) dan sebagai platform referensi yang dapat digunakan pengembang aplikasi untuk menguji kompatibilitas aplikasi mereka ketika mereka tidak memiliki perangkat nyata yang menjalankan versi Android yang diperlukan.

OEM juga dapat menggunakan GSI untuk membuat SSI mereka. Seperti yang dijelaskan dalam Gambar dan partisi , SSI terdiri dari gambar sistem untuk komponen yang ditentukan AOSP dan gambar system_ext untuk komponen yang ditentukan OEM. Saat GSI digunakan sebagai image system , OEM dapat fokus pada image system_ext untuk peningkatan.

Bagian ini memberikan panduan bagi OEM yang ingin memodulasi penyesuaian mereka ke dalam partisi /system_ext dan /product saat menggunakan image sistem AOSP atau mendekati AOSP. Jika OEM membuat image sistem dari sumber AOSP, maka mereka dapat mengganti image sistem yang mereka buat 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 diubah namanya menjadi generic_system.mk di AOSP), image sistem (OEM GSI) menyertakan semua file yang dimiliki AOSP GSI. File-file ini dapat dimodifikasi oleh OEM, sehingga OEM GSI dapat berisi file kepemilikan OEM selain file AOSP GSI. Namun, OEM tidak diperbolehkan mengubah file generic_system.mk itu sendiri.

Gambar 3. Mewarisi generic_system.mk untuk image sistem OEM

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

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

Gambar 4. Memindahkan file tambahan dari OEM GSI

Langkah 3. Menentukan daftar yang diizinkan untuk membatasi file yang dimodifikasi di OEM GSI

Untuk memeriksa file yang dimodifikasi, OEM dapat menggunakan alat compare_images , dan membandingkan GSI AOSP dengan GSI OEM. Dapatkan AOSP GSI dari target makan siang 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 OEM GSI.

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

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

Menghapus daftar yang diizinkan memungkinkan OEM menggunakan AOSP GSI sebagai image sistem untuk produk mereka sendiri. Untuk menghapus daftar yang diizinkan, OEM dapat mengabaikan perubahannya di GSI OEM, atau melakukan upstream perubahannya ke AOSP sehingga AOSP GSI menyertakan perubahannya.

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

Mendefinisikan SSI untuk OEM

Lindungi partisi /system pada waktu build

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

OEM dapat menentukan daftar untuk mengizinkan modul khusus produk dipasang di partisi /system untuk sementara. Namun, daftar tersebut harus kosong agar GSI OEM umum untuk semua produk OEM. Proses ini untuk menentukan OEM GSI dan tidak bergantung pada langkah-langkah untuk AOSP GSI .

Menerapkan antarmuka produk

Untuk menjamin bahwa partisi /product tidak dibundel, OEM dapat memastikan perangkat mereka menerapkan antarmuka produk dengan menyetel PRODUCT_PRODUCT_VNDK_VERSION:= current untuk modul asli, dan PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true untuk modul java. Variabel-variabel ini secara otomatis disetel jika PRODUCT_SHIPPING_API_LEVEL perangkat lebih besar dari atau sama dengan 30 . Untuk informasi selengkapnya, lihat Menerapkan Antarmuka Partisi Produk .

Membuat partisi /system_ext menjadi umum

Partisi /system_ext mungkin berbeda antar perangkat, karena dapat memiliki modul khusus perangkat yang disertakan dalam sistem. Karena SSI terdiri dari partisi /system dan /system_ext , perbedaan pada partisi /system_ext menghalangi OEM untuk mendefinisikan SSI. OEM dapat memiliki SSI mereka sendiri dan dapat membagikan SSI tersebut ke beberapa perangkat dengan menghilangkan perbedaan apa pun dan membuat partisi /system_ext menjadi umum.

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

Ekspos 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 mencari API publik atau sistem alternatif untuk menggantikannya. Jika tidak ada API untuk menggantikan API tersembunyi, OEM dapat berkontribusi pada AOSP untuk menentukan API sistem baru untuk perangkat mereka.

Alternatifnya, OEM dapat menentukan API khusus dengan membuat pustaka Java SDK mereka sendiri di partisi /system_ext . Itu dapat menggunakan API tersembunyi di partisi sistem, dan dapat menyediakan API ke aplikasi di partisi produk atau vendor. OEM harus membekukan API yang berhubungan dengan produk untuk kompatibilitas ke belakang.

Sertakan superset semua APK dan lewati beberapa instalasi paket untuk setiap perangkat

Paket tertentu yang digabungkan dengan sistem tidak umum di seluruh perangkat. Memisahkan 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 ini, OEM melapisi sumber daya kerangka kerja config_disableApkUnlessMatchedSku_skus_list dan config_disableApksUnlessMatchedSku_apk_list .

Untuk pengaturan yang lebih tepat, nyatakan penerima siaran yang menonaktifkan paket yang tidak diperlukan. Penerima siaran memanggil setApplicationEnabledSetting untuk menonaktifkan paket ketika menerima pesan ACTION_BOOT_COMPLETED .

Tentukan RRO alih-alih menggunakan hamparan sumber daya statis

Hamparan sumber daya statis memanipulasi paket yang dilapis. Namun, hal ini dapat menghambat pendefinisian SSI, jadi pastikan properti untuk RRO diaktifkan dan diatur dengan benar. Dengan mengatur properti sebagai berikut, OEM dapat menjadikan semua overlay yang dibuat secara otomatis sebagai RRO.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

Pertanyaan yang sering diajukan (FAQ)

Bisakah saya mendefinisikan beberapa SSI?

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

Bisakah saya memodifikasi generic_system.mk ( mainline_system.mk ) untuk OEM GSI?

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

Bisakah saya menghapus modul dari generic_system.mk yang bertentangan dengan implementasi saya?

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