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.

Trang này được dịch bởi Cloud Translation API.

AIDL cho HAL
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Android 11 giới thiệu khả năng sử dụng AIDL cho HAL trong Android, cho phép triển khai các phần của Android mà không cần HIDL. Chuyển đổi HAL để sử dụng AIDL exclusively (chỉ sử dụng AIDL) khi có thể (khi HAL thượng nguồn sử dụng HIDL, bạn phải sử dụng HIDL).

Các HAL sử dụng AIDL để giao tiếp giữa các thành phần khung, chẳng hạn như các thành phần trong system.img và các thành phần phần cứng, chẳng hạn như các thành phần trong vendor.img, phải sử dụng AIDL ổn định. Tuy nhiên, để giao tiếp trong một phân vùng, chẳng hạn như từ một HAL đến một HAL khác, không có quy định hạn chế nào về cơ chế IPC để sử dụng.

Động lực

AIDL đã xuất hiện lâu hơn HIDL và được sử dụng ở nhiều nơi khác, chẳng hạn như giữa các thành phần khung Android hoặc trong ứng dụng. Giờ đây, AIDL có hỗ trợ độ ổn định, bạn có thể triển khai toàn bộ ngăn xếp bằng một thời gian chạy IPC duy nhất. AIDL cũng có hệ thống tạo phiên bản tốt hơn so với HIDL. Sau đây là một số ưu điểm của AIDL:

Việc sử dụng một ngôn ngữ IPC duy nhất có nghĩa là bạn chỉ cần học, gỡ lỗi, tối ưu hoá và bảo mật một thứ.
AIDL hỗ trợ tạo phiên bản tại chỗ cho chủ sở hữu giao diện:
- Chủ sở hữu có thể thêm phương thức vào cuối giao diện hoặc trường vào các đối tượng có thể phân phối. Điều này có nghĩa là bạn có thể dễ dàng tạo phiên bản mã hơn theo năm, đồng thời chi phí qua các năm sẽ nhỏ hơn (các loại có thể được sửa đổi tại chỗ và không cần thêm thư viện cho mỗi phiên bản giao diện).
- Bạn có thể đính kèm giao diện tiện ích tại thời gian chạy thay vì trong hệ thống loại, vì vậy, bạn không cần phải đặt lại cơ sở các tiện ích hạ nguồn trên các phiên bản giao diện mới hơn.
Bạn có thể sử dụng trực tiếp giao diện AIDL hiện có khi chủ sở hữu chọn điều chỉnh giao diện đó. Trước đây, bạn phải tạo toàn bộ bản sao của giao diện trong HIDL.

Xây dựng dựa trên môi trường thời gian chạy AIDL

AIDL có ba phần phụ trợ khác nhau: Java, NDK và CPP. Để sử dụng AIDL ổn định, hãy luôn sử dụng bản sao hệ thống của libbinder tại system/lib*/libbinder.so và trò chuyện trên /dev/binder. Đối với mã trên hình ảnh vendor, điều này có nghĩa là bạn không thể sử dụng libbinder (từ VNDK): thư viện này có API C++ không ổn định và nội bộ không ổn định. Thay vào đó, mã gốc của nhà cung cấp phải sử dụng phần phụ trợ NDK của AIDL, liên kết với libbinder_ndk (được hệ thống libbinder.so hỗ trợ) và liên kết với các thư viện NDK do các mục nhập aidl_interface tạo. Để biết tên mô-đun chính xác, hãy xem Quy tắc đặt tên mô-đun.

Viết giao diện AIDL HAL

Để giao diện AIDL được sử dụng giữa hệ thống và nhà cung cấp, giao diện này cần có hai thay đổi:

Mọi định nghĩa loại phải được chú thích bằng @VintfStability.
Nội dung khai báo aidl_interface cần bao gồm stability: "vintf",.

Chỉ chủ sở hữu của giao diện mới có thể thực hiện những thay đổi này.

