27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.
Tedarikçi firma arayüzü nesnesi
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Bu dokümanda, bir cihazla ilgili alakalı bilgileri toplayan ve bu bilgileri sorgulanabilir bir API aracılığıyla kullanıma sunan tedarikçi arayüzü nesnesinin (VINTF nesnesi) tasarımı açıklanmaktadır.
VINTF nesnesi tasarımı
VINTF nesnesi, ihtiyaç duyduğu bilgilerin bir kısmını doğrudan cihazdan toplar. Manifestler gibi diğer özellikler XML'de statik olarak açıklanır.
Şekil 1. Manifestler, uyumluluk matrisleri ve çalışma zamanında toplanabilen bilgiler.
VINTF nesne tasarımı, cihaz ve çerçeve bileşenleri için aşağıdakileri sağlar:
| Cihaz için |
Çerçeve için |
- Statik bileşen için bir şema (cihaz manifest dosyası) tanımlar.
- Belirli bir cihazın cihaz manifest dosyasını tanımlamak için derleme zamanı desteği ekler.
- Çalışma zamanında, cihaz manifest dosyasını (çalışma zamanında toplanabilen diğer bilgilerle birlikte) alan ve sorgu sonucuna paketleyen sorgulanabilen API'yi tanımlar.
|
|
VINTF nesnesi güvenilir olmalı ve nesnenin ne zaman istendiğine bakılmaksızın aynı eksiksiz bilgileri sağlamalıdır (Dikkat edilecek noktalar bölümüne bakın).
Manifestler ve matrisler
Android 8.0'dan itibaren bir çalışma zamanı API'si, cihazda ne olduğunu sorgulayarak bu bilgileri kablosuz (OTA) güncelleme sunucusuna ve ilgilenen diğer taraflara (ör. CTSDeviceInfo) gönderir. Bazı bilgiler çalışma zamanında alınır, bazıları ise statik olarak tanımlanır.
- Cihaz manifesti, cihazın çerçeveye sağlayabileceği özelliklerin statik bileşenini tanımlar.
- Çerçeve uyumluluk matrisi, Android çerçevesinin belirli bir cihazdan ne beklediğini açıklar. Matris, Android çerçevesinin bir sonraki sürümünün geliştirilmesi sırasında bileşimi manuel olarak belirlenen statik bir öğedir.
- Çerçeve manifesti, çerçevenin cihaza sağlayabileceği üst düzey hizmetleri açıklar.
- Cihaz uyumluluk matrisi, tedarikçi firma resminin çerçeveden gerektirdiği hizmetleri açıklar. Bu dosyanın içeriği, cihazın geliştirilmesi sırasında manuel olarak belirlenir.
Bir cihazın, cihazın özellikleriyle uyumlu çerçeve güncellemeleri alabilmesi için bu iki manifest ve matris çifti, OTA sırasında uyumlulaştırılmalıdır. Genel olarak, manifest nelerin sağlandığını, uyumluluk matrisi ise nelerin gerekli olduğunu açıklar.
Bu bölümde, manifestler ve matrisler hakkında aşağıdaki ayrıntılar yer alır:
- Manifestler; cihaz manifestini, çerçeve manifestini ve manifest dosyası şemasını tanımlar.
- Uyumluluk Matrisleri, uyumluluk matrisinin şemasını tanımlar.
- FCM Yaşam Döngüsü, HIDL HAL'lerin desteğinin nasıl sonlandırıldığını ve kaldırıldığını ve FCM dosyalarının HAL sürümünün durumunu yansıtacak şekilde nasıl değiştirildiğini ayrıntılı olarak açıklar.
- DM Geliştirme, tedarikçilerin yeni cihazlar için cihaz manifestinde hedef FCM sürümünü nasıl tanımlayıp beyan edebileceğini veya eski cihazlar için tedarikçi firma görüntüsünü yükseltirken yeni HAL sürümlerini nasıl uygulayıp hedef FCM sürümünü nasıl artırabileceğini açıklar.
- Eşleşme Kuralları, bir uyumluluk matrisi ile manifest arasında başarılı bir eşleşme için kuralları tanımlar.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
