Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.
Việc triển khai tham chiếu dựa trên cấu trúc hai lớp. Ở lớp trên, DefaultVehicleHal triển khai giao diện VHAL AIDL và cung cấp logic VHAL chung cho tất cả thiết bị phần cứng. Ở lớp thấp hơn, FakeVehicleHardware, triển khai giao diện IVehicleHardware. Lớp này mô phỏng logic VHAL của việc tương tác với phần cứng thực tế hoặc bus xe và dành riêng cho thiết bị. Nhà cung cấp có thể tuỳ ý điều chỉnh cùng một cấu trúc này, sử dụng lại cùng một lớp DefaultVehicleHal (mở rộng lớp này để ghi đè một phương thức) và cung cấp cách triển khai IVehicleHardware của riêng họ.
Hình 1. Triển khai tham chiếu VHAL
DefaultVehicleHal chứa logic sau đây, được coi là chung và có thể áp dụng cho mọi hoạt động triển khai VHAL.
Triển khai giao diện IVehicle.
Thực hiện các bước kiểm tra đầu vào cơ bản, bao gồm cả việc kiểm tra mã nhận dạng trùng lặp.
Phân bổ đối tượng ứng dụng (ví dụ: GetValuesClient) cho mỗi thao tác cho
mỗi ứng dụng liên kết và thêm từng đối tượng vào một nhóm toàn cục.
Quản lý logic gọi lại không đồng bộ, chẳng hạn như thêm yêu cầu đang chờ xử lý vào nhóm yêu cầu đang chờ xử lý.
Giải quyết các yêu cầu đang chờ xử lý khi chúng tôi nhận được kết quả hoặc trả về lỗi khi một trong các yêu cầu đang chờ xử lý hết thời gian chờ.
Tuần tự hoá và giải tuần tự hoá LargeParcelable (xem ParcelableUtils.h).
Quản lý gói thuê bao (xem SubscriptionManager.h).
Kiểm tra quyền. (Xem hàm checkReadPermission và checkWritePermission).
Định kỳ gọi IVehicleHardware.checkHealth và gửi tín hiệu nhịp tim (xem hàm checkHealth).
IVehicleHardware là một giao diện chung dùng để biểu thị cách triển khai VHAL theo từng phần cứng. Phương thức triển khai tham chiếu cho IVehicleHardware là FakeVehicleHardware. Phương thức này sử dụng bản đồ trong bộ nhớ để lưu trữ giá trị thuộc tính và không giao tiếp với bus xe thực tế. Ứng dụng này được thiết kế để chạy trên trình mô phỏng và không có phần phụ thuộc dành riêng cho phần cứng. Việc triển khai của nhà cung cấp không được sử dụng nguyên trạng và phải thêm logic dành riêng cho bus xe.
Kể từ Android 14, FakeVehicleHardware sẽ đọc cấu hình thuộc tính được hỗ trợ trong thời gian chạy trong quá trình khởi chạy từ thư mục /vendor/etc/automotive/vhalconfig/ của thiết bị, chứa tệp cấu hình kiểu JSON. Hãy xem tệp README tham khảo VHAL để biết định dạng tệp cấu hình và nội dung tệp cấu hình.
FakeVehicleHardware cũng hỗ trợ ghi đè tệp cấu hình để kiểm thử. Nếu bạn đặt thuộc tính hệ thống persist.vendor.vhal_init_value_override (thuộc tính này phải được đặt tại thời điểm tạo bản dựng hoặc rất sớm trong quá trình khởi động trước khi khởi chạy VHAL), thì thuộc tính này sẽ sử dụng tệp cấu hình từ thư mục /vendor/etc/automotive/vhaloverride/ trên thiết bị để ghi đè cấu hình hiện có. Cách triển khai của nhà cung cấp có thể sử dụng một phương pháp tương tự để cấu hình thuộc tính được hỗ trợ VHAL không được mã hoá cứng và có thể được quyết định linh động tại thời điểm khởi động.
Danh sách cấu hình thuộc tính của xe phải ở trạng thái tĩnh sau khi VHAL được khởi chạy.
Kể từ Android 16, GRPCVehicleHardware cung cấp một phương thức triển khai IVehicleHardware tham chiếu khác. Phương thức triển khai này giả định rằng có một máy chủ riêng chạy trên một máy từ xa hoặc máy ảo chứa logic xử lý thuộc tính. VHAL chạy trên các thiết bị AAOS đóng vai trò là proxy chuyển tiếp các yêu cầu đến máy chủ từ xa. Hãy xem grpc để biết thêm thông tin chi tiết.
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-26 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]