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.
Implementasi referensi didasarkan pada arsitektur dua lapisan. Di lapisan atas,
DefaultVehicleHal, mengimplementasikan antarmuka VHAL AIDL dan menyediakan logika VHAL
umum untuk semua perangkat hardware. Di lapisan bawah, FakeVehicleHardware,
mengimplementasikan antarmuka IVehicleHardware. Class ini menyimulasikan logika VHAL
untuk berinteraksi dengan hardware atau bus kendaraan yang sebenarnya dan bersifat khusus perangkat. Secara opsional, vendor
dapat menyesuaikan arsitektur yang sama ini, menggunakan kembali class DefaultVehicleHal yang sama (memperluasnya
untuk menimpa metode), dan menyediakan implementasi IVehicleHardware mereka sendiri.
Gambar 1. Implementasi referensi VHAL
DefaultVehicleHal
berisi logika berikut, yang dianggap generik dan dapat diterapkan ke penerapan
VHAL apa pun.
Mengimplementasikan antarmuka IVehicle.
Melakukan pemeriksaan input dasar, termasuk pemeriksaan ID duplikat.
Mengalokasikan objek klien (misalnya, GetValuesClient) untuk setiap operasi untuk
setiap klien binder, dan menambahkan setiap objek ke kumpulan global.
Mengelola logika callback asinkron, seperti menambahkan permintaan yang tertunda ke kumpulan permintaan yang tertunda.
Menyelesaikan permintaan yang tertunda saat kita menerima hasilnya atau menampilkan error saat salah satu permintaan
yang tertunda habis waktunya.
Melakukan serialisasi dan deserialisasi LargeParcelable (lihat
ParcelableUtils.h).
Memeriksa izin. (Lihat fungsi checkReadPermission dan
checkWritePermission).
Memanggil IVehicleHardware.checkHealth secara berkala dan mengirim sinyal heartbeat (lihat
fungsi checkHealth).
IVehicleHardware
adalah antarmuka generik yang digunakan untuk merepresentasikan implementasi
khusus hardware VHAL. Implementasi referensi untuk IVehicleHardware adalah
FakeVehicleHardware,
yang menggunakan peta dalam memori untuk menyimpan nilai properti dan tidak
berkomunikasi dengan bus kendaraan yang sebenarnya. Aplikasi ini dimaksudkan untuk berjalan di emulator dan tidak memiliki
dependensi khusus hardware. Implementasi vendor tidak boleh menggunakannya apa adanya dan harus menambahkan
logika khusus bus kendaraan.
Mulai Android 14, FakeVehicleHardware membaca konfigurasi properti yang didukung saat runtime
selama inisialisasi dari folder /vendor/etc/automotive/vhalconfig/ perangkat,
yang berisi file konfigurasi bergaya JSON. Lihat
file README VHAL referensi
untuk format file konfigurasi dan konten file konfigurasi.
FakeVehicleHardware juga mendukung penggantian file konfigurasi untuk pengujian. Jika
properti sistem persist.vendor.vhal_init_value_override ditetapkan (properti ini harus
ditetapkan pada waktu build atau sangat awal selama booting sebelum inisialisasi VHAL), properti ini akan menggunakan file
konfigurasi dari folder /vendor/etc/automotive/vhaloverride/ di perangkat untuk mengganti
konfigurasi yang ada. Implementasi vendor dapat menggunakan pendekatan serupa sehingga konfigurasi properti yang didukung
VHAL tidak di-hardcode dan dapat diputuskan secara dinamis pada waktu mulai.
Daftar konfigurasi properti kendaraan harus statis setelah VHAL diinisialisasi.
Mulai Android 16, GRPCVehicleHardware
menyediakan implementasi IVehicleHardware referensi lainnya. Implementasi ini
mengasumsikan ada server terpisah yang berjalan di mesin atau VM jarak jauh yang berisi logika
penanganan properti. VHAL yang berjalan di perangkat AAOS bertindak sebagai proxy yang meneruskan permintaan ke
server jarak jauh. Lihat grpc
untuk mengetahui detail selengkapnya.
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-26 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-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."]]
