Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.

Halaman ini diterjemahkan oleh Cloud Translation API.

Siklus proses FCM

Rilis framework Android memiliki beberapa Framework Compatibility Matrix (FCM), satu untuk setiap Target FCM Version yang dapat diupgrade, yang menentukan apa yang dapat digunakan framework dan persyaratan versi Target FCM. Sebagai bagian dari siklus proses FCM, Android menghentikan penggunaan dan menghapus HAL HIDL, lalu mengubah file FCM untuk mencerminkan status versi HAL.

Untuk mengaktifkan OTA khusus framework di ekosistem mereka sendiri, partner yang memperluas antarmuka vendor juga harus menghentikan penggunaan dan menghapus HAL HIDL menggunakan metode yang sama.

Terminologi

Matriks Kompatibilitas Framework (FCM): File XML yang menentukan persyaratan framework pada penerapan vendor yang sesuai. Matriks kompatibilitas diberi versi, dan versi baru dibekukan untuk setiap rilis framework. Setiap rilis framework berisi beberapa FCM.
Versi FCM Platform (S_F): Kumpulan semua versi FCM dalam rilis framework. Framework ini dapat berfungsi dengan implementasi vendor apa pun yang memenuhi salah satu FCM ini.
Versi FCM (F): Versi tertinggi di antara semua FCM dalam rilis framework.
Target Versi FCM (V): Versi FCM yang ditargetkan (dari S_F), yang dideklarasikan secara eksplisit dalam manifes perangkat, yang dipenuhi oleh implementasi vendor. Implementasi vendor harus dibuat berdasarkan FCM yang dipublikasikan, meskipun dapat mendeklarasikan versi HAL yang lebih baru dalam Manifes Perangkatnya.
Versi HAL: Versi HAL memiliki format foo@x.y, dengan foo adalah nama HAL dan x.y adalah versi tertentu; misalnya, nfc@1.0, keymaster@3.0 (awalan root, misalnya android.hardware, dihilangkan di seluruh dokumen ini.)
Manifes Perangkat: File XML yang menentukan versi HAL yang disediakan sisi perangkat antarmuka vendor, termasuk image vendor dan ODM. Konten manifes perangkat dibatasi oleh versi Target FCM perangkat, tetapi dapat mencantumkan HAL yang jauh lebih baru dibandingkan dengan FC yang sesuai dengan V.
HAL Perangkat: HAL yang tercantum (disediakan) dalam manifes perangkat dan tercantum dalam matriks kompatibilitas framework (FCM).
Matriks Kompatibilitas Perangkat (DCM): File XML yang menentukan persyaratan vendor pada penerapan framework yang sesuai. Setiap perangkat berisi satu DCM.
Manifes Framework: File XML yang menentukan versi HAL yang disediakan oleh sisi framework antarmuka vendor, termasuk sistem, system_ext, dan image produk. HAL dalam manifes framework dinonaktifkan secara dinamis sesuai dengan versi Target FCM perangkat.
HAL Framework: HAL yang tercantum seperti yang disediakan dalam manifes framework dan tercantum dalam matriks kompatibilitas perangkat (DCM).

Siklus proses FCM di codebase

Dokumen ini menjelaskan siklus proses FCM secara ringkas. Untuk melihat manifes yang didukung, lihat hardware/interfaces/compatibility_matrix.<FCM>.xml tempat FCM dapat ditemukan di system/libvintf/include/vintf/Level.h.

Perangkat yang mengirimkan versi rilis Android yang sesuai diharapkan memiliki nilai FCM yang lebih besar dari atau sama dengan level yang setara. Misalnya, perangkat yang dikirimkan dengan Android 11 umumnya memiliki FCM level 5, tetapi menerapkan FCM level 6 atau yang lebih tinggi, yang dilengkapi dengan berbagai persyaratan tambahan yang ditentukan dalam matriks kompatibilitas. Level yang didukung untuk Android 15 adalah:

FCM	Versi Android
5	Android 11/R
6	Android 12/S
7	Android 13/T
8	Android 14/U
202404	Android 15/V

