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 Target FCM version. Sebagai bagian dari siklus proses FCM, Android menghentikan dan menghapus HIDL HAL, 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 dan menghapus HIDL HAL menggunakan metode yang sama.

Terminologi

Framework Compatibility Matrix (FCM)
File XML yang menentukan persyaratan framework pada implementasi vendor yang sesuai. Matriks kompatibilitas diberi versi, dan versi baru dibekukan untuk setiap rilis framework. Setiap rilis framework berisi beberapa FCM.
Platform FCM Versions (SF)
Kumpulan semua versi FCM dalam rilis framework. Framework dapat berfungsi dengan implementasi vendor yang memenuhi salah satu FCM ini.
FCM Version (F)
Versi tertinggi di antara semua FCM dalam rilis framework.
Target FCM Version (V)
Versi FCM target (dari SF), 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.
HAL Version
HAL Version 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.)
Device Manifest
File XML yang menentukan versi HAL mana yang disediakan oleh sisi perangkat antarmuka vendor, termasuk image vendor dan ODM. Konten manifes perangkat dibatasi oleh Target FCM version perangkat, tetapi dapat mencantumkan HAL yang benar-benar lebih baru dibandingkan FC yang sesuai dengan V.
Device HALs
HAL yang tercantum (disediakan) dalam manifes perangkat dan tercantum dalam framework compatibility matrix (FCM).
Device Compatibility Matrix (DCM)
File XML yang menentukan persyaratan vendor pada implementasi framework yang sesuai. Setiap perangkat berisi satu DCM.
Framework Manifest
File XML yang menentukan versi HAL mana yang disediakan oleh sisi framework antarmuka vendor, termasuk image sistem, system_ext, dan produk. HAL dalam manifes framework dinonaktifkan secara dinamis sesuai dengan Target FCM version perangkat.
Framework HALs
HAL yang tercantum sebagai disediakan dalam manifes framework dan tercantum dalam device compatibility matrix (DCM).

Siklus proses FCM dalam codebase

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

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 12 umumnya akan memiliki level FCM 6, tetapi dapat menerapkan level FCM 7 atau yang lebih tinggi, yang mengubah perilaku Android dan memaksa penggunaan API vendor yang lebih baru seperti yang ditentukan dalam matriks kompatibilitas. Level yang didukung untuk Android 16 adalah:

FCM Versi Android
6 Android 12/S
7 Android 13/T
8 Android 14/U
202404 Android 15/V
202504 Android 16/B

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

Saat Project Treble diumumkan, image sistem Android dibuat agar kompatibel dengan tiga versi implementasi vendor sebelumnya (total empat). Untuk mendukung masa pakai perangkat yang lebih lama, rentang ini telah ditingkatkan untuk mendukung versi FCM saat ini dan enam versi sebelumnya (total tujuh) untuk 202404 dan yang lebih baru.

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

Mengembangkan dalam versi FCM baru

Android meningkatkan 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 dalam FCM Version F baru:

  1. Salin compatibility_matrix.<F-1>.xml terbaru ke compatibility_matrix.F.xml.
  2. Perbarui atribut level dalam file ke F.
  3. 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 version 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 AIDL HAL dihitung sebagai versi HAL minor. Versi antarmuka HIDL memiliki major.minor versi seperti 1.2.

Selama pengembangan, saat AIDL HAL memiliki upgrade versi dari 2 ke 3 di FCM Version F saat ini, 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 (major)

Selama pengembangan, saat HAL memiliki upgrade versi utama di FCM Version F, 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 <hal> tag yang sama, jika perangkat yang dikirimkan dengan V = F dapat diluncurkan dengan versi utama yang lebih lama.

Misalnya, FCM version F memperkenalkan foo@2.0 sebagai upgrade versi utama HAL 1.0 dan menghentikan HAL 1.0. Versi lama, foo@1.0, digunakan untuk perangkat yang menargetkan versi FCM sebelumnya. Perangkat yang menargetkan FCM version 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 version F tidak boleh menyediakan HAL 1.0 (karena HAL ini dianggap tidak digunakan lagi).
  • Karena HAL 1.0 ada di FCM Version lama, framework masih dapat berfungsi dengan HAL 1.0 sehingga kompatibel dengan perangkat lama yang menargetkan versi FCM lama.

Versi FCM baru

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

  1. Pastikan compatibility_matrix.F.xml memiliki atribut level="F".
  2. Pastikan semua perangkat di-build dan di-boot.
  3. Perbarui pengujian VTS untuk memastikan perangkat yang diluncurkan dengan framework terbaru (berdasarkan level API Shipping) memiliki Target FCM Version V >= F.
  4. Publikasikan 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 di partisi produk dan system_ext dilakukan oleh pemilik image ini. Nomor versi FCM di partisi produk dan system_ext harus selaras dengan yang ada di partisi sistem. Mirip dengan versi FCM di partisi sistem, matriks kompatibilitas di FCM version F dalam partisi produk dan system_ext mencerminkan persyaratan pada perangkat dengan target FCM version F.

Penghentian versi HAL

Penghentian HAL Version adalah keputusan developer (yaitu untuk HAL AOSP, Google membuat keputusan). Hal ini dapat terjadi saat HAL version yang lebih tinggi (baik minor maupun major) dirilis.

