Kiểm tra khả năng kiểm thử HAL

Bộ kiểm thử nhà cung cấp (VTS) Android 9 hỗ trợ một phương thức thời gian chạy để sử dụng cấu hình thiết bị nhằm xác định những bài kiểm thử VTS cần bỏ qua cho mục tiêu thiết bị đó.

Tính linh hoạt của bài kiểm thử VTS

Kể từ Android 8.0, các bài kiểm thử VTS là bắt buộc đối với tất cả thiết bị ra mắt bằng Android 8.0 trở lên. Tuy nhiên, không phải tất cả bài kiểm thử VTS đều áp dụng cho mọi mục tiêu thiết bị. Ví dụ:

  • Nếu một thiết bị cụ thể không hỗ trợ HAL kiểm thử (ví dụ: IR), thì VTS không cần chạy các bài kiểm thử cho bài kiểm thử HAL đó đối với mục tiêu thiết bị đó.
  • Nếu một số thiết bị dùng chung cùng một SoC và hình ảnh nhà cung cấp nhưng có các chức năng phần cứng khác nhau, thì VTS phải xác định xem có nên chạy hay bỏ qua một bài kiểm thử cho một mục tiêu thiết bị cụ thể hay không.

Các loại bài kiểm thử VTS

VTS bao gồm các loại bài kiểm thử sau:

  • Các bài kiểm thử Tuân thủ đảm bảo khả năng tương thích giữa các phân vùng khung và nhà cung cấp. Bạn phải chạy (và vượt qua) các bài kiểm thử này trên các thiết bị ra mắt bằng Android 8.0 trở lên.
  • Các bài kiểm thửKhông tuân thủ giúp nhà cung cấp cải thiện chất lượng sản phẩm (hiệu suất/fuzzing, v.v.). Nhà cung cấp có thể chọn chạy các bài kiểm thử này.

Việc một bài kiểm thử có phải là bài kiểm thử tuân thủ hay không phụ thuộc vào gói mà bài kiểm thử đó thuộc về. Các bài kiểm thử chạy theo gói VTS được coi là bài kiểm thử tuân thủ.

Xác định các HAL được hỗ trợ

VTS có thể sử dụng các tệp sau để xác định xem mục tiêu thiết bị có hỗ trợ một HAL cụ thể hay không:

  • /system/compatibility_matrix.xml. Yêu cầu các thực thể HAL mà khung cần. Ví dụ: 
    <hal format="hidl" optional="true">
    <name>android.hardware.vibrator</name>
    <version>1.0-1</version>
    <interface>
       <name>IVibrator</name>
       <instance>default</instance>
    </interface>
</hal>
    • Thuộc tính optional cho biết liệu khung có thực sự cần HAL hay không.
    • Tệp này có thể chứa nhiều mục cho cùng một HAL (có cùng tên) nhưng có phiên bản và giao diện khác nhau.
    • Tệp này có thể chứa nhiều cấu hình version cho cùng một mục, cho biết khung có thể hoạt động với nhiều phiên bản.
    • version1.0-1 có nghĩa là khung có thể hoạt động với phiên bản thấp nhất phiên bản 1.0 và không yêu cầu phiên bản cao hơn 1.1.
  • manifest.xml của thiết bị. Yêu cầu các thực thể HAL do nhà cung cấp cung cấp. Ví dụ: 
    <hal format="hidl">
    <name>android.hardware.vibrator</name>
    <transport>hwbinder</transport>
    <version>1.2</version>
    <interface>
        <name>IVibrator</name>
       <instance>default</instance>
    </interface>
</hal>
    • Tệp này có thể chứa nhiều mục cho cùng một HAL (có cùng tên) nhưng có phiên bản và giao diện khác nhau.
    • Nếu tệp này chỉ chứa một cấu hình version cho một mục, thì version1.2 có nghĩa là nhà cung cấp hỗ trợ tất cả các phiên bản từ 1.0 đến 1.2.
  • lshal. Một công cụ trên thiết bị cho biết thông tin thời gian chạy về các dịch vụ HAL đã đăng ký với hwservicemanager. Ví dụ: 
    android.hardware.vibrator@1.0::IVibrator/default
    lshal cũng cho thấy tất cả các HAL có triển khai chuyển tiếp (tức là có tệp -impl.so tương ứng trên thiết bị). Ví dụ: 
    android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/)
