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.
Referans uygulama, iki katmanlı bir mimariye dayanır. Üst katmanda DefaultVehicleHal, VHAL AIDL arayüzünü uygular ve tüm donanım cihazları için genel VHAL mantığı sağlar. Alt katmanda FakeVehicleHardware,
IVehicleHardware arayüzünü uygular. Bu sınıf, gerçek donanım veya araç veriyoluyla etkileşime geçmenin VHAL mantığını simüle eder ve cihaza özeldir. İsteğe bağlı olarak tedarikçi firmalar bu mimariyi uyarlayabilir, aynı DefaultVehicleHal sınıfını yeniden kullanabilir (bir yöntemin üzerine yazması için sınıfı genişleterek) ve kendi IVehicleHardware uygulamalarını sağlayabilir.
Şekil 1. VHAL referans uygulaması
DefaultVehicleHal
aşağıdaki mantığı içerir. Bu mantık genel kabul edilir ve herhangi bir VHAL uygulaması için geçerli olabilir.
IVehicle arayüzünü uygular.
Yinelenen kimlikler olup olmadığını kontrol etmek de dahil olmak üzere temel giriş kontrolleri yapar.
Her bağlayıcı istemcisi için her işleme istemci nesneleri (örneğin, GetValuesClient) ayırır ve her birini global bir havuza ekler.
Beklemedeki istek havuzuna bekleyen istek ekleme gibi asenkron geri çağırma mantığını yönetir.
Sonuçları aldığımızda bekleyen istekleri çözer veya bekleyen isteklerden biri zaman aşımına uğradığında hata döndürür.
LargeParcelable değerini serileştirir ve seri dışına çıkarır (ParcelableUtils.h bölümüne bakın).
İzinleri kontrol eder. (checkReadPermission ve checkWritePermission işlevlerine bakın.)
IVehicleHardware.checkHealth işlevini düzenli olarak çağırır ve kalp atışı sinyalleri gönderir (checkHealth işlevine bakın).
IVehicleHardware, VHAL'ın donanıma özgü uygulamasını temsil etmek için kullanılan genel bir arayüzdür. IVehicleHardware için referans uygulama, mülk değerini depolamak için bellek içi bir harita kullanan ve gerçek bir araç otobüsü ile iletişim kurmayan FakeVehicleHardware'dir. Bir emülatörde çalışacak şekilde tasarlanmıştır ve donanıma özgü bağımlılıklara sahip değildir. Tedarikçi firma uygulamaları bu protokolü olduğu gibi kullanmamalı ve araç otobüsüne özgü mantık eklemelidir.
Android 14'ten itibaren FakeVehicleHardware, desteklenen mülk yapılandırmasını, JSON stilinde yapılandırma dosyası içeren cihazın /vendor/etc/automotive/vhalconfig/ klasöründen, çalıştırma zamanında başlatma sırasında okur. Yapılandırma dosyası biçimi ve yapılandırma dosyası içeriği için referans VHAL README dosyasına bakın.
FakeVehicleHardware, test için yapılandırma dosyasını geçersiz kılmayı da destekler. persist.vendor.vhal_init_value_override sistem özelliği ayarlanmışsa (bu özellik, derleme sırasında veya VHAL başlatılmadan önce önyükleme sırasında çok erken ayarlanmalıdır) mevcut yapılandırmayı geçersiz kılmak için cihazdaki /vendor/etc/automotive/vhaloverride/ klasöründeki yapılandırma dosyasını kullanır. Tedarikçi firma uygulamasında, VHAL tarafından desteklenen mülk yapılandırmasının sabit kodlanmaması ve başlangıç zamanında dinamik olarak karar verilebilmesi için benzer bir yaklaşım kullanılabilir.
VHAL başlatıldıktan sonra araç özelliği yapılandırmalarının listesi statik olmalıdır.
Android 16'dan itibaren GRPCVehicleHardware, IVehicleHardware için başka bir referans uygulama sağlar. Bu uygulamada, uzak bir makinede veya sanal makinede mülk işleme mantığını içeren ayrı bir sunucu olduğu varsayılır. AAOS cihazlarda çalışan VHAL, istekleri uzak sunucuya yönlendiren bir proxy gibi çalışır. Daha fazla bilgi için grpc bölümüne bakın.
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-26 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-26 UTC."],[],[],null,["# Reference implementation\n\nWe provide a\n[reference implementation](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current)\nfor the AIDL VHAL. The main service thread is implemented\nat\n[`VehicleService.cpp`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/vhal/src/VehicleService.cpp).\nThe VHAL interface implementation is located at\n[`DefaultVehicleHal.cpp`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/vhal/src/DefaultVehicleHal.cpp).\n\n\nThe reference implementation is based on a two-layer architecture. On the upper layer,\n`DefaultVehicleHal`, implements VHAL AIDL interface and provides VHAL logic\ngeneric to all hardware devices. On the lower layer, `FakeVehicleHardware`,\nimplements the `IVehicleHardware` interface. This class simulates the VHAL logic\nof interacting with actual hardware or vehicle bus and is device-specific. Optionally, vendors\ncan adapt this same architecture, reuse the same `DefaultVehicleHal` class (extending\nit to overwrite a method), and provide their own `IVehicleHardware` implementation.\n**Figure 1.** VHAL reference implementation\n\n[`DefaultVehicleHal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/vhal/src/DefaultVehicleHal.cpp)\ncontains the following logic, which is considered to be generic and can apply to any VHAL\nimplementation.\n\n- Implements the `IVehicle` interface.\n- Performs basic input checks, including a check for duplicate IDs.\n- Allocates client objects (for example, `GetValuesClient`) for each operation for each binder client, and adds each to a global pool.\n- Manages async callbacks logic, such as adding a pending request to a pending request pool. Resolves pending requests when we receive the results or returns error when one of the pending requests times out.\n- Serializes and deserializes `LargeParcelable` (see `ParcelableUtils.h`).\n- Manages subscription (see `SubscriptionManager.h`).\n- Checks permissions. (See the `checkReadPermission` and `checkWritePermission` functions).\n- Periodically calls `IVehicleHardware.checkHealth` and sends heartbeat signals (see the `checkHealth` function).\n\n[`IVehicleHardware`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/hardware/include/IVehicleHardware.h)\nis a generic interface used to represent a VHAL's hardware-specific\nimplementation. The reference implementation for `IVehicleHardware` is\n[`FakeVehicleHardware`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/fake_impl/hardware/src/FakeVehicleHardware.cpp),\nwhich uses an in-memory map to store property value and does\nnot communicate with an actual vehicle bus. It's intended to run on an emulator and have no\nhardware-specific dependencies. Vendor implementations must not use it as-is and must add\nvehicle bus-specific logic.\n\nStarting in Android 14, `FakeVehicleHardware` reads the supported property config at run-time\nduring initialization from the device's `/vendor/etc/automotive/vhalconfig/` folder,\nwhich contains a JSON-style config file. See the\n[reference VHAL README file](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/default_config/config/README.md)\nfor config file format and config file content.\n\n`FakeVehicleHardware` also supports config file override for testing. If the\nsystem property `persist.vendor.vhal_init_value_override` is set (this property must be\nset at build time or very early during boot before VHAL initialization), it uses the config\nfile from the `/vendor/etc/automotive/vhaloverride/` folder on the device to override\nthe existing configuration. A vendor implementation can use a similar approach so that the VHAL-\nsupported property configuration is not hard-coded and can be dynamically decided at start time.\nThe list of vehicle property configs must be static after VHAL is initialized.\n\nStarting in Android 16, [`GRPCVehicleHardware`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/grpc/GRPCVehicleHardware.cpp)\nprovides another reference `IVehicleHardware` implementation. This implementation\nassumes there is a separate server running on a remote machine or VM which contains the property\nhandling logic. The VHAL running on AAOS devices acts as a proxy that forwards requests to\nthe remote server. See [grpc](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/README.md#grpc)\nfor more details."]]