Khi bạn thực hiện những thay đổi này, giao diện phải nằm trong tệp kê khai VINTF để hoạt động. Kiểm thử yêu cầu này (và các yêu cầu liên quan, chẳng hạn như xác minh rằng các giao diện đã phát hành bị đóng băng) bằng kiểm thử VTS vts_treble_vintf_vendor_test. Bạn có thể sử dụng giao diện @VintfStability mà không cần các yêu cầu này bằng cách gọi AIBinder_forceDowngradeToLocalStability trong phần phụ trợ NDK, android::Stability::forceDowngradeToLocalStability trong phần phụ trợ C++, hoặc android.os.Binder#forceDowngradeToSystemStability trong phần phụ trợ Java trên một đối tượng liên kết trước khi đối tượng đó được gửi đến một quy trình khác.

Ngoài ra, để có khả năng di chuyển mã tối đa và tránh các vấn đề tiềm ẩn như thư viện bổ sung không cần thiết, hãy tắt phần phụ trợ CPP.

Xin lưu ý rằng việc sử dụng backends trong ví dụ mã sau đây là chính xác, vì có ba phần phụ trợ (Java, NDK và CPP). Mã này cho biết cách tắt phần phụ trợ CPP:

    aidl_interface: {
        ...
        backends: {
            cpp: {
                enabled: false,
            },
        },
    }

Tìm giao diện AIDL HAL

Các giao diện AIDL ổn định của AOSP cho HALS nằm trong các thư mục aidl trong cùng thư mục cơ sở với các giao diện HIDL:

hardware/interfaces dành cho các giao diện thường do phần cứng cung cấp.
frameworks/hardware/interfaces dành cho các giao diện cấp cao được cung cấp cho phần cứng.
system/hardware/interfaces dành cho các giao diện cấp thấp được cung cấp cho phần cứng.

Đặt giao diện tiện ích vào các thư mục con hardware/interfaces khác trong vendor hoặc hardware.

Giao diện tiện ích

Android có một bộ giao diện AOSP chính thức với mỗi bản phát hành. Khi các đối tác Android muốn thêm chức năng vào các giao diện này, họ không nên thay đổi trực tiếp các giao diện này vì điều này khiến môi trường thời gian chạy Android của họ không tương thích với môi trường thời gian chạy Android AOSP. Tránh thay đổi các giao diện này để hình ảnh GSI có thể tiếp tục hoạt động.

Tiện ích có thể đăng ký theo hai cách:

Trong thời gian chạy; xem Giao diện tiện ích đính kèm
Là một trang web độc lập, được đăng ký trên toàn cầu và trong VINTF

Tuy nhiên, một tiện ích được đăng ký, khi các thành phần dành riêng cho nhà cung cấp (nghĩa là không phải là một phần của AOSP thượng nguồn) sử dụng giao diện, thì không thể xảy ra xung đột hợp nhất. Tuy nhiên, khi các sửa đổi hạ nguồn đối với các thành phần AOSP thượng nguồn được thực hiện, thì có thể xảy ra xung đột hợp nhất và bạn nên sử dụng các chiến lược sau:

Chuyển các phần bổ sung giao diện lên AOSP trong bản phát hành tiếp theo.
Thêm giao diện ngược dòng cho phép linh hoạt hơn (không có xung đột hợp nhất) trong bản phát hành tiếp theo.

Tiện ích có thể phân phối: ParcelableHolder

ParcelableHolder là một thực thể của giao diện Parcelable có thể chứa một thực thể khác của Parcelable.

Trường hợp sử dụng chính của ParcelableHolder là giúp Parcelable có thể mở rộng. Ví dụ: hình ảnh mà người triển khai thiết bị muốn có thể mở rộng Parcelable, AospDefinedParcelable do AOSP xác định để bao gồm các tính năng gia tăng giá trị của họ.