android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)

Bài kiểm thử tuân thủ

Đối với các bài kiểm thử tuân thủ, VTS dựa vào tệp kê khai của nhà cung cấp để xác định (và kiểm thử) tất cả các thực thể HAL do thiết bị cung cấp. Quy trình quyết định:

Kiểm tra khả năng kiểm thử để đảm bảo tuân thủ

Hình 1. Kiểm tra khả năng kiểm thử đối với các bài kiểm thử tuân thủ VTS

Bài kiểm thử không tuân thủ

Đối với các bài kiểm thử không tuân thủ, VTS dựa vào tệp kê khai của nhà cung cấp và lshal đầu ra để xác định (và kiểm thử) các HAL thử nghiệm không được yêu cầu trong tệp manifest.xml. Quy trình quyết định:

Kiểm tra khả năng kiểm thử đối với trường hợp không tuân thủ

Hình 2. Kiểm tra khả năng kiểm thử đối với các bài kiểm thử không tuân thủ VTS tests

Tìm tệp kê khai của nhà cung cấp

VTS kiểm tra tệp manifest.xml của nhà cung cấp ở những vị trí sau theo thứ tự sau:

  1. /vendor/etc/vintf/manifest.xml + tệp kê khai ODM (Nếu cùng một HAL được xác định ở cả hai vị trí, thì tệp kê khai ODM sẽ ghi đè tệp kê khai trong /vendor/etc/vintf/manifest.xml)
  2. /vendor/etc/vintf/manifest.xml
  3. Tệp manifest.xml ODM, được tải từ các tệp sau theo thứ tự sau:
    1. /odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml
    2. /odm/etc/vintf/manifest.xml
    3. /odm/etc/manifest_$(ro.boot.product.hardware.sku).xml
    4. /odm/etc/manifest.xml
    5. /vendor/manifest.xml

Công cụ kiểm tra khả năng kiểm thử VTS

The vts_testibility_checker là một tệp nhị phân được đóng gói bằng VTS và được khung kiểm thử VTS sử dụng trong thời gian chạy để xác định xem một bài kiểm thử HAL nhất định có thể kiểm thử hay không. Công cụ này dựa trên libvintf để tải và phân tích cú pháp tệp kê khai của nhà cung cấp, đồng thời triển khai quy trình quyết định được mô tả trong phần trước.

Cách sử dụng vts_testability_check:

  • Đối với bài kiểm thử tuân thủ: 
    vts_testability_check -c -b <bitness>  <hal@version>
  • Đối với bài kiểm thử không tuân thủ: 
    vts_testability_check -b <bitness>  <hal@version>

Đầu ra của vts_testability_check sử dụng định dạng json sau: 

{testable: <True/False> Instances: <list of instance names of HAL service>}

Xác định các HAL được truy cập

Để xác định những HAL mà các bài kiểm thử VTS truy cập, hãy đảm bảo rằng mỗi bài kiểm thử HAL sử dụng VtsHalHidlTargetTestEnvBase mẫu để đăng ký(các) HAL được truy cập trong bài kiểm thử. Sau đó, khung kiểm thử VTS có thể trích xuất các HAL đã đăng ký khi tiền xử lý bài kiểm thử.

Đối với các bài kiểm thử tuân thủ, bạn cũng có thể kiểm tra /system/etc/vintf/manifest.xml. Nếu một HAL được xác định ở đây, thì VTS sẽ kiểm thử HAL đó. (Đối với các dịch vụ HAL do hệ thống cung cấp (ví dụ: graphics.composer/vr), các HAL được khai báo trong /system/manifest.xml.)