Bu sayfa, Cloud Translation API ile çevrilmiştir.

HAL'ler için AIDL

Android 11, Android'de HAL'ler için AIDL kullanma özelliğini kullanıma sunarak Android'in bazı bölümlerinin HIDL olmadan uygulanmasını mümkün kıldı. Mümkün olduğunda HAL'leri yalnızca AIDL kullanmaya geçirin (Yukarı akış HAL'leri HIDL kullandığında HIDL kullanılmalıdır).

system.img'teki gibi çerçeve bileşenleri ile vendor.img'teki gibi donanım bileşenleri arasında iletişim kurmak için AIDL kullanan HAL'ler kararlı AIDL kullanmalıdır. Ancak bir bölüm içinde (ör. bir HAL'den diğerine) iletişim kurmak için kullanılacak IPC mekanizması konusunda herhangi bir kısıtlama yoktur.

Motivasyon

AIDL, HIDL'den daha uzun süredir kullanılmaktadır ve Android çerçeve bileşenleri arasında veya uygulamalarda gibi diğer birçok yerde kullanılır. AIDL'de kararlılık desteği bulunduğundan, tek bir IPC çalışma zamanında tüm yığının uygulanması mümkündür. AIDL, HIDL'den daha iyi bir sürüm sistemi de sunar. AIDL'nin bazı avantajları şunlardır:

Tek bir IPC dili kullanmak, öğrenmeniz, hata ayıklamanız, optimize etmeniz ve güvence altına almanız gereken tek bir şey olduğu anlamına gelir.
AIDL, bir arayüzün sahipleri için yerinde sürüm oluşturmayı destekler:
- Sahipler, arayüzlerin sonuna yöntem veya paketlenebilir öğelere alan ekleyebilir. Bu sayede, yıllar içinde kod sürümünü oluşturmak daha kolay olur ve yıllık maliyet daha düşük olur (türler yerinde değiştirilebilir ve her arayüz sürümü için ek kitaplıklara gerek yoktur).
- Uzantı arayüzleri, tür sisteminde değil de çalışma zamanında eklenebilir. Bu nedenle, yayın uzantılarını arayüzlerin yeni sürümlerine yeniden temellendirmeye gerek yoktur.
Mevcut bir AIDL arayüzü, sahibi tarafından sabitlendiğinde doğrudan kullanılabilir. Daha önce, arayüzün tamamının HIDL'de oluşturulması gerekiyordu.

AIDL çalışma zamanına göre derleme

AIDL'nin üç farklı arka ucu vardır: Java, NDK ve CPP. Sabit AIDL kullanmak için system/lib*/libbinder.so adresindeki libbinder'ün sistem kopyasını kullanın ve /dev/binder üzerinden iletişim kurun. vendor resmindeki kod için bu, libbinder'un (VNDK'dan) kullanılamayacağı anlamına gelir: Bu kitaplıkta kararsız bir C++ API'si ve kararsız dahili bileşenler vardır. Bunun yerine, yerel tedarikçi kodu AIDL'nin NDK arka ucunu kullanmalı, libbinder_ndk (sistem libbinder.so tarafından desteklenir) ile bağlantı kurmalı ve aidl_interface girişleri tarafından oluşturulan NDK kitaplıklarıyla bağlantı kurmalıdır. Tam modül adları için Modül adlandırma kuralları başlıklı makaleyi inceleyin.

AIDL HAL arayüzü yazma

Sistem ile tedarikçi firma arasında kullanılacak bir AIDL arayüzünde iki değişiklik yapılması gerekir:

Her tür tanımı @VintfStability ile ek açıklamaya tabi tutulmalıdır.
aidl_interface beyanında stability: "vintf", yer almalıdır.

Bu değişiklikleri yalnızca arayüzün sahibi yapabilir.

Bu değişiklikleri yaptığınızda, arayüzün çalışması için VINTF manifestinde olması gerekir. Bu koşulu (ve yayınlanmış arayüzlerin dondurulduğunu doğrulama gibi ilgili koşulları) VTS testini vts_treble_vintf_vendor_test kullanarak test edin. Bir bağlayıcı nesnesi başka bir sürece gönderilmeden önce NDK arka ucunda AIBinder_forceDowngradeToLocalStability, C++ arka ucunda android::Stability::forceDowngradeToLocalStability veya Java arka ucunda android.os.Binder#forceDowngradeToSystemStability çağrısını yaparak @VintfStability arayüzünü bu şartlar olmadan kullanabilirsiniz.

