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

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

Kiểm tra tính linh hoạt của VTS

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

  • Nếu một thiết bị cụ thể không hỗ trợ HAL thử nghiệm (ví dụ: IR), VTS không cần chạy thử nghiệm cho thử nghiệm HAL đó đối với mục tiêu thiết bị đó.
  • Nếu một số thiết bị chia sẻ 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, VTS phải xác định xem nên chạy hay bỏ qua thử nghiệm đối với một mục tiêu thiết bị cụ thể.

Các loại thử nghiệm VTS

VTS bao gồm các loại thử nghiệm sau:

  • Kiểm tra tuân thủ đảm bảo khả năng tương thích giữa khung và phân vùng của nhà cung cấp. Các thử nghiệm này bắt buộc phải được chạy (và vượt qua) trên các thiết bị chạy Android 8.0 trở lên.
  • Kiểm tra sự 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/làm mờ, v.v.). Những thử nghiệm này là tùy chọn đối với các nhà cung cấp.

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

Xác định 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ợ HAL cụ thể hay không:

  • /system/compatibility_matrix.xml . Xác nhận các trường hợp HAL theo yêu cầu của khung. 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 HAL có được khung yêu cầu nghiêm ngặt hay không.
    • Tệp 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 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 các phiên bản khác nhau.
    • version1.0-1 có nghĩa là khung có thể hoạt động với phiên bản 1.0 thấp nhất và không yêu cầu phiên bản cao hơn 1.1.
  • Tệp kê khai thiết manifest.xml . Yêu cầu các phiên bản 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 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 nhập, 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~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ả 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/)
    

Kiểm tra tuân thủ

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

Testability check for compliance

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

Kiểm tra sự không tuân thủ

Đối với các thử nghiệm không tuân thủ, VTS dựa vào kết quả đầu ra của lshal và bảng kê khai của nhà cung cấp để xác định (và kiểm tra) các HAL thử nghiệm không được xác nhận quyền sở hữu trong tệp kê manifest.xml . Luồng quyết định:

Testability check for noncompliance

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

Xác định vị trí bảng 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, 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 kê manifest.xml ODM.xml, đượ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

Trình kiểm tra khả năng kiểm tra VTS

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

Để sử dụng vts_testability_check :

  • Để kiểm tra sự tuân thủ:
    vts_testability_check -c -b <bitness>  <hal@version>
    
  • Đối với thử nghiệm 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 HAL được truy cập

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

Để kiểm tra tính tuân thủ, bạn cũng có thể kiểm tra /system/etc/vintf/manifest.xml . Nếu HAL được xác định ở đây, VTS sẽ kiểm tra nó. (Đố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 .)