Sử dụng giao diện ParcelableHolder để mở rộng Parcelable bằng các tính năng giá trị gia tăng. Giao diện ParcelableHolder chứa một thực thể của Parcelable. Nếu bạn cố gắng thêm các trường trực tiếp vào Parcelable, thì điều này sẽ gây ra lỗi:

parcelable AospDefinedParcelable {
  int a;
  String b;
  String x; // ERROR: added by a device implementer
  int[] y; // added by a device implementer
}

Như đã thấy trong mã trước, phương pháp này không hoạt động vì các trường do trình triển khai thiết bị thêm vào có thể xung đột khi Parcelable được sửa đổi trong các bản phát hành Android tiếp theo.

Khi sử dụng ParcelableHolder, chủ sở hữu của một đối tượng có thể phân phối có thể xác định một điểm mở rộng trong một thực thể của Parcelable:

parcelable AospDefinedParcelable {
  int a;
  String b;
  ParcelableHolder extension;
}

Sau đó, trình triển khai thiết bị có thể xác định thực thể Parcelable riêng cho tiện ích của họ:

parcelable OemDefinedParcelable {
  String x;
  int[] y;
}

Bạn có thể đính kèm thực thể Parcelable mới vào Parcelable ban đầu bằng trường ParcelableHolder:


// Java
AospDefinedParcelable ap = ...;
OemDefinedParcelable op = new OemDefinedParcelable();
op.x = ...;
op.y = ...;

ap.extension.setParcelable(op);

...

OemDefinedParcelable op = ap.extension.getParcelable(OemDefinedParcelable.class);

// C++
AospDefinedParcelable ap;
OemDefinedParcelable op;
std::shared_ptr<OemDefinedParcelable> op_ptr = make_shared<OemDefinedParcelable>();

ap.extension.setParcelable(op);
ap.extension.setParcelable(op_ptr);

...

std::shared_ptr<OemDefinedParcelable> op_ptr;

ap.extension.getParcelable(&op_ptr);

// NDK
AospDefinedParcelable ap;
OemDefinedParcelable op;
ap.extension.setParcelable(op);

...

std::optional<OemDefinedParcelable> op;
ap.extension.getParcelable(&op);

// Rust
let mut ap = AospDefinedParcelable { .. };
let op = Rc::new(OemDefinedParcelable { .. });

ap.extension.set_parcelable(Rc::clone(&op));

...

let op = ap.extension.get_parcelable::<OemDefinedParcelable>();

Tên thực thể máy chủ HAL AIDL

Theo quy ước, các dịch vụ AIDL HAL có tên thực thể ở định dạng $package.$type/$instance. Ví dụ: một thực thể của HAL của bộ rung được đăng ký là android.hardware.vibrator.IVibrator/default.

Viết máy chủ HAL AIDL

Bạn phải khai báo máy chủ AIDL @VintfStability trong tệp kê khai VINTF, ví dụ:

    <hal format="aidl">
        <name>android.hardware.vibrator</name>
        <version>1</version>
        <fqname>IVibrator/default</fqname>
    </hal>

Nếu không, các ứng dụng này sẽ đăng ký dịch vụ AIDL như bình thường. Khi chạy kiểm thử VTS, dự kiến tất cả HAL AIDL đã khai báo đều có sẵn.

Viết ứng dụng AIDL

Ứng dụng AIDL phải tự khai báo trong ma trận tương thích, ví dụ:

    <hal format="aidl" optional="true">
        <name>android.hardware.vibrator</name>
        <version>1-2</version>
        <interface>
            <name>IVibrator</name>
            <instance>default</instance>
        </interface>
    </hal>

Chuyển đổi HAL hiện có từ HIDL sang AIDL

Sử dụng công cụ hidl2aidl để chuyển đổi giao diện HIDL thành AIDL.

Tính năng hidl2aidl:

Tạo tệp AIDL (.aidl) dựa trên tệp HAL (.hal) cho gói đã cho.
Tạo quy tắc bản dựng cho gói AIDL mới tạo với tất cả các phần phụ trợ được bật.
Tạo các phương thức dịch trong phần phụ trợ Java, CPP và NDK để dịch từ các loại HIDL sang các loại AIDL.
Tạo quy tắc bản dựng cho các thư viện dịch có các phần phụ thuộc bắt buộc.
Tạo các câu nhận định tĩnh để đảm bảo rằng trình liệt kê HIDL và AIDL có cùng giá trị trong phần phụ trợ CPP và NDK.

Hãy làm theo các bước sau để chuyển đổi gói tệp HAL thành tệp AIDL:

Tạo công cụ nằm trong system/tools/hidl/hidl2aidl.

Việc tạo công cụ này từ nguồn mới nhất sẽ mang lại trải nghiệm hoàn chỉnh nhất. Bạn có thể sử dụng phiên bản mới nhất để chuyển đổi giao diện trên các nhánh cũ từ các bản phát hành trước:
```
m hidl2aidl
```
Thực thi công cụ bằng một thư mục đầu ra, theo sau là gói cần chuyển đổi.

Bạn có thể sử dụng đối số -l để thêm nội dung của tệp giấy phép mới vào đầu tất cả các tệp được tạo. Hãy nhớ sử dụng đúng giấy phép và ngày:
```
hidl2aidl -o <output directory> -l <file with license> <package>
```
Ví dụ:
```
hidl2aidl -o . -l my_license.txt android.hardware.nfc@1.2
```
Đọc kỹ các tệp đã tạo và khắc phục mọi vấn đề về quá trình chuyển đổi:
- conversion.log chứa mọi vấn đề chưa được xử lý cần khắc phục trước tiên.
- Các tệp AIDL được tạo có thể có cảnh báo và đề xuất cần được xử lý. Các nhận xét này bắt đầu bằng //.
- Dọn dẹp và cải thiện gói.
- Kiểm tra chú thích @JavaDerive để biết các tính năng có thể cần thiết, chẳng hạn như toString hoặc equals.
Chỉ tạo các mục tiêu mà bạn cần:
- Tắt các phần phụ trợ sẽ không được sử dụng. Ưu tiên phần phụ trợ NDK hơn phần phụ trợ CPP; xem phần Tạo dựa trên môi trường thời gian chạy AIDL.
- Xoá thư viện dịch hoặc bất kỳ mã nào được tạo sẽ không được sử dụng.
Xem Những điểm khác biệt chính giữa AIDL và HIDL:
- Việc sử dụng Status tích hợp sẵn và các trường hợp ngoại lệ của AIDL thường cải thiện giao diện và không cần đến loại trạng thái dành riêng cho giao diện khác.
- Theo mặc định, các đối số giao diện AIDL trong phương thức không phải là @nullable như trong HIDL.

SEPolicy cho HAL AIDL

Loại dịch vụ AIDL hiển thị với mã của nhà cung cấp phải có thuộc tính hal_service_type. Nếu không, cấu hình sepolicy sẽ giống như mọi dịch vụ AIDL khác (mặc dù có các thuộc tính đặc biệt cho HAL). Dưới đây là định nghĩa mẫu về ngữ cảnh dịch vụ HAL:

    type hal_foo_service, service_manager_type, hal_service_type;

Đối với hầu hết các dịch vụ do nền tảng xác định, ngữ cảnh dịch vụ có loại chính xác đã được thêm (ví dụ: android.hardware.foo.IFoo/default đã được đánh dấu là hal_foo_service). Tuy nhiên, nếu ứng dụng khung hỗ trợ nhiều tên thực thể, thì bạn phải thêm các tên thực thể bổ sung trong các tệp service_contexts dành riêng cho thiết bị:

    android.hardware.foo.IFoo/custom_instance u:object_r:hal_foo_service:s0