Ayrıca, kod taşınabilirliğini en üst düzeye çıkarmak ve gereksiz ek kitaplıklar gibi olası sorunları önlemek için CPP arka ucunu devre dışı bırakın.

Üç arka uç (Java, NDK ve CPP) olduğundan aşağıdaki kod örneğinde backends kullanımının doğru olduğunu unutmayın. Kodda, bir PBM arka ucunun nasıl devre dışı bırakılacağı gösterilmektedir:

    aidl_interface: {
        ...
        backends: {
            cpp: {
                enabled: false,
            },
        },
    }

AIDL HAL arayüzlerini bulma

HAL'ler için AOSP kararlı AIDL arayüzleri, HIDL arayüzleriyle aynı temel dizinlerdeki aidl klasörlerinde bulunur:

hardware/interfaces, genellikle donanım tarafından sağlanan arayüzler içindir.
frameworks/hardware/interfaces, donanıma sağlanan üst düzey arayüzler içindir.
system/hardware/interfaces, donanıma sağlanan düşük seviyeli arayüzler içindir.

Uzantı arayüzlerini vendor veya hardware içindeki diğer hardware/interfacesalt dizinlerine koyun.

Uzantı arayüzleri

Android'in her sürümünde resmi AOSP arayüzleri bulunur. Android iş ortakları bu arayüzlere özellik eklemek istediğinde bunları doğrudan değiştirmemelidir. Aksi takdirde Android çalışma ortamları AOSP Android çalışma ortamıyla uyumlu olmaz. GSI resminin çalışmaya devam edebilmesi için bu arayüzleri değiştirmeyin.

Uzantılar iki farklı şekilde kaydedilebilir:

Çalışma zamanında; Ekli uzantı arayüzleri bölümüne bakın.
Bağımsız olarak, dünya genelinde ve VINTF'de kayıtlı

