Kiểm tra khả năng thử nghiệm 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 nào cần bỏ qua đối với mục tiêu thiết bị đó.

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

Kể từ Android 8.0, tất cả thiết bị chạy Android 8.0 trở lên đều phải trải qua quy trình kiểm thử VTS. Tuy nhiên, không phải tất cả các 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 kiểm thử cho kiểm thử HAL đó trên mục tiêu thiết bị đó.
  • Nếu một số thiết bị dùng chung SoC và hình ảnh nhà cung cấp nhưng 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 thử nghiệm hay bỏ qua thử nghiệm cho một mục tiêu thiết bị cụ thể hay không.

Các loại xét nghiệm 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 khung và các phân vùng của nhà cung cấp. Bạn phải chạy (và vượt qua) các kiểm thử này trên các thiết bị chạy Android 8.0 trở lên.
  • Các bài kiểm tra 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/hiệu suất mờ, v.v.). Các 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 kiểm thử có phải là kiểm thử tuân thủ hay không phụ thuộc vào gói mà kiểm thử đó thuộc về. Các chương trình kiểm thử chạy bằng kế hoạch VTS được coi là chương trình 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ó bắt buộc phải có HAL hay không.
    • Tệp này 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 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 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 này 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ị hiển thị 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 hiển thị tất cả HAL có triển khai truyền tải (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ử 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 thực thể HAL do thiết bị cung cấp. Quy trình quyết định:

Kiểm tra tính tuân thủ của hoạt động thử nghiệm

Hình 1. Kiểm tra khả năng thử nghiệm cho quy trình kiểm tra mức độ tuân thủ VTS

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

Đối với các kiểm thử 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 thử) các HAL thử nghiệm không được xác nhận trong tệp manifest.xml. Quy trình quyết định:

Kiểm tra khả năng thử nghiệm để biết trạng thái không tuân thủ

Hình 2. Kiểm tra khả năng kiểm thử của bài kiểm tra mức độ 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 ở các 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 thử nghiệm VTS

vts_testibility_checker là một tệp nhị phân đóng gói VTS và được khung kiểm thử VTS sử dụng trong thời gian chạy để xác định xem một quy trình kiểm thử HAL nhất định có thể kiểm thử được hay không. Phương thứ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 ra quyết định được mô tả trong phần trước.

Cách sử dụng vts_testability_check:

  • Đối với kiểm thử tuân thủ: 
    vts_testability_check -c -b <bitness>  <hal@version>
  • Đối với quy trình kiểm tra 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 HAL nào được 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 kiểm thử.

Đối với các 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 tại đâ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), HAL được khai báo trong /system/manifest.xml.)