Level FCM sama dengan atau lebih baru dari Level API Vendor.

Saat Android menghentikan penggunaan level FCM, level tersebut masih didukung untuk perangkat yang ada. Perangkat yang menargetkan level FCM yang lebih rendah secara implisit diizinkan untuk menggunakan HAL yang tercantum di level FCM yang lebih baru, selama tersedia di cabang.

Mengembangkan di versi FCM baru

Android menambahkan versi FCM untuk setiap rilis framework (seperti Android 8 dan 8.1). Selama pengembangan, compatibility_matrix.F.xml baru dibuat dan compatibility_matrix.f.xml yang ada (dengan f < F) tidak lagi diubah.

Untuk mulai mengembangkan di FCM Versi F baru:

Salin compatibility_matrix.<F-1>.xml terbaru ke compatibility_matrix.F.xml.
Perbarui atribut level dalam file menjadi F.
Tambahkan aturan build yang sesuai untuk menginstal matriks kompatibilitas ini ke perangkat.

Memperkenalkan HAL baru

Selama pengembangan, saat memperkenalkan HAL baru (Wi-Fi, NFC, dll.) ke Android pada FCM versi F saat ini, tambahkan HAL ke compatibility_matrix.F.xml.

Misalnya, Android 8.1 memperkenalkan cas@1.0. Perangkat yang diluncurkan dengan Android 8.1 dapat menerapkan HAL ini, sehingga entri berikut ditambahkan ke compatibility_matrix.F.xml (yang sebelumnya bernama compatibility_matrix.current.xml untuk sementara selama pengembangan rilis tersebut):

<hal format="hidl">
    <name>android.hardware.cas</name>
    <version>1.0</version>
    <interface>
        <name>IMediaCasService</name>
        <instance>default</instance>
    </interface>
</hal>

Mengupgrade HAL (minor)

Versi HAL AIDL dihitung sebagai versi HAL minor. Versi antarmuka HIDL memiliki versi major.minor seperti 1.2.

Selama pengembangan, saat HAL AIDL memiliki upgrade versi dari 2 ke 3 pada Versi FCM saat ini F, versi baru akan ditambahkan ke entri HAL di compatibility_matrix.F.xml. Kolom versi entri HAL menerima rentang seperti 2-3.

Misalnya, Android FCM F memperkenalkan foo@3 sebagai upgrade versi minor HAL. Versi lama, foo@2, digunakan untuk perangkat yang menargetkan FCM lama, sedangkan versi yang lebih baru, foo@3, dapat digunakan untuk perangkat yang menargetkan Android FCM F. Entri di FCM lama sebelum versi 2 terlihat seperti:

<hal format="aidl">
    <name>foo</name>
    <version>2</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Entri ini disalin ke compatibility_matrix.F.xml dan diubah untuk mendukung versi 3 sebagai berikut:

<hal format="aidl">
    <name>foo</name>
    <version>2-3</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Mengupgrade HAL (utama)

Selama pengembangan, saat HAL memiliki upgrade versi utama pada Versi FCM F saat ini, versi utama baru x.0 akan ditambahkan ke compatibility_matrix.F.xml dengan setelan berikut:

Hanya versi x.0, jika perangkat yang dikirimkan dengan V = F harus diluncurkan dengan x.0.
Dengan versi utama yang lebih lama dalam tag <hal> yang sama, jika perangkat yang dikirimkan dengan V = F dapat diluncurkan dengan versi utama yang lebih lama.

Misalnya, FCM versi F memperkenalkan foo@2.0 sebagai upgrade versi utama HAL 1.0 dan menghentikan penggunaan HAL 1.0. Versi lama, foo@1.0, digunakan untuk perangkat yang menargetkan versi FCM sebelumnya. Perangkat yang menargetkan FCM versi F harus menyediakan versi 2.0 baru jika menyediakan HAL. Dalam contoh ini, versi FCM sebelumnya berisi entri ini:

<hal format="hidl">
    <name>foo</name>
    <version>1.0</version>;
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Salin entri ini ke compatibility_matrix.F.xml dan ubah sebagai berikut:

<hal format="hidl">
    <name>foo</name>
    <version>2.0</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Pembatasan:

Karena HAL 1.0 tidak ada di compatibility_matrix.F.xml, perangkat yang menargetkan FCM versi F tidak boleh menyediakan HAL 1.0 (karena HAL ini dianggap tidak digunakan lagi).
Karena HAL 1.0 ada di Versi FCM yang lebih lama, framework masih dapat berfungsi dengan HAL 1.0 sehingga kompatibel dengan perangkat lama yang menargetkan versi FCM yang lebih lama.

Versi FCM baru

Proses merilis Versi FCM di partisi sistem dilakukan sepenuhnya oleh Google sebagai bagian dari rilis AOSP dan mencakup langkah-langkah berikut:

Pastikan compatibility_matrix.F.xml memiliki atribut level="F".
Pastikan semua perangkat mem-build dan melakukan booting.
Perbarui pengujian VTS untuk memastikan perangkat yang diluncurkan dengan framework terbaru (berdasarkan API level Pengiriman) memiliki Versi FCM Target V >= F.
Memublikasikan file ke AOSP.

Misalnya, pengujian VTS memastikan bahwa perangkat yang diluncurkan dengan Android 9 memiliki Target FCM Version >= 3.

Selain itu, FCM produk dan system_ext juga dapat mencantumkan persyaratan untuk setiap versi FCM platform. Rilis versi FCM pada partisi produk dan system_ext dilakukan oleh pemilik gambar tersebut. Nomor versi FCM di partisi produk dan system_ext harus selaras dengan yang ada di partisi sistem. Serupa dengan versi FCM di partisi sistem, matriks kompatibilitas pada FCM versi F di partisi produk dan system_ext mencerminkan persyaratan pada perangkat dengan target FCM versi F.

Penghentian penggunaan versi HAL

Penghentian Versi HAL adalah keputusan developer (yaitu untuk HAL AOSP, Google akan membuat keputusan). Hal ini dapat terjadi saat versi HAL yang lebih tinggi (baik versi minor maupun utama) dirilis.

Menghentikan penggunaan HAL perangkat

Jika HAL perangkat tertentu foo@x.y tidak digunakan lagi pada FCM Versi F, artinya perangkat apa pun yang diluncurkan dengan Target FCM Versi V = F atau yang lebih baru tidak boleh menerapkan foo pada versi x.y atau versi apa pun yang lebih lama dari x.y. Versi HAL yang tidak digunakan lagi masih didukung oleh framework untuk mengupgrade perangkat.

Saat Versi FCM F dirilis, Versi HAL foo@x.y dianggap tidak digunakan lagi jika Versi HAL tertentu tidak dinyatakan secara eksplisit dalam FCM terbaru untuk Versi FCM Target V = F. Untuk perangkat yang diluncurkan dengan V = F, salah satu kondisi berikut terpenuhi:

Framework memerlukan versi yang lebih tinggi (utama atau minor);
Framework tidak lagi memerlukan HAL.

Misalnya, di Android 9, health@2.0 diperkenalkan sebagai upgrade versi utama HAL 1.0. health@1.0 dihapus dari compatibility_matrix.3.xml, tetapi ada di compatibility_matrix.legacy.xml, compatibility_matrix.1.xml, dan compatibility_matrix.2.xml. Oleh karena itu, health@1.0 dianggap tidak digunakan lagi.

Menghentikan penggunaan HAL framework

Jika framework HAL foo@x.y tertentu tidak digunakan lagi pada FCM Versi F, artinya perangkat apa pun yang diluncurkan dengan Target FCM Versi V = F atau yang lebih baru tidak boleh mengharapkan framework menyediakan foo pada versi x.y, atau pada versi apa pun yang lebih lama dari x.y. Versi HAL yang tidak digunakan lagi masih disediakan oleh framework untuk mengupgrade perangkat.