Ancak bir uzantı kaydedildiğinde, tedarikçiye özgü (yani yayın öncesi AOSP'nin bir parçası olmayan) bileşenler arayüzü kullandığında birleştirme çakışması mümkün değildir. Ancak yayın öncesi AOSP bileşenlerinde yayın sonrası değişiklikler yapıldığında birleştirme çakışmaları oluşabilir ve aşağıdaki stratejiler önerilir:

Arayüz eklemelerini bir sonraki sürümde AOSP'ye gönderin.
Bir sonraki sürümde daha fazla esnekliğe (birleştirme çakışmaları olmadan) olanak tanıyan yayın öncesi arayüz eklemeleri.

Uzantı paketlenebilirleri: ParcelableHolder

ParcelableHolder, Parcelable arayüzünün başka bir Parcelable örneğini içerebilen bir örneğidir.

ParcelableHolder'ün ana kullanım alanı, Parcelable'u genişletilebilir hale getirmektir. Örneğin, cihaz uygulayıcılarının AOSP tarafından tanımlanan bir Parcelable, AospDefinedParcelable öğesini katma değerli özelliklerini içerecek şekilde genişletebilmeyi beklediği resim.

Parcelable'u katma değerli özelliklerinizle genişletmek için ParcelableHolder arayüzünü kullanın. ParcelableHolder arayüzü, Parcelable örneği içerir. Parcelable alanına doğrudan alan eklemeye çalışırsanız hata oluşur:

parcelable AospDefinedParcelable {
  int a;
  String b;
  String x; // ERROR: added by a device implementer
  int[] y; // added by a device implementer
}

Önceki kodda görüldüğü gibi, cihaz uygulayıcısı tarafından eklenen alanlar Android'in sonraki sürümlerinde Parcelable düzeltildiğinde çakışmaya neden olabileceği için bu uygulama geçersizdir.

ParcelableHolder özelliğini kullanarak, bölünebilir bir öğenin sahibi Parcelable örneğinde bir uzantı noktası tanımlayabilir:

parcelable AospDefinedParcelable {
  int a;
  String b;
  ParcelableHolder extension;
}

Ardından cihaz uygulayıcıları, uzantılarının kendi Parcelable örneğini tanımlayabilir:

parcelable OemDefinedParcelable {
  String x;
  int[] y;
}

Yeni Parcelable örneği, ParcelableHolder alanıyla orijinal Parcelable'e eklenebilir:


// Java
AospDefinedParcelable ap = ...;
OemDefinedParcelable op = new OemDefinedParcelable();
op.x = ...;
op.y = ...;

ap.extension.setParcelable(op);

...

OemDefinedParcelable op = ap.extension.getParcelable(OemDefinedParcelable.class);

// C++
AospDefinedParcelable ap;
OemDefinedParcelable op;
std::shared_ptr<OemDefinedParcelable> op_ptr = make_shared<OemDefinedParcelable>();

ap.extension.setParcelable(op);
ap.extension.setParcelable(op_ptr);

...

std::shared_ptr<OemDefinedParcelable> op_ptr;

ap.extension.getParcelable(&op_ptr);

// NDK
AospDefinedParcelable ap;
OemDefinedParcelable op;
ap.extension.setParcelable(op);

...

std::optional<OemDefinedParcelable> op;
ap.extension.getParcelable(&op);

// Rust
let mut ap = AospDefinedParcelable { .. };
let op = Rc::new(OemDefinedParcelable { .. });

ap.extension.set_parcelable(Rc::clone(&op));

...

let op = ap.extension.get_parcelable::<OemDefinedParcelable>();

AIDL HAL sunucu örnek adı

AIDL HAL hizmetlerinin adlandırma kuralı gereği örnek adı $package.$type/$instance biçimindedir. Örneğin, titreşim HAL'inin bir örneği android.hardware.vibrator.IVibrator/default olarak kaydedilir.

AIDL HAL sunucusu yazma

@VintfStability AIDL sunucuları VINTF manifestinde belirtilmelidir. Örneğin:

    <hal format="aidl">
        <name>android.hardware.vibrator</name>
        <version>1</version>
        <fqname>IVibrator/default</fqname>
    </hal>

Aksi takdirde, AIDL hizmetini normal şekilde kaydetmelidirler. VTS testleri çalıştırıldığında, bildirilen tüm AIDL HAL'lerin kullanılabilir olması beklenir.

AIDL istemcisi yazma

AIDL istemcileri kendilerini uyumluluk matrisinde belirtmelidir. Örneğin:

    <hal format="aidl" optional="true">
        <name>android.hardware.vibrator</name>
        <version>1-2</version>
        <interface>
            <name>IVibrator</name>
            <instance>default</instance>
        </interface>
    </hal>

Mevcut bir HAL'i HIDL'den AIDL'ye dönüştürme

HIDL arayüzünü AIDL'ye dönüştürmek için hidl2aidl aracını kullanın.

hidl2aidl özellikleri:

Belirli paketin HAL (.hal) dosyalarına göre AIDL (.aidl) dosyaları oluşturun.
Yeni oluşturulan AIDL paketi için tüm arka uçların etkin olduğu derleme kuralları oluşturun.
HIDL türlerinden AIDL türlerine çevirmek için Java, CPP ve NDK arka uçlarında çeviri yöntemleri oluşturun.
Gerekli bağımlılıklara sahip çeviri kitaplıkları için derleme kuralları oluşturun.
HIDL ve AIDL dizeleyicilerinin CPP ve NDK arka uçlarında aynı değerlere sahip olmasını sağlamak için statik iddialar oluşturun.

HAL dosyası paketini AIDL dosyalarına dönüştürmek için aşağıdaki adımları uygulayın:

system/tools/hidl/hidl2aidl adresindeki aracı oluşturun.

Bu aracı en güncel kaynaktan oluşturmak en eksiksiz deneyimi sağlar. Önceki sürümlerdeki eski dallardaki arayüzleri dönüştürmek için en son sürümü kullanabilirsiniz:
```
m hidl2aidl
```
Aracı, çıkış dizini ve ardından dönüştürülecek paketle birlikte çalıştırın.

İsteğe bağlı olarak, yeni bir lisans dosyasının içeriğini oluşturulan tüm dosyaların en üstüne eklemek için -l bağımsız değişkenini kullanın. Doğru lisansı ve tarihi kullandığınızdan emin olun:
```
hidl2aidl -o <output directory> -l <file with license> <package>
```
Örnek:
```
hidl2aidl -o . -l my_license.txt android.hardware.nfc@1.2
```
Oluşturulan dosyaları okuyup dönüştürmeyle ilgili sorunları düzeltin:
- conversion.log, önce düzeltilmesi gereken, ele alınmamış sorunları içerir.
- Oluşturulan AIDL dosyalarında işlem gerektiren uyarılar ve öneriler olabilir. Bu yorumlar // ile başlar.
- Paketi temizleyin ve iyileştirmeler yapın.
- toString veya equals gibi ihtiyaç duyulabilecek özellikler için @JavaDerive ek açıklamasını kontrol edin.
Yalnızca ihtiyacınız olan hedefleri oluşturun:
- Kullanılmayacak arka uçları devre dışı bırakın. CPP arka ucu yerine NDK arka ucunu tercih edin. AIDL çalışma zamanına göre derleme başlıklı makaleyi inceleyin.
- Çeviri kitaplıklarını veya oluşturulan kodlarından kullanılmayacak olanları kaldırın.
AIDL ile HIDL arasındaki önemli farklar başlıklı makaleyi inceleyin:
- AIDL'nin yerleşik Status ve istisnalarını kullanmak genellikle arayüzü iyileştirir ve arayüze özgü başka bir durum türüne olan ihtiyacı ortadan kaldırır.
- Yöntemlerdeki AIDL arayüz bağımsız değişkenleri, HIDL'de olduğu gibi varsayılan olarak @nullable değildir.

AIDL HAL'leri için SEPolicy

Tedarikçi kodu tarafından görülebilen bir AIDL hizmet türü, hal_service_type özniteliğine sahip olmalıdır. Aksi takdirde, sepolicy yapılandırması diğer tüm AIDL hizmetleriyle aynıdır (HAL'ler için özel özellikler olsa da). Aşağıda, HAL hizmet bağlamının örnek bir tanımı verilmiştir:

    type hal_foo_service, service_manager_type, hal_service_type;

Platform tarafından tanımlanan çoğu hizmet için doğru türe sahip bir hizmet bağlamı zaten eklenmiştir (örneğin, android.hardware.foo.IFoo/default zaten hal_foo_service olarak işaretlenmiştir). Ancak bir çerçeve istemcisi birden fazla örnek adını destekliyorsa cihaza özgü service_contexts dosyalarına ek örnek adları eklenmelidir:

    android.hardware.foo.IFoo/custom_instance u:object_r:hal_foo_service:s0

Yeni bir HAL türü oluşturduğunuzda HAL özellikleri eklemeniz gerekir. Belirli bir HAL özelliği birden fazla hizmet türüyle ilişkilendirilebilir (her birinin, daha önce tartışıldığı gibi birden fazla örneği olabilir). HAL için foo, hal_attribute(foo) vardır. Bu makro, hal_foo_client ve hal_foo_server özelliklerini tanımlar. hal_client_domain ve hal_server_domain makroları, belirli bir alan için alanı belirli bir HAL özelliğiyle ilişkilendirir. Örneğin, sistem sunucusunun bu HAL'in istemcisi olması hal_client_domain(system_server, hal_foo) politikasına karşılık gelir. HAL sunucusu da benzer şekilde hal_server_domain(my_hal_domain, hal_foo) içerir.

Genellikle, belirli bir HAL özelliği için referans veya örnek HAL'ler için hal_foo_default gibi bir alan da oluşturun. Ancak bazı cihazlar kendi sunucuları için bu alanları kullanır. Birden fazla sunucu için alanları ayırt etmek yalnızca aynı arayüzü sunan ve uygulamalarında farklı bir izin grubuna ihtiyaç duyan birden fazla sunucu varsa önemlidir. Bu makroların hiçbirinde hal_foo bir sepolicy nesnesi değildir. Bunun yerine bu jeton, istemci sunucusu çiftiyle ilişkili özellik grubunu belirtmek için bu makrolar tarafından kullanılır.

Ancak şu ana kadar hal_foo_service ve hal_foo (hal_attribute(foo)'deki özellik çifti) ilişkilendirilmemiştir. HAL özelliği, hal_attribute_service makrosu (HIDL HAL'ler hal_attribute_hwservice makrosunu kullanır) kullanılarak AIDL HAL hizmetleriyle ilişkilendirilir. Örneğin, hal_attribute_service(hal_foo, hal_foo_service). Bu, hal_foo_client işlemlerinin HAL'i alabileceği ve hal_foo_server işlemlerinin HAL'i kaydedebileceği anlamına gelir. Bu kayıt kurallarının uygulanması bağlam yöneticisi (servicemanager) tarafından yapılır.

Hizmet adları her zaman HAL özelliklerine (ör. hal_attribute_service(hal_foo, hal_foo2_service)) karşılık gelmeyebilir. Genel olarak, hizmetlerin her zaman birlikte kullanıldığını ima ettiği için hal_foo2_service öğesini kaldırabilir ve tüm hizmet bağlamları için hal_foo_service öğesini kullanabilirsiniz. HAL'lerin birden fazla hal_attribute_service örneği ayarlamasının nedeni, orijinal HAL özellik adının yeterince genel olmaması ve değiştirilememesidir.

Tüm bunları bir araya getirdiğimizde örnek bir HAL şu şekilde görünür:

    public/attributes:
    // define hal_foo, hal_foo_client, hal_foo_server
    hal_attribute(foo)

    public/service.te
    // define hal_foo_service
    type hal_foo_service, hal_service_type, protected_service, service_manager_type

    public/hal_foo.te:
    // allow binder connection from client to server
    binder_call(hal_foo_client, hal_foo_server)
    // allow client to find the service, allow server to register the service
    hal_attribute_service(hal_foo, hal_foo_service)
    // allow binder communication from server to service_manager
    binder_use(hal_foo_server)

    private/service_contexts:
    // bind an AIDL service name to the selinux type
    android.hardware.foo.IFooXxxx/default u:object_r:hal_foo_service:s0

    private/<some_domain>.te:
    // let this domain use the hal service
    binder_use(some_domain)
    hal_client_domain(some_domain, hal_foo)

    vendor/<some_hal_server_domain>.te
    // let this domain serve the hal service
    hal_server_domain(some_hal_server_domain, hal_foo)

Ekli uzantı arayüzleri

Doğrudan hizmet yöneticisine kayıtlı üst düzey bir arayüz veya alt arayüz olsun, herhangi bir bağlayıcı arayüzüne uzantı eklenebilir. Uzatma alırken, uzantının türünü doğrulamanız gerekir. Uzantılar yalnızca bir bağlayıcı sunan süreçten ayarlanabilir.

Bir uzantı mevcut HAL'in işlevini değiştirdiğinde ekli uzantıları kullanın. Tamamen yeni bir özellik gerektiğinde bu mekanizma gerekli değildir ve doğrudan hizmet yöneticisine bir uzantı arayüzü kaydedebilirsiniz. Ekli uzantı arayüzleri, bu hiyerarşiler derin veya çok örnekli olabileceğinden alt arayüzlere eklendiğinde en iyi sonucu verir. Başka bir hizmetin bağlayıcı arayüzü hiyerarşisini yansıtmak için genel bir uzantı kullanmak, doğrudan bağlı uzantılara eşdeğer özellikler sunmak için kapsamlı bir muhasebe gerektirir.

Bir ciltte uzantı ayarlamak için aşağıdaki API'leri kullanın:

NDK arka ucu: AIBinder_setExtension
Java arka ucu: android.os.Binder.setExtension
PBM arka ucu: android::Binder::setExtension
Rust arka ucu: binder::Binder::set_extension

Bir ciltleyici için ek süre almak üzere aşağıdaki API'leri kullanın:

NDK arka ucu: AIBinder_getExtension
Java arka ucu: android.os.IBinder.getExtension
PBM arka ucu: android::IBinder::getExtension
Rust arka ucu: binder::Binder::get_extension

Bu API'ler hakkında daha fazla bilgiyi ilgili arka uçtaki getExtension işlevinin dokümanlarında bulabilirsiniz. Uzantıların nasıl kullanılacağına dair bir örnek hardware/interfaces/tests/extension/vibrator bölümünde verilmiştir.

AIDL ile HIDL arasındaki önemli farklar

AIDL HAL'leri veya AIDL HAL arayüzlerini kullanırken HIDL HAL'leri yazmaya kıyasla farklılıklara dikkat edin.

AIDL dilinin söz dizimi Java'ya daha yakındır. HIDL söz dizimi C++'ya benzer.
Tüm AIDL arayüzlerinde yerleşik hata durumları vardır. Özel durum türleri oluşturmak yerine arayüz dosyalarında sabit durum int'leri oluşturun ve CPP ile NDK arka uçlarında EX_SERVICE_SPECIFIC, Java arka ucunda ise ServiceSpecificException kullanın. Hata işleme bölümüne bakın.
AIDL, bağlayıcı nesneleri gönderildiğinde iş parçacığı havuzlarını otomatik olarak başlatmaz. Bunları manuel olarak başlatmanız gerekir (Mesaj dizisi yönetimi bölümüne bakın).
AIDL, işaretlenmemiş aktarım hatalarında işlemi iptal etmez (HIDL, işaretlenmemiş hatalarda işlemi iptal eder).Return
AIDL, dosya başına yalnızca bir tür tanımlayabilir.
AIDL bağımsız değişkenleri, çıkış parametresine ek olarak in, out veya inout olarak belirtilebilir (eşzamanlı geri çağırma yoktur).
AIDL, ilkel tür olarak handle yerine fd kullanır.
HIDL, uyumsuz değişiklikler için ana sürümleri, uyumlu değişiklikler için ise küçük sürümleri kullanır. AIDL'de geriye dönük uyumlu değişiklikler yerinde yapılır. AIDL'de ana sürüm kavramı açıkça belirtilmez. Bunun yerine, ana sürümler paket adlarına dahil edilir. Örneğin, AIDL bluetooth2 paket adını kullanabilir.
AIDL, varsayılan olarak gerçek zamanlı önceliği devralmaz. Gerçek zamanlı öncelik devralınmasını etkinleştirmek için setInheritRt işlevi bağlayıcı başına kullanılmalıdır.

HAL'ler için Tedarikçi Test Paketi (VTS) Testleri

Android, beklenen HAL uygulamalarını doğrulamak için Satıcı Testi Paketi'nden (VTS) yararlanır. VTS, Android'in eski tedarikçi uygulamalarıyla geriye dönük uyumlu olmasını sağlar. VTS'de başarısız olan uygulamalarda, işletim sisteminin gelecekteki sürümleriyle çalışmasını engelleyebilecek bilinen uyumluluk sorunları vardır.

HAL'ler için VTS'nin iki ana bölümü vardır.

1. Cihazdaki HAL'lerin Android tarafından bilindiğini ve beklendiğini doğrulama

Bu test grubuna test/vts-testcase/hal/treble/vintf adresinden ulaşabilirsiniz. Bu testler aşağıdakileri doğrulamaktan sorumludur:

VINTF manifestinde tanımlanan her @VintfStability arayüzü, bilinen bir yayınlanmış sürümde dondurulur. Bu, arayüzün her iki tarafının da arayüzün ilgili sürümünün tam tanımı konusunda anlaşmasına olanak tanır. Bu, temel işlevler için gereklidir.
VINTF manifestinde tanımlanan tüm HAL'ler söz konusu cihazda kullanılabilir. Beyan edilen bir HAL hizmetini kullanmak için yeterli izne sahip olan tüm istemciler, bu hizmetleri istedikleri zaman alıp kullanabilmelidir.
VINTF manifestinde bildirilen tüm HAL'ler, manifestte belirttikleri arayüz sürümünü sunar.
Cihazlarda desteği sonlandırılmış HAL'ler sunulmuyor. Android, FCM yaşam döngüsü bölümünde açıklandığı gibi HAL arayüzlerinin eski sürümlerine yönelik desteği sonlandırıyor.
Cihazda gerekli HAL'ler mevcut olmalıdır. Android'in düzgün çalışması için bazı HAL'ler gereklidir.

2. Her HAL'ın beklenen davranışını doğrulama

Her HAL arayüzünün, istemcilerinden beklenen davranışı doğrulamak için kendi VTS testleri vardır. Test durumları, bildirilen bir HAL arayüzünün her örneğinde çalıştırılır ve uygulanan arayüz sürümüne göre belirli bir davranışı zorunlu kılar.

Bu testler, HAL uygulamasının Android çerçevesinin dayandığı veya gelecekte dayayabileceği her yönü kapsayacak şekilde tasarlanmıştır.

Bu testler, özelliklerin desteklenmesi, hata işleme ve istemcinin hizmetten beklediği diğer tüm davranışların doğrulanmasını içerir.

HAL geliştirme için VTS aşamaları

Android'in HAL arayüzleri oluşturulurken veya değiştirilirken VTS testlerinin güncel tutulması beklenir.

VTS testleri, Android Tedarikçi API sürümleri için dondurulmadan önce tamamlanmalı ve tedarikçi uygulamalarını doğrulamaya hazır olmalıdır. Geliştiricilerin kendi uygulamalarını oluşturabilmesi, doğrulayabilmesi ve HAL arayüzü geliştiricilerine geri bildirim vermesi için arayüzler dondurulmadan önce hazır olmalıdır.

Mürekkep balığında VTS

Donanım kullanılamadığında Android, HAL arayüzleri için geliştirme aracı olarak Cuttlefish'i kullanır. Bu sayede Android için ölçeklenebilir VTS ve entegrasyon testi yapılabilir.

hal_implementation_test, Android'in yeni arayüzleri işlemeye hazır olduğundan ve VTS testlerinin yeni donanım ve cihazlar kullanıma sunulduğunda yeni satıcı uygulamalarını test etmeye hazır olduğundan emin olmak için Cuttlefish'in en son HAL arayüzü sürümlerinin uygulandığını test eder.