Rilis framework Android memiliki beberapa Framework Compatibility Matrix (FCM)—satu untuk setiap Versi FCM Target yang dapat diupgrade—yang menentukan apa yang mungkin digunakan framework dan persyaratan versi Target FCM. Sebagai bagian dari siklus hidup FCM, Android tidak lagi menggunakan dan menghapus HIDL HAL, lalu memodifikasi file FCM untuk mencerminkan status Versi HAL .
Untuk mengaktifkan OTA hanya kerangka kerja di ekosistem mereka sendiri, mitra yang memperluas antarmuka vendor juga harus menghentikan dan menghapus HIDL HAL menggunakan metode yang sama.
Terminologi
Matriks Kompatibilitas Kerangka (FCM) | File XML yang menentukan persyaratan kerangka kerja pada implementasi vendor yang sesuai. Matriks kompatibilitas diversi, dan versi baru dibekukan untuk setiap rilis kerangka kerja. Setiap rilis kerangka kerja berisi beberapa FCM. |
---|---|
Versi FCM Platform (S F ) | Kumpulan semua versi FCM dalam rilis framework. Kerangka kerja dapat bekerja dengan implementasi vendor apa pun yang memenuhi salah satu FCM ini. |
Versi FCM (P) | Versi tertinggi di antara semua FCM dalam rilis framework. |
Versi FCM Target (V) | Versi FCM yang ditargetkan (dari S F ), dinyatakan secara eksplisit dalam manifes perangkat, yang dipenuhi oleh implementasi vendor. Implementasi vendor harus dibuat terhadap FCM yang dipublikasikan, meskipun mungkin mendeklarasikan versi HAL yang lebih baru dalam Manifes Perangkatnya. |
Versi HAL | Versi HAL memiliki format foo@xy , di mana foo adalah nama HAL dan xy adalah versi spesifiknya; 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 mana yang disediakan oleh sisi perangkat dari antarmuka vendor, termasuk vendor dan gambar ODM. Konten manifes perangkat dibatasi oleh versi Target FCM perangkat tetapi dapat mencantumkan HAL yang benar-benar lebih baru relatif terhadap FCM yang sesuai dengan V. |
Perangkat HAL | HAL yang terdaftar (disediakan) dalam manifes perangkat dan terdaftar (baik diperlukan atau opsional) dalam matriks kompatibilitas kerangka kerja (FCM). |
Matriks Kompatibilitas Perangkat (DCM) | File XML yang menetapkan persyaratan vendor tentang implementasi kerangka kerja yang sesuai. Setiap perangkat berisi satu DCM. |
Manifes Kerangka | File XML yang menentukan versi HAL mana yang disediakan oleh sisi kerangka kerja antarmuka vendor, termasuk sistem, system_ext, dan gambar produk. HAL dalam manifes kerangka kerja dinonaktifkan secara dinamis sesuai dengan versi Target FCM perangkat. |
Kerangka HAL | HAL yang terdaftar sebagaimana disediakan dalam manifes kerangka kerja dan terdaftar sebagai wajib atau opsional dalam matriks kompatibilitas perangkat (DCM). |
Berkembang dalam Versi FCM baru
Android menambah Versi FCM untuk setiap rilis framework (seperti Android 8, 8.1, dll). Selama pengembangan, compatibility_matrix.current.xml
baru dibuat ( F
) dan compatibility_matrix.f.xml
yang ada (di mana f
< F
) tidak lagi diubah.
Untuk mulai mengembangkan di FCM Versi F
baru :
- Salin
compatibility_matrix.<F-1>.xml
terbaru kecompatibility_matrix.current.xml
. - Perbarui atribut
level
dalam file keF
. - 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.current.xml
dengan pengaturan optional
berikut:
-
optional="false"
jika perangkat yang dikirimkan denganV = F
harus diluncurkan dengan HAL ini,
ATAU -
optional="true"
jika perangkat yang dikirimkan denganV = F
dapat diluncurkan tanpa HAL ini.
Misalnya, Android 8.1 memperkenalkan cas@1.0
sebagai HAL opsional. Perangkat yang diluncurkan dengan Android 8.1 tidak diperlukan untuk mengimplementasikan HAL ini, jadi entri berikut telah ditambahkan ke compatibility_matrix.current.xml
(diganti namanya menjadi compatibility_matrix.2.xml
setelah Android 8.1 dirilis):
<hal format="hidl" optional="true"> <name>android.hardware.cas</name> <version>1.0</version> <interface> <name>IMediaCasService</name> <instance>default</instance> </interface> </hal>
Meningkatkan HAL (minor)
Selama pengembangan, ketika HAL memiliki peningkatan versi minor dari xz
ke x.(z+1)
pada FCM Versi F
saat ini, jika versi tersebut adalah:
- Diperlukan pada perangkat yang diluncurkan dengan
V = F
,compatibility_matrix.current.xml
harus menyatakanx.(z+1)
danoptional="false"
. - Tidak diperlukan pada perangkat yang diluncurkan dengan
V = F
,compatibility_matrix.current.xml
harus menyalinxy-z
dan opsionalitas daricompatibility_matrix.<F-1>.xml
dan mengubah versi menjadixw-(z+1)
(di manaw >= y
).
Misalnya, Android 8.1 memperkenalkan broadcastradio@1.1
sebagai versi minor peningkatan versi 1.0 HAL. Versi yang lebih lama, broadcastradio@1.0
, adalah opsional untuk perangkat yang diluncurkan dengan Android 8.0 sedangkan versi yang lebih baru, broadcastradio@1.1
, adalah opsional untuk perangkat yang diluncurkan dengan Android 8.1. Dalam compatibility_matrix.1.xml
:
<hal format="hidl" optional="true"> <name>android.hardware.broadcastradio</name> <version>1.0</version> <interface> <name>IBroadcastRadioFactory</name> <instance>default</instance> </interface> </hal>
Entri ini disalin ke compatibility_matrix.current.xml
(berganti nama menjadi compatibility_matrix.2.xml
setelah Android 8.1 dirilis) dan dimodifikasi sebagai berikut:
<hal format="hidl" optional="true"> <name>android.hardware.broadcastradio</name> <version>1.0-1</version> <interface> <name>IBroadcastRadioFactory</name> <instance>default</instance> </interface> </hal>
Meningkatkan HAL (utama)
Selama pengembangan, ketika HAL memiliki peningkatan versi utama pada FCM Versi F
saat ini, versi utama baru x.0
ditambahkan ke compatibility_matrix.current.xml
dengan pengaturan optional
berikut:
-
optional="false"
dengan hanya versix.0
, jika perangkat yang dikirimkan denganV = F
harus diluncurkan denganx.0
. -
optional="false"
tetapi bersama dengan versi utama yang lebih lama dalam tag<hal>
yang sama, jika perangkat yang dikirimkan denganV = F
harus diluncurkan dengan HAL ini, tetapi dapat diluncurkan dengan versi utama yang lebih lama. -
optional="true"
jika perangkat yang dikirimkan denganV = F
tidak harus meluncurkan HAL.
Misalnya, Android 9 memperkenalkan health@2.0
sebagai peningkatan versi utama dari 1.0 HAL dan menghentikan 1.0 HAL. Versi yang lebih lama, health@1.0
, adalah opsional untuk perangkat yang diluncurkan dengan Android 8.0 dan Android 8.1. Perangkat yang diluncurkan dengan Android 9 tidak boleh menyediakan 1.0 HAL yang tidak digunakan lagi dan harus menyediakan versi 2.0 yang baru. Dalam compatibility_matrix.legacy.xml
, compatibility_matrix.1.xml
, dan compatibility_matrix.2.xml
:
<hal format="hidl" optional="true"> <name>android.hardware.health</name> <version>1.0</version> <interface> <name>IHealth</name> <instance>default</instance> </interface> </hal>
Entri ini disalin ke compatibility_matrix.current.xml
(diganti namanya menjadi compatibility_matrix.3.xml
dengan rilis Android 9) dan dimodifikasi sebagai berikut:
<hal format="hidl" optional="false"> <name>android.hardware.health</name> <version>2.0</version> <interface> <name>IHealth</name> <instance>default</instance> </interface> </hal>
Pembatasan:
- Karena 2.0 HAL ada di
compatibility_matrix.3.xml
denganoptional="false"
, perangkat yang diluncurkan dengan Android 9 harus dikirimkan dengan 2.0 HAL. - Karena 1.0 HAL tidak ada dalam
compatibility_matrix.3.xml
, perangkat yang diluncurkan dengan Android 9 tidak boleh menyediakan 1.0 HAL (karena HAL ini dianggap tidak digunakan lagi). - Karena 1.0 HAL hadir di legacy/1/2.xml (Versi FCM lama yang dapat digunakan oleh Android 9) sebagai HAL opsional, framework Android 9 masih dapat bekerja dengan 1.0 HAL (yang tidak dianggap sebagai Versi HAL yang dihapus ).
Versi FCM Baru
Proses merilis Versi FCM di partisi sistem dilakukan sepenuhnya oleh Google sebagai bagian dari rilis AOSP dan mencakup langkah-langkah berikut:
- Ganti nama
compatibility_matrix.current.xml
menjadicompatibility_matrix.F.xml
. - Pastikan file memiliki atribut
level="F"
. - Edit aturan build yang sesuai untuk mencerminkan perubahan nama file.
- Pastikan semua perangkat dibangun dan di-boot.
- Perbarui pengujian VTS untuk memastikan perangkat yang diluncurkan dengan kerangka kerja terbaru (berdasarkan level API Pengiriman) memiliki Target FCM Versi
V >= F
. - Publikasikan file ke AOSP.
File ini tidak dapat diubah setelah diganti namanya dan diterbitkan. Misalnya, selama pengembangan Android 9, file berikut dibuat untuk hardware/interfaces/compatibility_matrices/
:
-
compatibility_matrix.legacy.xml
-
compatibility_matrix.1.xml
-
compatibility_matrix.2.xml
-
compatibility_matrix.current.xml
Saat Android 9 dirilis, compatibility_matrix.current.xml
diganti namanya menjadi compatibility_matrix.3.xml
dan file berikut dibuat untuk hardware/interfaces/compatibility_matrices/
:
-
compatibility_matrix.legacy.xml
-
compatibility_matrix.1.xml
-
compatibility_matrix.2.xml
-
compatibility_matrix.3.xml
Tes 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 produk dan partisi system_ext masing-masing dilakukan oleh pemilik gambar ini. Nomor versi FCM pada produk dan partisi system_ext harus sejajar dengan yang ada di partisi sistem. Mirip dengan versi FCM di partisi sistem, matriks kompatibilitas di FCM versi F di produk dan partisi system_ext mencerminkan persyaratan pada perangkat dengan target FCM versi F.
Penghentian Versi HAL
Menghentikan Versi HAL adalah keputusan pengembang (yaitu untuk AOSP HAL, Google membuat keputusan). Itu bisa terjadi ketika versi HAL yang lebih tinggi (baik minor atau mayor) dirilis.
Menghentikan perangkat HAL
Ketika perangkat tertentu HAL foo@xy
tidak digunakan lagi di FCM Versi F
, itu berarti bahwa perangkat apa pun yang diluncurkan dengan Target FCM Versi V = F
atau yang lebih baru tidak boleh mengimplementasikan foo
pada versi xy
atau versi apa pun yang lebih lama dari xy
. Versi HAL yang tidak digunakan lagi masih didukung oleh kerangka kerja untuk memutakhirkan perangkat.
Saat FCM Versi F
dirilis, Versi HAL foo@xy
dianggap tidak digunakan lagi jika Versi HAL tertentu tidak secara eksplisit dinyatakan dalam FCM terbaru untuk Target FCM Versi V = F
. Untuk perangkat yang diluncurkan dengan V = F
, salah satu kondisi berikut ini benar:
- Kerangka kerja membutuhkan versi yang lebih tinggi (mayor atau minor);
- Kerangka kerja tidak memerlukan HAL lagi.
Misalnya, di Android 9, health@2.0
diperkenalkan sebagai peningkatan versi utama dari 1.0 HAL. 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 kerangka kerja HAL
Ketika kerangka kerja tertentu HAL foo@xy
tidak digunakan lagi di FCM Versi F
, itu berarti bahwa setiap perangkat yang diluncurkan dengan Target FCM Versi V = F
atau yang lebih baru tidak boleh mengharapkan kerangka kerja untuk menyediakan foo
pada versi xy
, atau pada versi apa pun yang lebih lama dari xy
. Versi HAL yang tidak digunakan lagi masih disediakan oleh kerangka kerja untuk memutakhirkan perangkat.
Saat FCM versi F
dirilis, Versi HAL foo@xy
dianggap tidak digunakan lagi jika manifes kerangka kerja menetapkan max-level=" F - 1 "
untuk foo@xy
. Untuk perangkat yang diluncurkan dengan V = F
, framework tidak menyediakan HAL foo@xy
. Matriks kompatibilitas perangkat pada perangkat yang diluncurkan dengan V = F
tidak boleh mencantumkan kerangka kerja HAL dengan max-level < V
.
Misalnya, di Android 12, schedulerservice@1.0
tidak digunakan lagi. Atribut max-level
disetel ke 5
, versi FCM yang diperkenalkan di Android 11. Lihat manifes kerangka kerja Android 12 .
Penghapusan dukungan untuk Versi Target FCM
Saat perangkat aktif dari Target FCM Version V
tertentu turun di bawah ambang batas tertentu, Target FCM Version akan dihapus dari set SF dari rilis framework berikutnya. Ini dilakukan dengan kedua langkah berikut:
- Menghapus
compatibility_matrix.V.xml
dari aturan build (sehingga tidak diinstal pada citra sistem), dan menghapus kode apa pun yang diterapkan atau bergantung pada fungsionalitas yang dihapus. - Menghapus HAL framework dengan
max-level
lebih rendah dari atau sama denganV
dari manifes framework, dan menghapus kode apa pun yang mengimplementasikan HAL framework yang dihapus.
Perangkat dengan Versi FCM target di luar SF untuk rilis framework tertentu tidak dapat diupgrade ke rilis tersebut.
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, itu dianggap belum dirilis dan mungkin dalam pengembangan. Ini termasuk Versi HAL yang hanya ada di compatibility_matrix.current.xml
. Contoh:
- Selama pengembangan Android 9 (sebelum
compatibiility_matrix.current.xml
diubah namanya menjadicompatibility_matrix.3.xml
),health@2.0
HAL dianggap sebagai HAL yang belum dirilis. -
teleportation@1.0
HAL tidak ada dalam matriks kompatibilitas yang dirilis, dan juga dianggap sebagai HAL yang belum dirilis.
Untuk kerangka HAL, jika versi HAL hanya dalam manifes kerangka dari cabang pengembangan yang tidak terkait, itu dianggap belum dirilis.
Dirilis dan Saat Ini
Untuk HAL perangkat, jika Versi HAL ada dalam matriks kompatibilitas publik dan beku, itu akan dirilis. Misalnya, setelah FCM Versi 3 dibekukan (ketika compatibiility_matrix.current.xml
diubah namanya menjadi compatibility_matrix.3.xml
) 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 (tidak termasuk compatibility_matrix.current.xml
), versi HAL adalah yang terbaru (yaitu tidak usang). Misalnya, Versi HAL yang ada (seperti nfc@1.0
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 kerangka HAL, jika versi HAL ada dalam manifes kerangka kerja cabang terbaru yang dirilis tanpa atribut max-level
atau (tidak biasanya) level max-level
sama dengan atau lebih tinggi dari versi FCM yang dirilis di cabang ini, ini dianggap sebagai versi dirilis dan versi HAL saat ini. Misalnya, layanan displayservice
HAL dirilis dan saat ini di Android 12, seperti yang ditentukan oleh Android 12framework manifest
.
Dirilis tapi Usang
Untuk HAL perangkat, Versi HAL tidak digunakan lagi jika dan hanya jika semua hal berikut terpenuhi:
- Hal ini dirilis.
- Bukan dalam matriks kompatibilitas publik dan beku yang memiliki Versi FCM tertinggi.
- Dalam matriks kompatibilitas publik dan beku yang masih didukung oleh kerangka kerja.
Contoh:
- HAL
health@1.0
ada di dalamcompatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
, dancompatibility_matrix.2.xml
, tetapi tidak dalamcompatibility_matrix.3.xml
. Oleh karena itu dianggap usang di Android 9. - Power HAL memiliki peningkatan versi minor di Android 9, tetapi
power@1.0
masih dalamcompatibility_matrix.3.xml
.-
power@1.0
ada dicompatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
, dancompatibility_matrix.2.xml
. -
compatibility_matrix.3.xml
memilikipower@1.0-1
.
-
Karenanya power@1.0
saat ini, tetapi TIDAK ditinggalkan, di Android 9.
Untuk kerangka HAL, jika versi HAL ada dalam manifes kerangka kerja cabang terbaru yang dirilis dengan atribut max-level
lebih rendah dari versi FCM yang dirilis di cabang ini, itu dianggap sebagai versi HAL yang dirilis tetapi tidak digunakan lagi. Misalnya, layanan schedulerservice
HAL dirilis tetapi tidak digunakan lagi di Android 12, seperti yang ditentukan oleh Android 12framework manifest
.
DIHAPUS
Untuk HAL perangkat, Versi HAL dihapus jika dan hanya jika hal berikut ini benar:
- Itu dirilis sebelumnya.
- Tidak ada matriks kompatibilitas publik dan beku yang didukung oleh kerangka kerja.
Matriks kompatibilitas yang bersifat publik, dibekukan, tetapi tidak didukung oleh kerangka kerja disimpan dalam basis kode untuk menentukan kumpulan Versi HAL yang dihapus sehingga pengujian VTS dapat ditulis untuk memastikan HAL yang dihapus tidak ada di perangkat baru.
Untuk kerangka HAL, versi HAL dihapus jika dan hanya jika hal berikut terpenuhi:
- Itu dirilis sebelumnya.
- Itu tidak ada dalam manifes kerangka kerja apa pun dari cabang terbaru yang dirilis.
FCM lama
Target Versi FCM Legacy adalah nilai khusus untuk semua perangkat non-Treble. FCM lawas, compatibility_matrix.legacy.xml
, mencantumkan persyaratan kerangka kerja pada perangkat lawas (yaitu perangkat yang diluncurkan sebelum Android 8.0).
Jika file ini ada untuk FCM dengan versi F
, perangkat non-Treble apa pun dapat ditingkatkan 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 yang aktif turun di bawah ambang batas tertentu).
Versi FCM yang dirilis
Daftar versi FCM yang dirilis dapat ditemukan di hardware/interfaces/compatibility_matrices
.
Untuk menemukan versi FCM yang dirilis dengan rilis Android tertentu, lihat Level.h
.