Saat FCM versi F dirilis, Versi HAL foo@x.y dianggap tidak digunakan lagi jika manifes framework menentukan max-level="F - 1" untuk foo@x.y. Untuk perangkat yang diluncurkan dengan V = F, framework tidak menyediakan HAL foo@x.y. Matriks kompatibilitas perangkat di perangkat yang diluncurkan dengan V = F tidak boleh mencantumkan HAL framework dengan max-level < V.

Misalnya, di Android 12, schedulerservice@1.0 tidak digunakan lagi. Atribut max-level-nya ditetapkan ke 5, versi FCM yang diperkenalkan di Android 11. Lihat manifes framework Android 12.

Penghapusan dukungan untuk versi FCM target

Jika perangkat aktif dari Versi Target FCM V tertentu turun di bawah nilai minimum tertentu, Versi Target FCM akan dihapus dari kumpulan S_F dari rilis framework berikutnya. Hal ini dilakukan dengan kedua langkah berikut:

Menghapus compatibility_matrix.V.xml dari aturan build (sehingga tidak diinstal di image sistem), dan menghapus kode apa pun yang menerapkan atau bergantung pada kemampuan yang dihapus.
Menghapus HAL framework dengan max-level yang lebih rendah dari atau sama dengan V dari manifes framework, dan menghapus kode apa pun yang mengimplementasikan HAL framework yang dihapus.

Perangkat dengan Versi FCM target di luar S_F untuk rilis framework tertentu tidak dapat diupgrade ke rilis tersebut.

Penghapusan HAL yang tidak digunakan lagi sepenuhnya

Saat versi FCM dihapus, beberapa antarmuka HAL, atau versi antarmuka HAL, tidak lagi ada di FCM mana pun. Artinya, Android tidak lagi mendukung versi tersebut sama sekali, bahkan untuk mengupgrade perangkat.

Setelah HAL tidak lagi didukung, developer akan menghapus referensi ke antarmuka HAL tersebut dari Android, termasuk dalam kode klien dalam framework, implementasi default, dan kasus pengujian VTS.

Jika tidak ada HAL yang didukung yang mewarisi dari HAL yang dihapus, definisi HAL itu sendiri dapat dihapus dengan beberapa langkah tambahan.

Hapus definisi antarmuka HAL dari kode sumber. Ini mencakup file *.aidl dan modul Android.bp aidl_interface.
Jika HIDL, hapus HASH dari hardware/interfaces/current.txt.
Jika AIDL, hapus direktori aidl_api dengan file AIDL yang dibekukan.
Hapus antarmuka dari hardware/interfaces/compatibility_matrices/exclude/fcm_exclude.cpp.

Status versi HAL

Bagian berikut menjelaskan (dalam urutan kronologis) kemungkinan status Versi HAL.

Belum dirilis

Untuk HAL perangkat, jika Versi HAL tidak ada dalam matriks kompatibilitas publik dan beku, versi tersebut dianggap belum dirilis dan mungkin sedang dalam pengembangan. Ini mencakup Versi HAL yang hanya ada di compatibility_matrix.F.xml. Contoh:

Selama pengembangan Android 9, HAL health@2.0 dianggap sebagai HAL yang belum dirilis dan hanya ada di compatibility_matrix.3.xml.
HAL teleportation@1.0 tidak ada dalam matriks kompatibilitas yang dirilis, dan juga dianggap sebagai HAL yang belum dirilis.

Untuk HAL framework, jika versi HAL hanya ada dalam manifes framework dari cabang pengembangan yang tidak terkait, versi tersebut dianggap belum dirilis.

Rilis dan saat ini

Untuk HAL perangkat, jika Versi HAL berada dalam matriks kompatibilitas publik dan dibekukan, versi tersebut akan dirilis. Misalnya, setelah FCM Versi 3 dibekukan dan dipublikasikan ke AOSP, HAL health@2.0 dianggap sebagai Versi HAL yang dirilis dan saat ini.