Menghentikan HAL perangkat

Jika HAL perangkat tertentu foo@x.y dihentikan di FCM Version F, artinya perangkat yang diluncurkan dengan Target FCM Version V = F atau yang lebih baru tidak boleh menerapkan foo di versi x.y atau versi yang lebih lama dari x.y. HAL version yang dihentikan masih didukung oleh framework untuk mengupgrade perangkat.

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

  • 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 HAL framework

Jika HAL framework tertentu foo@x.y dihentikan di FCM Version F, artinya perangkat yang diluncurkan dengan Target FCM Version V = F atau yang lebih baru tidak boleh mengharapkan framework untuk menyediakan foo di versi x.y, atau di versi yang lebih lama dari x.y. HAL version yang dihentikan masih disediakan oleh framework untuk mengupgrade perangkat.

Saat FCM version F dirilis, HAL Version 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. Device compatibility matrix di perangkat yang diluncurkan dengan V = F tidak boleh mencantumkan framework HAL dengan max-level < V.

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

Penghapusan dukungan untuk target FCM version

Kami menggunakan proses berbasis jadwal untuk menentukan penghapusan target FCM version, guna mempertahankan kompatibilitas untuk durasi yang diperlukan dan mendukung persyaratan partner untuk perangkat yang lebih tahan lama.

Saat kami menghapus target FCM version dari set SF rilis framework berikutnya, kami melakukan kedua langkah berikut:

  1. Menghapus compatibility_matrix.V.xml dari aturan build (agar tidak diinstal pada image sistem), dan menghapus kode apa pun yang menerapkan atau bergantung pada kemampuan yang dihapus.

  2. Menghapus HAL framework dengan max-level yang lebih rendah dari atau sama dengan V dari manifes framework, dan menghapus kode apa pun yang menerapkan HAL framework yang dihapus.

Penghentian bertahap untuk konfigurasi rilis

Strategi percabangan Trunk Stable, tempat Quarterly Platform Releases (QPR) diambil langsung dari git_main, bukan cabang release-dev terpisah, memerlukan proses penghentian bertahap. Versi FCM dapat dihapus untuk sinyal awal dalam build trunk_staging sambil tetap didukung di cabang rilis untuk mengakomodasi perangkat yang menggunakan QPR sepanjang tahun.

Biasanya, rilis framework mendukung enam FCM: satu versi saat ini, empat versi sebelumnya, dan satu versi tambahan untuk mendukung QPR. Jumlah ini dapat meningkat jika versi FCM tertentu (seperti 202404 Android 15) memiliki dukungan yang diperpanjang untuk masa pakai perangkat.

Perangkat dengan Target FCM Version di luar SF untuk rilis framework tertentu tidak dapat mengupgrade ke rilis tersebut.

Penghapusan HAL yang sepenuhnya dihentikan

Saat versi FCM dihapus, beberapa antarmuka HAL, atau versi antarmuka HAL, tidak lagi ada di FCM mana pun. Artinya, Android tidak lagi mendukungnya 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 di 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.

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

Status versi HAL

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

Belum dirilis

Untuk HAL perangkat, jika HAL Version tidak ada dalam matriks kompatibilitas publik dan dibekukan, HAL tersebut dianggap belum dirilis dan mungkin masih dalam pengembangan. Hal ini mencakup HAL Version 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, HAL tersebut dianggap belum dirilis.

Dirilis dan saat ini

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

Jika HAL Version ada dalam matriks kompatibilitas publik dan dibekukan yang memiliki FCM Version tertinggi, HAL version tersebut saat ini (yaitu tidak dihentikan). Misalnya, HAL Version yang ada (seperti nfc@1.0 yang diperkenalkan di compatibility_matrix.legacy.xml) yang terus ada di compatibility_matrix.3.xml juga dianggap sebagai HAL Version yang dirilis dan saat ini.

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

Dirilis tetapi dihentikan

Untuk HAL perangkat, HAL Version dihentikan jika dan hanya jika semua hal berikut terpenuhi:

  • HAL tersebut dirilis.
  • HAL tersebut tidak ada dalam matriks kompatibilitas publik dan dibekukan yang memiliki FCM Version tertinggi.
  • HAL tersebut ada dalam matriks kompatibilitas publik dan dibekukan yang masih didukung oleh framework.

Contoh:

Oleh karena itu, power@1.0 saat ini, tetapi TIDAK dihentikan, di Android 9.

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

Dihapus

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

  • HAL tersebut sebelumnya dirilis.
  • HAL tersebut tidak ada dalam matriks kompatibilitas publik dan dibekukan yang didukung oleh framework.

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

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

  • HAL tersebut sebelumnya dirilis.
  • HAL tersebut tidak ada dalam manifes framework dari cabang rilis terbaru.

FCM lama

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

Jika file ini ada untuk FCM dengan versi F, perangkat non-Treble dapat diupgrade ke F asalkan manifes perangkatnya kompatibel dengan file ini. Penghapusannya mengikuti prosedur yang sama seperti FCM untuk Target FCM Version lainnya (dihapus setelah jumlah perangkat aktif sebelum 8.0 turun di bawah batas 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.