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

Bộ thử nghiệm của 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 thử nghiệm VTS cần bỏ qua cho mục tiêu thiết bị đó.

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

Kể từ Android 8.0, các thiết bị chạy Android 8.0 trở lên đều phải có các bài kiểm thử VTS. Tuy nhiên, không phải mọ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 kiểm thử cho 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 của 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 kiểm thử cho một mục tiêu thiết bị cụ thể hay không.

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

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

  • Các 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 kiểm thử này trên những thiết bị chạy 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/kiểm thử ngẫu nhiên, v.v.). Nhà cung cấp không bắt buộc phải thực hiện các kiểm thử này.

Việc một bài kiểm tra có phải là bài kiểm tra tuân thủ hay không phụ thuộc vào gói mà bài kiểm tra đó thuộc về. Những kiểm thử chạy bằng kế hoạch VTS được coi là 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. Xác nhận các thực thể HAL mà khung yêu cầu. 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 có thể chứa nhiều mục nhập 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 này có thể hoạt động với nhiều phiên bản.
    • version1.0-1 có nghĩa là khung này có thể hoạt động với phiên bản thấp nhất là 1.0 và không yêu cầu phiên bản cao hơn 1.1.
  • Thiết bị manifest.xml. Xác nhận 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 có thể chứa nhiều mục nhập 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 chỉ chứa một cấu hình version duy nhất 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ả HAL có các chế độ triển khai truyền dữ liệu trực 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/)

Kiểm thử việc tuân thủ

Đối với các 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 phiên bản HAL do thiết bị cung cấp. Quy trình đưa ra 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ử cho các bài kiểm tra tuân thủ VTS

Kiểm thử không tuân thủ

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

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 nơi, 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

vts_testibility_checker là một tệp nhị phân được đóng gói cùng với VTS và được khung kiểm thử VTS sử dụng trong thời gian chạy để xác định xem một kiểm thử HAL nhất định có kiểm thử được hay không. Thư viện 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 tra tuân thủ: 
    vts_testability_check -c -b <bitness>  <hal@version>
  • Đối vớ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 đã truy cập

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

Đối với các bài kiểm tra 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, 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.)