Khi tạo một loại HAL mới, bạn phải thêm các thuộc tính HAL. Một thuộc tính HAL cụ thể có thể được liên kết với nhiều loại dịch vụ (mỗi loại có thể có nhiều thực thể như vừa thảo luận). Đối với HAL, foo, có hal_attribute(foo). Macro này xác định các thuộc tính hal_foo_client và hal_foo_server. Đối với một miền cụ thể, các macro hal_client_domain và hal_server_domain liên kết một miền với một thuộc tính HAL nhất định. Ví dụ: máy chủ hệ thống là ứng dụng của HAL này tương ứng với chính sách hal_client_domain(system_server, hal_foo). Tương tự, máy chủ HAL cũng bao gồm hal_server_domain(my_hal_domain, hal_foo).

Thông thường, đối với một thuộc tính HAL nhất định, hãy tạo một miền như hal_foo_default để tham khảo hoặc ví dụ về HAL. Tuy nhiên, một số thiết bị sử dụng các miền này cho máy chủ của riêng mình. Việc phân biệt giữa các miền cho nhiều máy chủ chỉ quan trọng nếu có nhiều máy chủ phân phát cùng một giao diện và cần một nhóm quyền khác nhau trong quá trình triển khai. Trong tất cả các macro này, hal_foo không phải là đối tượng sepolicy. Thay vào đó, các macro này sử dụng mã thông báo này để tham chiếu đến nhóm thuộc tính được liên kết với một cặp máy chủ ứng dụng.

Tuy nhiên, cho đến nay, hal_foo_service và hal_foo (cặp thuộc tính từ hal_attribute(foo)) chưa được liên kết. Thuộc tính HAL được liên kết với các dịch vụ HAL AIDL bằng macro hal_attribute_service (HAL HIDL sử dụng macro hal_attribute_hwservice), ví dụ: hal_attribute_service(hal_foo, hal_foo_service). Điều này có nghĩa là các quy trình hal_foo_client có thể nắm bắt HAL và các quy trình hal_foo_server có thể đăng ký HAL. Trình quản lý ngữ cảnh (servicemanager) thực thi các quy tắc đăng ký này.

Tên dịch vụ không phải lúc nào cũng tương ứng với các thuộc tính HAL, ví dụ: hal_attribute_service(hal_foo, hal_foo2_service). Nhìn chung, vì điều này ngụ ý rằng các dịch vụ luôn được sử dụng cùng nhau, nên bạn có thể xoá hal_foo2_service và sử dụng hal_foo_service cho tất cả ngữ cảnh dịch vụ. Khi HAL đặt nhiều thực thể hal_attribute_service, đó là do tên thuộc tính HAL ban đầu không đủ chung và không thể thay đổi.

Khi kết hợp tất cả những điều này, một HAL mẫu sẽ có dạng như sau:

    public/attributes:
    // define hal_foo, hal_foo_client, hal_foo_server
    hal_attribute(foo)

    public/service.te
    // define hal_foo_service
    type hal_foo_service, hal_service_type, protected_service, service_manager_type

    public/hal_foo.te:
    // allow binder connection from client to server
    binder_call(hal_foo_client, hal_foo_server)
    // allow client to find the service, allow server to register the service
    hal_attribute_service(hal_foo, hal_foo_service)
    // allow binder communication from server to service_manager
    binder_use(hal_foo_server)

    private/service_contexts:
    // bind an AIDL service name to the selinux type
    android.hardware.foo.IFooXxxx/default u:object_r:hal_foo_service:s0

    private/<some_domain>.te:
    // let this domain use the hal service
    binder_use(some_domain)
    hal_client_domain(some_domain, hal_foo)

    vendor/<some_hal_server_domain>.te
    // let this domain serve the hal service
    hal_server_domain(some_hal_server_domain, hal_foo)

Giao diện tiện ích đính kèm

Bạn có thể đính kèm một tiện ích vào bất kỳ giao diện liên kết nào, cho dù đó là giao diện cấp cao nhất được đăng ký trực tiếp với trình quản lý dịch vụ hay là giao diện phụ. Khi nhận được một tiện ích, bạn phải xác nhận loại tiện ích đó như dự kiến. Bạn chỉ có thể đặt các tiện ích từ quy trình phân phát liên kết.

