HAL test edilebilirlik kontrolü

Android 9 Vendor Test Suite (VTS), cihaz yapılandırmasını kullanarak hangi VTS testlerinin atlanması gerektiğini belirlemek için bir çalışma zamanı yöntemini destekler.

VTS test esnekliği

Android 8.0'dan itibaren, Android 8.0 ve sonraki sürümlerle kullanıma sunulan tüm cihazlar için VTS testleri zorunludur. Ancak tüm VTS testleri tüm cihaz hedefleri için geçerli değildir. Örneğin:

  • Belirli bir cihaz bir test HAL'sini (ör. IR) desteklemiyorsa VTS'nin bu HAL testi için bu cihaz hedefiyle ilgili testleri çalıştırması gerekmez.
  • Aynı çip üzerinde sistemi ve satıcı görüntüsünü paylaşan ancak farklı donanım işlevlerine sahip birden fazla cihaz varsa VTS, belirli bir cihaz hedefi için bir testin çalıştırılıp çalıştırılmayacağını veya atlanıp atlanmayacağını belirlemelidir.

VTS test türleri

VTS aşağıdaki test türlerini içerir:

  • Uygunluk testleri, çerçeve ile tedarikçi bölümleri arasındaki uyumluluğu sağlar. Bu testlerin, Android 8.0 veya sonraki sürümlerle kullanıma sunulan cihazlarda çalıştırılması (ve geçilmesi) gerekir.
  • Uygunluk dışı testleri, satıcıların ürün kalitesini (performans/bulanıklık vb.) artırmasına yardımcı olur. Bu testler, tedarikçiler için isteğe bağlıdır.

Bir testin uygunluk testi olup olmadığı, hangi plana ait olduğuna bağlıdır. VTS planı ile çalışan testler uygunluk testleri olarak kabul edilir.

Desteklenen HAL'leri belirleme

VTS, cihaz hedefinin belirli bir HAL'yi destekleyip desteklemediğini belirlemek için aşağıdaki dosyaları kullanabilir:

  • /system/compatibility_matrix.xml. Çerçevenin gerektirdiği HAL örneklerini talep eder. Örnek:
    <hal format="hidl" optional="true">
        <name>android.hardware.vibrator</name>
        <version>1.0-1</version>
        <interface>
           <name>IVibrator</name>
           <instance>default</instance>
        </interface>
    </hal>
    • optional özelliği, HAL'ın çerçeve tarafından kesinlikle gerekli olup olmadığını gösterir.
    • Dosya, aynı HAL için (aynı adla) birden fazla giriş içerebilir ancak farklı sürüm ve arayüzlere sahip olabilir.
    • Dosya, aynı giriş için birden fazla version yapılandırması içerebilir. Bu, çerçevenin farklı sürümlerle çalışabileceğini gösterir.
    • version1.0-1, çerçevenin en düşük 1.0 sürümüyle çalışabileceği ve 1.1'den daha yüksek bir sürüm gerektirmediği anlamına gelir.
  • Cihaz manifest.xml. Tedarikçi tarafından sağlanan HAL örneklerini talep eder. Örnek:
    <hal format="hidl">
        <name>android.hardware.vibrator</name>
        <transport>hwbinder</transport>
        <version>1.2</version>
        <interface>
            <name>IVibrator</name>
           <instance>default</instance>
        </interface>
    </hal>
    • Dosya, aynı HAL için (aynı adla) birden fazla giriş içerebilir ancak farklı sürüm ve arayüzlere sahip olabilir.
    • Dosya, bir giriş için yalnızca tek bir version yapılandırması içeriyorsa version1.2, tedarikçinin 1.0-1.2 arasındaki tüm sürümleri desteklediği anlamına gelir.
  • lshal. Cihazda, hwservicemanager ile kaydedilen HAL hizmetleri hakkında çalışma zamanı bilgilerini gösteren bir araç. Örnek:
    android.hardware.vibrator@1.0::IVibrator/default

    lshal, geçiş uygulamalarıyla birlikte tüm HAL'leri de gösterir (ör.cihazda ilgili -impl.so dosyası bulunur). Örnek:
    android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/)
    android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)

Uygunluk testleri

VTS, uygunluk testleri için cihaz tarafından sağlanan tüm HAL örneklerini belirlemek (ve test etmek) üzere satıcı manifestine güvenir. Karar akışı:

Uygunluk için test edilebilirlik kontrolü

Şekil 1. VTS uygunluk testleri için test edilebilirlik kontrolü

Uygunluk dışı testler

Uygunluk testleri için VTS, manifest.xml dosyasında belirtilmeyen deneysel HAL'leri belirlemek (ve test etmek) amacıyla tedarikçi manifestosunu ve lshal çıkışlarını kullanır. Karar akışı:

Uygunsuzluk için test edilebilirlik kontrolü

Şekil 2. VTS'ye uygun olmayan testler için test edilebilirliği kontrol etme testleri

Tedarikçi manifestini bulma

VTS, tedarikçi manifest.xml dosyasını aşağıdaki yerlerde ve sırayla kontrol eder:

  1. /vendor/etc/vintf/manifest.xml + ODM manifesti (Aynı HAL her iki yerde de tanımlanmışsa ODM manifesti, /vendor/etc/vintf/manifest.xml içindeki manifesti geçersiz kılar)
  2. /vendor/etc/vintf/manifest.xml
  3. Aşağıdaki dosyalardan şu sırayla yüklenen ODM manifest.xml dosyası:
    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

VTS test edilebilirliği kontrol aracı

vts_testibility_checker, VTS ile birlikte paketlenmiş bir ikili programdır ve belirli bir HAL testinin test edilebilir olup olmadığını belirlemek için çalışma zamanında VTS test çerçevesi tarafından kullanılır. Tedarikçi manifest dosyasını yüklemek ve ayrıştırmak için libvintf temel alınır ve önceki bölümde açıklanan karar akışı uygulanır.

vts_testability_check uygulamasını kullanmak için:

  • Uygunluk testi için:
    vts_testability_check -c -b <bitness>  <hal@version>
  • Uygunsuzluk testi için:
    vts_testability_check -b <bitness>  <hal@version>

vts_testability_check çıkışında aşağıdaki JSON biçimi kullanılır:

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

Erişilen HAL'leri belirleme

VTS testleri tarafından hangi HAL'lere erişildiğini belirlemek için her bir HAL testinin, testte erişilen HAL'leri kaydetmek üzere VtsHalHidlTargetTestEnvBase şablonunu kullandığından emin olun. VTS test çerçevesi, testi önceden işlerken kayıtlı HAL'leri çıkarabilir.

Uygunluk testleri için /system/etc/vintf/manifest.xml bölümünü de inceleyebilirsiniz. Burada bir HAL tanımlanmışsa VTS bunu test etmelidir. (Sistem tarafından sağlanan HAL hizmetleri (ör. graphics.composer/vr) için HAL'ler /system/manifest.xml içinde tanımlanır.)