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.
Objek antarmuka vendor
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Dokumen ini menjelaskan desain objek antarmuka vendor
(objek VINTF), yang menggabungkan informasi yang relevan tentang perangkat dan menyediakan
informasi tersebut melalui API yang dapat dikueri.
Desain objek VINTF
Objek VINTF mengumpulkan beberapa informasi yang diperlukannya langsung dari
perangkat. Aspek lainnya, seperti manifes, dijelaskan secara statis dalam
XML.
Gambar 1. Manifes, matriks kompatibilitas, dan informasi yang dapat dikumpulkan runtime.
Desain objek VINTF menyediakan hal berikut untuk komponen perangkat dan
framework:
| Untuk Perangkat |
Untuk Framework |
- Menentukan skema untuk komponen statis (file
manifes
perangkat).
- Menambahkan dukungan waktu build untuk menentukan file manifes perangkat untuk perangkat
tertentu.
- Menentukan
API
yang dapat dikueri saat runtime yang mengambil file manifes perangkat (beserta
informasi runtime lainnya yang dapat dikumpulkan) dan mengemasnya ke dalam hasil kueri.
|
|
Objek VINTF harus andal dan memberikan informasi lengkap yang sama
terlepas dari kapan objek diminta (lihat
Perhatian).
Manifes dan matriks
Mulai Android 8.0, API runtime membuat kueri tentang apa yang ada di perangkat dan mengirim
informasi tersebut ke server update
Over-the-Air (OTA) dan pihak lain yang berkepentingan (seperti CTS
DeviceInfo). Beberapa informasi diambil saat runtime dan beberapa
didefinisikan secara statis.
- Manifes perangkat menjelaskan komponen statis dari
apa yang dapat disediakan perangkat ke framework.
- Matriks kompatibilitas framework menjelaskan hal yang
diharapkan framework Android dari perangkat tertentu. Matriks adalah entity statis
yang komposisinya ditentukan secara manual selama pengembangan rilis
berikutnya dari framework Android.
- Manifes framework menjelaskan layanan tingkat tinggi yang
dapat disediakan framework ke perangkat.
- Matriks kompatibilitas perangkat menjelaskan layanan
yang diperlukan image vendor dari framework. Komposisinya ditentukan secara manual
selama pengembangan perangkat.
Kedua pasangan manifes dan matriks ini harus direkonsiliasi pada waktu OTA untuk
memastikan perangkat dapat mendapatkan update framework yang kompatibel dengan kemampuan
perangkat. Secara umum, manifes menjelaskan apa yang disediakan dan
matriks kompatibilitas menjelaskan apa yang diperlukan.
Bagian ini mencakup detail berikut tentang manifes dan matriks:
- Manifes menentukan
manifes perangkat, manifes framework, dan skema file manifes.
- Matriks
Kompatibilitas menentukan skema untuk matriks kompatibilitas.
- Siklus Proses FCM menjelaskan
cara HAL HIDL tidak digunakan lagi dan dihapus serta cara file FCM diubah untuk
mencerminkan status Versi HAL.
- Pengembangan DM menjelaskan
cara vendor dapat menentukan dan mendeklarasikan Versi FCM Target dalam manifes
perangkat untuk perangkat baru atau menerapkan versi HAL baru dan menambahkan
Versi FCM Target saat mengupgrade image vendor untuk perangkat lama.
- Aturan Pencocokan
menentukan aturan untuk pencocokan yang berhasil antara matriks kompatibilitas dan
manifes.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-27 UTC."],[],[],null,["# Vendor interface object\n\nThis document describes the design of the *vendor interface object*\n(VINTF object), which aggregates relevant information about a device and makes\nthat information available through a *queryable API*.\n\nVINTF object design\n-------------------\n\nA VINTF object gathers some of the information it needs directly from the\ndevice. Other aspects, such as the manifests, are described statically in\nXML.\n\n**Figure 1.** Manifests, compatibility matrixes, and runtime-collectible information.\n\nVINTF object design provides the following for device and framework\ncomponents:\n\n| For the Device | For the Framework |\n|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| - Defines a schema for the static component (the [device manifest file](/docs/core/architecture/vintf/objects#device-manifest-file)). - Adds build time support for defining the device manifest file for a given device. - Defines the [queryable API](/docs/core/architecture/vintf/objects#queryable-api) at runtime that retrieves the device manifest file (along with the other runtime-collectible information) and packages them into the query result. | - Defines a schema for the static component (the [framework manifest file](/docs/core/architecture/vintf/objects#framework-manifest-file)). - Defines the [queryable API](/docs/core/architecture/vintf/objects#queryable-api) at runtime that retrieves the framework manifest file and packages it into the query result. |\n\nThe VINTF object must be reliable and provide the same complete information\nregardless of when the object is requested (see\n[Caveats](/docs/core/architecture/vintf/resources#caveats)).\n\nManifests and matrixes\n----------------------\n\nAs of Android 8.0, a runtime API queries what is on the device and sends that\ninformation to the [Over-the-Air (OTA)](/docs/core/ota)\nupdate server and other interested parties (such as CTS\n`DeviceInfo`). Some information is retrieved at runtime and some of\nit is statically-defined.\n\n- The **device manifest** describes the static component of what the device can provide to the framework.\n- The **framework compatibility matrix** describes what the Android framework expects from a given device. The matrix is a static entity whose composition is determined manually during development of the next release of the Android framework.\n- The **framework manifest** describes high-level services the framework can provide to the device.\n- The **device compatibility matrix** describes the services the vendor image requires of the framework. Its composition is determined manually during the development of the device.\n\nThese two pairs of manifests and matrixes must be reconciled at OTA time to\nensure a device can get framework updates that are compatible with the device's\ncapabilities. In general, a *manifest* describes what is provided and a\n*compatibility matrix* describes what is required.\n\nThis section includes the following details on manifests and matrixes:\n\n- [Manifests](/docs/core/architecture/vintf/objects) defines the device manifest, framework manifest, and manifest file schema.\n- [Compatibility\n Matrixes](/docs/core/architecture/vintf/comp-matrices) defines the schema for the compatibility matrix.\n- [FCM Lifecycle](/docs/core/architecture/vintf/fcm) details how HIDL HALs are deprecated and removed and how FCM files are modifed to reflect the status of the HAL Version.\n- [DM Development](/docs/core/architecture/vintf/dm) describes how vendors can define and declare the Target FCM Version in the device manifest for new devices or implement new HAL versions and increment the Target FCM Version when upgrading the vendor image for old devices.\n- [Matching Rules](/docs/core/architecture/vintf/match-rules) defines the rules for a successful match between a compatibility matrix and a manifest."]]