Sử dụng các tiện ích đính kèm bất cứ khi nào một tiện ích sửa đổi chức năng của một HAL hiện có. Khi cần có chức năng hoàn toàn mới, bạn không cần đến cơ chế này và có thể trực tiếp đăng ký giao diện tiện ích với trình quản lý dịch vụ. Giao diện tiện ích đính kèm sẽ phù hợp nhất khi được đính kèm vào giao diện phụ, vì các hệ phân cấp này có thể sâu hoặc nhiều thực thể. Việc sử dụng một tiện ích toàn cục để phản ánh hệ phân cấp giao diện liên kết của một dịch vụ khác đòi hỏi phải có hệ thống ghi chép rộng rãi để cung cấp các chức năng tương đương cho các tiện ích được đính kèm trực tiếp.

Để đặt một phần mở rộng trên một liên kết, hãy sử dụng các API sau:

Phần phụ trợ NDK: AIBinder_setExtension
Phần phụ trợ Java: android.os.Binder.setExtension
Phần phụ trợ CPP: android::Binder::setExtension
Phần phụ trợ Rust: binder::Binder::set_extension

Để nhận tiện ích trên một liên kết, hãy sử dụng các API sau:

Phần phụ trợ NDK: AIBinder_getExtension
Phần phụ trợ Java: android.os.IBinder.getExtension
Phần phụ trợ CPP: android::IBinder::getExtension
Phần phụ trợ Rust: binder::Binder::get_extension

Bạn có thể tìm thêm thông tin về các API này trong tài liệu về hàm getExtension trong phần phụ trợ tương ứng. Ví dụ về cách sử dụng các tiện ích có trong hardware/interfaces/tests/extension/vibrator.

Sự khác biệt chính giữa AIDL và HIDL

Khi sử dụng HAL AIDL hoặc sử dụng giao diện HAL AIDL, hãy lưu ý đến sự khác biệt so với việc viết HAL HIDL.

Cú pháp của ngôn ngữ AIDL gần giống với Java. Cú pháp HIDL tương tự như C++.
Tất cả giao diện AIDL đều có trạng thái lỗi tích hợp. Thay vì tạo các loại trạng thái tuỳ chỉnh, hãy tạo các số nguyên trạng thái không đổi trong tệp giao diện và sử dụng EX_SERVICE_SPECIFIC trong phần phụ trợ CPP và NDK cũng như ServiceSpecificException trong phần phụ trợ Java. Xem phần Xử lý lỗi.
AIDL không tự động khởi động các nhóm luồng khi gửi đối tượng liên kết. Bạn phải bắt đầu các luồng này theo cách thủ công (xem phần Quản lý luồng).
AIDL không huỷ khi gặp lỗi truyền tải chưa được kiểm tra (HIDL Return huỷ khi gặp lỗi chưa được kiểm tra).
AIDL chỉ có thể khai báo một loại trên mỗi tệp.
Bạn có thể chỉ định đối số AIDL là in, out hoặc inout ngoài tham số đầu ra (không có lệnh gọi lại đồng bộ).
AIDL sử dụng fd làm loại gốc thay vì handle.
HIDL sử dụng các phiên bản chính cho các thay đổi không tương thích và các phiên bản phụ cho các thay đổi tương thích. Trong AIDL, các thay đổi tương thích ngược được thực hiện tại chỗ. AIDL không có khái niệm rõ ràng về các phiên bản chính; thay vào đó, khái niệm này được đưa vào tên gói. Ví dụ: AIDL có thể sử dụng tên gói bluetooth2.
AIDL không kế thừa mức độ ưu tiên theo thời gian thực theo mặc định. Bạn phải sử dụng hàm setInheritRt cho mỗi liên kết để bật tính năng kế thừa mức độ ưu tiên theo thời gian thực.

Bộ kiểm thử nhà cung cấp (VTS) kiểm thử cho HAL