Jika Versi HAL berada dalam matriks kompatibilitas publik dan beku yang memiliki Versi FCM tertinggi, versi HAL adalah versi terbaru (yaitu tidak dihentikan penggunaannya). Misalnya, Versi HAL yang ada (seperti nfc@1.0 yang diperkenalkan di compatibility_matrix.legacy.xml) yang terus ada di compatibility_matrix.3.xml juga dianggap sebagai Versi HAL yang dirilis dan saat ini.

Untuk HAL framework, jika versi HAL ada dalam manifes framework dari cabang yang dirilis terbaru tanpa atribut max-level atau (tidak biasa) max-level sama dengan atau lebih tinggi dari versi FCM yang dirilis di cabang ini, versi tersebut dianggap sebagai versi HAL yang dirilis dan saat ini. Misalnya, HAL displayservice dirilis dan saat ini ada di Android 12, seperti yang ditentukan oleh manifes framework Android 12.

Dirilis, tetapi tidak digunakan lagi

Untuk HAL perangkat, Versi HAL tidak digunakan lagi jika dan hanya jika semua hal berikut terpenuhi:

Aplikasi tersebut dirilis.
Versi ini tidak ada dalam matriks kompatibilitas publik dan beku yang memiliki Versi FCM tertinggi.
Versi ini berada dalam matriks kompatibilitas publik dan beku yang masih didukung framework.

Contoh:

HAL health@1.0 ada di compatibility_matrix.legacy.xml, compatibility_matrix.1.xml, dan compatibility_matrix.2.xml, tetapi tidak ada di compatibility_matrix.3.xml. Oleh karena itu, API ini dianggap tidak digunakan lagi di Android 9.
HAL daya memiliki upgrade versi minor di Android 9, tetapi power@1.0 masih dalam compatibility_matrix.3.xml.
power@1.0 compatibility_matrix.legacy.xml, compatibility_matrix.1.xml, dan compatibility_matrix.2.xml.
compatibility_matrix.3.xml memiliki power@1.0-1.

Oleh karena itu, power@1.0 adalah versi terbaru, tetapi BUKAN tidak digunakan lagi, di Android 9.

Untuk HAL framework, jika versi HAL ada dalam manifes framework dari cabang terbaru yang dirilis dengan atribut max-level yang lebih rendah dari rilis versi FCM di cabang ini, versi tersebut dianggap sebagai versi HAL yang dirilis tetapi tidak digunakan lagi. Misalnya, HAL schedulerservice dirilis, tetapi tidak digunakan lagi di Android 12, seperti yang ditentukan oleh manifes framework Android 12.

Dihapus

Untuk HAL perangkat, Versi HAL dihapus jika dan hanya jika hal berikut benar:

Sebelumnya telah dirilis.
Tidak ada dalam matriks kompatibilitas publik dan beku yang didukung framework.

Matriks kompatibilitas yang bersifat publik, dibekukan, tetapi tidak didukung oleh framework disimpan di codebase untuk menentukan kumpulan Versi HAL yang dihapus sehingga pengujian VTS dapat ditulis untuk memastikan HAL yang dihapus tidak ada di perangkat baru.

Untuk HAL framework, versi HAL dihapus jika dan hanya jika hal berikut terpenuhi:

Sebelumnya telah dirilis.
File ini tidak ada dalam manifes framework cabang yang dirilis terbaru.

FCM Lama

Versi FCM Target lama adalah nilai khusus untuk semua perangkat non-Treble. FCM lama, compatibility_matrix.legacy.xml, mencantumkan persyaratan framework di perangkat lama (yaitu perangkat yang diluncurkan sebelum Android 8.0).

Jika file ini ada untuk FCM dengan versi F, perangkat non-Treble apa pun dapat diupgrade ke F asalkan manifes perangkatnya kompatibel dengan file ini. Penghapusannya mengikuti prosedur yang sama seperti FCM untuk Versi FCM Target lainnya (dihapus setelah jumlah perangkat pra-8.0 aktif turun di bawah nilai minimum tertentu).

Versi FCM yang dirilis

Daftar versi FCM yang dirilis dapat ditemukan di bagian hardware/interfaces/compatibility_matrices.

Untuk menemukan versi FCM yang dirilis dengan rilis Android tertentu, lihat Level.h.