Android dựa vào Bộ kiểm thử nhà cung cấp (VTS) để xác minh việc triển khai HAL dự kiến. VTS giúp đảm bảo Android có thể tương thích ngược với các phương thức triển khai cũ của nhà cung cấp. Các phương thức triển khai không thành công với VTS có các vấn đề về khả năng tương thích đã biết có thể khiến chúng không hoạt động được với các phiên bản hệ điều hành trong tương lai.

Có hai phần chính của VTS cho HAL.

1. Xác minh rằng Android đã biết và dự kiến các HAL trên thiết bị

Bạn có thể tìm thấy bộ kiểm thử này trong test/vts-testcase/hal/treble/vintf. Các kiểm thử này chịu trách nhiệm xác minh:

Mọi giao diện @VintfStability được khai báo trong tệp kê khai VINTF sẽ bị khoá ở một phiên bản đã phát hành đã biết. Điều này đảm bảo cả hai bên của giao diện đều đồng ý về định nghĩa chính xác của phiên bản giao diện đó. Điều này là cần thiết cho hoạt động cơ bản.
Tất cả HAL được khai báo trong tệp kê khai VINTF đều có trên thiết bị đó. Mọi ứng dụng có đủ quyền để sử dụng một dịch vụ HAL đã khai báo đều phải có thể nhận và sử dụng các dịch vụ đó bất cứ lúc nào.
Tất cả HAL được khai báo trong tệp kê khai VINTF đều phân phát phiên bản giao diện mà chúng khai báo trong tệp kê khai.
Không có HAL nào không dùng nữa được phân phát trên thiết bị. Android ngừng hỗ trợ các phiên bản giao diện HAL thấp hơn như mô tả trong vòng đời của FCM.
Các HAL bắt buộc có trên thiết bị. Một số HAL là bắt buộc để Android hoạt động đúng cách.

2. Xác minh hành vi dự kiến của từng HAL

Mỗi giao diện HAL đều có các bài kiểm thử VTS riêng để xác minh hành vi dự kiến của các ứng dụng khách. Các trường hợp kiểm thử chạy trên mọi thực thể của giao diện HAL đã khai báo và thực thi hành vi cụ thể dựa trên phiên bản giao diện đã triển khai.

Các chương trình kiểm thử này cố gắng bao gồm mọi khía cạnh của việc triển khai HAL mà khung Android dựa vào hoặc có thể dựa vào trong tương lai.

Các kiểm thử này bao gồm việc xác minh khả năng hỗ trợ các tính năng, xử lý lỗi và mọi hành vi khác mà ứng dụng khách có thể mong đợi từ dịch vụ.

Các mốc VTS cho việc phát triển HAL

Các bài kiểm thử VTS dự kiến sẽ được cập nhật khi tạo hoặc sửa đổi giao diện HAL của Android.

Bạn phải hoàn tất các thử nghiệm VTS và sẵn sàng xác minh việc triển khai của nhà cung cấp trước khi các thử nghiệm này bị đóng băng cho các bản phát hành API của nhà cung cấp Android. Các lớp này phải sẵn sàng trước khi giao diện bị đóng băng để nhà phát triển có thể tạo các phương thức triển khai, xác minh các phương thức đó và đưa ra ý kiến phản hồi cho nhà phát triển giao diện HAL.

VTS trên Cuttlefish

Khi không có phần cứng, Android sẽ sử dụng Cuttlefish làm công cụ phát triển cho giao diện HAL. Điều này cho phép kiểm thử tích hợp và VTS có thể mở rộng của Android.

hal_implementation_test kiểm thử để đảm bảo Cuttlefish triển khai các phiên bản giao diện HAL mới nhất nhằm đảm bảo Android đã sẵn sàng xử lý các giao diện mới và các kiểm thử VTS đã sẵn sàng kiểm thử các hoạt động triển khai mới của nhà cung cấp ngay khi có phần cứng và thiết bị mới.