Arayüz sürümü oluşturma

HIDL, HIDL'de yazılan her arayüzün sürümü olmasını gerektirir. HAL'den sonra yayınlandığında, dondurulur ve bundan sonraki değişikliklerin yeni bir sürüm oluşturabilirsiniz. Yayınlanan belirli bir arayüz başka bir arayüzle genişletilebilir.

HIDL kodu yapısı

HIDL kodu kullanıcı tanımlı olarak düzenlenmiştir türler, arayüzler ve paketler:

• Kullanıcı tanımlı türler (UDT'ler). HIDL aracılığıyla daha karmaşık türleri oluşturmak için kullanılabilecek temel veri türleri birleşimler ve sıralamalar hakkında bilgi sahibi olmanızı sağlar. UDT'ler arayüzler ve paket düzeyinde tanımlanabilir (tüm kullanıcılar için ortak veya yerel olarak bir arayüze aktarmanızı sağlar.
• Arayüzler. HIDL'nin temel yapı taşı olan bir arayüz olan UDT ve yöntem bildirimlerinden oluşur. Arayüzler kullanabilirsiniz.
• Paketler. İlgili HIDL arayüzlerini ve verileri düzenler yaygın olarak kullanılan bir öğe daha var. Paket, bir ad ve sürümle tanımlanır ve şunları içerir:
  • types.hal adlı veri türü tanımlama dosyası.
  • Her biri kendi .hal dosyasında bulunan sıfır veya daha fazla arayüz.

types.hal veri türü tanım dosyası yalnızca UDT'leri içerir (tümü paket düzeyindeki UDT'ler tek bir dosyada tutulur. Hedefteki gösterimler dil, paketteki tüm arayüzlerde kullanılabilir.

Sürüm oluşturma felsefesi

HIDL paketi (ör. android.hardware.nfc), belirli bir sürüm (1.0 gibi) için yayınlananlar değiştirilemez; o değiştirilemez. Paketteki arayüzlerde veya arayüzde yapılan değişiklikler, UDT'lerindeki değişiklikler yalnızca başka bir pakette gerçekleşebilir.

HIDL'de sürüm belirleme, arayüz düzeyinde değil, paket düzeyinde geçerlidir. Bir paketteki tüm arayüzler ve UDT'ler aynı sürümü paylaşır. Paket sürümler anlamsal sürüm oluşturma ile ilgili daha fazla bilgi edinin. Bir veya daha fazla alt sürüm yükseltmeleri, yeni sürümün paketin eski paketle geriye dönük olarak uyumlu olması ve önemli bir version ifadesi, paketin yeni sürümünün hiç yüklenmediğini eski paketle geriye dönük olarak uyumlu hale gelecektir.

Kavramsal olarak, bir paket birkaç şekilde başka bir paketle ilişkilendirilebilir:

• Hiç.
• Paket düzeyinde geriye dönük uyumlu genişletilebilirlik. Bu bir paketin yeni küçük sürüm yükseltmelerinde (sonraki artışlı düzeltme) gerçekleşir; yeni paket, eski paketle aynı ada ve ana sürüme sahiptir, ancak yüksek alt sürüm olabilir. İşlevsel olarak yeni paket, eski paketin paketinin anlamı:
  • Ana paketin üst düzey arayüzleri yeni pakette mevcuttur. arayüzlerde yeni yöntemler, yeni arayüz-yerel UDT'ler ( arayüz düzeyinde uzantı) ve yeni UDT'leri types.hal
  • Yeni pakete yeni arayüzler de eklenebilir.
  • Üst paketin tüm veri türleri yeni pakette mevcuttur ve eski paketin (muhtemelen yeniden uygulanmış) yöntemlerle işletilebilir.
  • Yeni veri türleri de eklenebilir. Bu veri türleri, veya yeni arayüzler olabilir.
• Arayüz düzeyinde geriye dönük uyumlu genişletilebilirlik. Yeni paketi, orijinal paketin kapsamını mantıksal olarak ayrı arayüzlerle tanıştırmayı unutmayın. Bu amaçla aşağıdakileri tercih edebilirsiniz:
  • Yeni paketteki arayüzlerin, eski paketteki veri türlerine başvurması gerekir. paketinden yararlanın.
  • Yeni paketteki arayüzler, eski bir veya daha fazla arayüzün arayüzünü genişletebilir paketlerini ekleyebilirsiniz.
• Orijinal geriye dönük uyumsuzluğun kapsamını genişletin. Bu, paketin ana sürümünün yükseltmesi ve iki sürüm arasında herhangi bir ilişki çünkü bu ikisi. Böyle bir durum varsa her zaman türünü ve bir alt kümenin devralınmasından eski paket arayüzleridir.

Arayüz yapılandırma

İyi yapılandırılmış bir arayüz için, normal koşullarda ölçülemeyen yeni işlev türleri orijinal tasarımın bir parçası olmayanlar HIDL'de değişiklik gerektirmelidir kullanır. Öte yandan, risk almanın her iki tarafında da değişiklik arayüzü değiştirmeden yeni işlevler sunan arayüz arayüz yapılandırılmamıştır.

Treble, Bir cihazda vendor.img ve system.img olabilir ayrı derlenir. vendor.img ile arasındaki tüm etkileşimler system.img özelliğinin açık ve eksiksiz bir şekilde tanımlanması gerekir. yıllarca çalışmaya devam etmesini sağlıyor. Bu, birçok API yüzeyini içerir ancak yüzey, HIDL’nin web üzerinde işlemler arası iletişim için kullandığı IPC mekanizmasıdır. system.img/vendor.img sınır.

Gereksinimler

HIDL üzerinden iletilen tüm veriler açıkça tanımlanmalıdır. Bir derlendiğinde bile birlikte çalışmaya devam edebilir. ayrı ayrı veya bağımsız olarak geliştirilen veriler için de koşullar:

• Doğrudan HIDL'de (structs enums vb. kullanılarak) açıklanabilir. anlamlara gelir.
• ISO/IEC 7816 gibi genel bir standartla açıklanabilir.
• Donanım standardı veya fiziksel donanım düzeniyle tanımlanabilir.
• Gerekirse opak veriler (ör. ortak anahtarlar, kimlikler vb.) olabilir.

Opak veriler kullanılıyorsa bu veriler HIDL'nin yalnızca bir tarafı tarafından okunmalıdır. kullanır. Örneğin, vendor.img kodu system.img, bir dize mesajı veya vec<uint8_t> bu veriler system.img tarafından ayrıştırılamaz; bu yalnızca vendor.img karakterlerinin yorumlanması için geri gönderilir. Zaman vendor.img öğesinden bir değeri tedarikçi firma koduna iletme verilerin biçimi ve nasıl kullanıldığı, system.img bir parçası olarak ele alınmalı ve bu da yorumlanması gereken arayüz.

Kurallar

Yalnızca aşağıdaki kodu kullanarak bir HAL uygulamasını veya istemcisini yazabilmeniz gerekir: .hal dosyaları (yani, Android kaynağına veya herkese açık standartlarına göre). Gerekli davranışı tam olarak belirtmenizi öneririz. Şuna benzer ifadeler "uygulama A veya B yapabilir" gibi başarılı sonuçlar almak için ortak bir paydada buluşmasını sağlamak sizin görevinizdir.

HIDL kodu düzeni

HIDL temel ve satıcı paketlerini içerir.

Temel HIDL arayüzleri, Google tarafından belirtilen arayüzlerdir. Ait oldukları paketler android.hardware. ile başlar ve alt sisteme göre adlandırılır. farklı adlandırma düzeylerine sahip olduğunu gördük. Örneğin, NFC paketi android.hardware.nfc ve kamera paketi android.hardware.camera. Temel paket genel olarak şu ada sahiptir: android.hardware.[name1].[name2].... HIDL paketlerinin adlarının yanı sıra bir sürümü de vardır. Örneğin, android.hardware.camera, 3.4 sürümünde olabilir; bu Bir paketin sürümü kaynak ağaçtaki yerleşimini etkilediğinden önemlidir.

Tüm temel paketler şuranın hardware/interfaces/ altındadır: geliştirmenizi sağlar. Paket android.hardware.[name1].[name2]... şunun altında: $m.$n hardware/interfaces/name1/name2/.../$m.$n/; paket android.hardware.camera sürümü 3.4 dizinde hardware/interfaces/camera/3.4/. Sabit kodlu bir eşleme var paket öneki android.hardware. ile yol arasındaki hardware/interfaces/

Çekirdek olmayan (tedarikçi firma) paketler, SoC tedarikçisi veya ODM tarafından oluşturulan paketlerdir. İlgili içeriği oluşturmak için kullanılan çekirdek olmayan paketler için önek vendor.$(VENDOR).hardware. şeklindedir; burada: $(VENDOR)SoC tedarikçisi veya OEM/ODM'yi ifade eder. Bu, yol ile eşleşir Ağaçta vendor/$(VENDOR)/interfaces (bu eşleme de sabit kodlu) sunulur.

Tam nitelikli kullanıcı tanımlı tür adları

HIDL'de her UDT, UDT adından, UDT'nin tanımlandığı paket adı ve paket sürümü. İlgili içeriği oluşturmak için kullanılan tam nitelikli ad, yalnızca bu türün örnekleri bildirildiğinde ve türbenin tanımlandığı yer kullanılmaz. Örneğin, android.hardware.nfc, sürüm 1.0 bir struct tanımlıyor NfcData olarak adlandırıldı. Beyanın sitesinde ( types.hal veya bir arayüzün beyanı içinde) sadece şöyle der:

struct NfcData {
    vec<uint8_t> data;
};

Bu tür bir örnek tanımlarken (veri yapısı içinde veya yöntem parametresi olarak) tam nitelikli tür adını kullanın:

android.hardware.nfc@1.0::NfcData

Genel söz dizimi: PACKAGE@VERSION::UDT, burada:

• PACKAGE, bir HIDL paketinin noktayla ayrılmış adıdır (ör. android.hardware.nfc).
• VERSION, noktayla ayrılmış ana.minor-sürümdür biçimi (ör. 1.0).
• UDT, HIDL UDT'nin noktayla ayrılmış adıdır. HIDL iç içe yerleştirilmiş UDT'leri desteklediğinden HIDL arayüzleri UDT'ler (bir tür iç içe yerleştirilmiş ifade) durumlarda, adlara erişmek için noktalar kullanılır.

Örneğin, aşağıdaki iç içe yerleştirilmiş bildirim ortak android.hardware.example paketindeki tür dosyası 1.0:

// types.hal
package android.hardware.example@1.0;
struct Foo {
    struct Bar {
        // …
    };
    Bar cheers;
};

Bar için tam nitelikli ad: android.hardware.example@1.0::Foo.Bar. Ayrıca, bir proje yöneticisi olarak yukarıdaki pakette, iç içe yerleştirilmiş bildirim adlı bir arayüzde IQuux:

// IQuux.hal
package android.hardware.example@1.0;
interface IQuux {
    struct Foo {
        struct Bar {
            // …
        };
        Bar cheers;
    };
    doSomething(Foo f) generates (Foo.Bar fb);
};

Bar için tam nitelikli ad: android.hardware.example@1.0::IQuux.Foo.Bar.

Her iki durumda da Bar yalnızca Bar olarak anılabilir Foo bildiriminin kapsamındadır. Pakette veya arayüz düzeyinde, Foo aracılığıyla Bar sitesine başvurmanız gerekir: doSomething yönteminin bildirimindeki gibi Foo.Bar bölümünü ziyaret edin. Alternatif olarak, yöntemi daha ayrıntılı bir şekilde şu şekilde açıklayabilirsiniz:

// IQuux.hal
doSomething(android.hardware.example@1.0::IQuux.Foo f) generates (android.hardware.example@1.0::IQuux.Foo.Bar fb);

Tam nitelikli numaralandırma değerleri

UDT bir enum türüyse enum türünün her değerinin bir numaralandırma türünün tam nitelikli adıyla başlayan tam nitelikli ad, ardından iki nokta işareti ve ardından numaralandırma değerinin adı gelir. Örneğin, android.hardware.nfc, paketinin 1.0 sürümünü kabul et NfcStatus enum türünü tanımlar:

enum NfcStatus {
    STATUS_OK,
    STATUS_FAILED
};

STATUS_OK ifadesinden bahsedilirken tam ad şu şekildedir:

android.hardware.nfc@1.0::NfcStatus:STATUS_OK

Genel söz dizimi: PACKAGE@VERSION::UDT:VALUE, burada:

• PACKAGE@VERSION::UDT enum türü için tam olarak aynı tam nitelikli adı kullanır.
• VALUE, değerin adıdır.

Otomatik çıkarım kuralları

Tam nitelikli UDT adının belirtilmesi gerekmez. UDT adı şunları güvenli bir şekilde atlayın:

• Paket, ör. @1.0::IFoo.Type.
• Hem paket hem de sürüm, ör. IFoo.Type.

HIDL, otomatik müdahale kurallarını kullanarak adı tamamlamaya çalışır (alt kural) sayısı daha yüksek öncelik anlamına gelir).

1. Kural

Paket ve sürüm sağlanmazsa yerel ad arama denenir. Örnek:

interface Nfc {
    typedef string NfcErrorMessage;
    send(NfcData d) generates (@1.0::NfcStatus s, NfcErrorMessage m);
};

NfcErrorMessage yerel olarak aranır ve typedef bulunur. NfcData için de yerel arama yapılır, ancak yerel olarak tanımlanmadığından kural 2 ve 3 kullanılır. @1.0::NfcStatus. bir sürüm sağladığından 1. kural geçerli değildir.

2. Kural

1. kural başarısız olursa ve tam nitelikli adın bir bileşeni eksikse (paket, sürüm veya paket ve sürüm) içeriyorsa bileşen otomatik olarak bilgi edinin. Ardından HIDL derleyicisi geçerli dosyayı (ve tüm içe aktarmaları) tıklayarak otomatik doldurulan tam nitelikli adı bulabilirsiniz. Yukarıdaki örneği kullanarak ExtendedNfcData beyanını kabul edin (android.hardware.nfc) aynı pakette yapılmış sürümü (1.0) aşağıdaki gibi NfcData biçimindedir:

struct ExtendedNfcData {
    NfcData base;
    // … additional members
};

HIDL derleyicisi, paket adını ve sürüm adını tam nitelikli UDT adını üretmek için mevcut paketi android.hardware.nfc@1.0::NfcData Ad (doğru bir şekilde içe aktarıldığı varsayılırsa) taşımanın ardından beyanı.

Geçerli paketteki bir ad, yalnızca aşağıdakilerden biri doğru:

• Bu öğe, bir import ifadesiyle açık bir şekilde içe aktarılır.
• Mevcut pakette types.hal konumunda tanımlanmıştır

NfcData yalnızca sürüm numarası:

struct ExtendedNfcData {
    // autofill the current package name (android.hardware.nfc)
    @1.0::NfcData base;
    // … additional members
};

3. Kural

2. kural bir eşleşme oluşturamazsa (UDT geçerli paketinde yer alıyorsa HIDL derleyicisi, içe aktarılan tüm paketlerde eşleşme olup olmadığını tarar. Yukarıdaki örneği kullanarak ExtendedNfcData öğesinin android.hardware.nfc paketinin 1.1 sürümü, 1.1, 1.0 öğesini olması gerektiği gibi içe aktarır ( Paket Düzeyinde Uzantılar) ve bunların tanımı yalnızca UDT adını belirtir:

struct ExtendedNfcData {
    NfcData base;
    // … additional members
};

Derleyici, NfcData adlı herhangi bir UDT'yi arar ve 1.0 sürümünde android.hardware.nfc ile sonuçlanıyor android.hardware.nfc@1.0::NfcData tam nitelikli UDT'si. Daha fazlaysa HIDL derleyicisi olan kısmen nitelikli belirli bir UDT için birden fazla eşleşme bulundu hata verir.

Örnek

2. kural kullanılarak, mevcut pakette tanımlanmış içe aktarılan türe öncelik verilir başka bir paketten içe aktarılan bir tür:

// hardware/interfaces/foo/1.0/types.hal
package android.hardware.foo@1.0;
struct S {};

// hardware/interfaces/foo/1.0/IFooCallback.hal
package android.hardware.foo@1.0;
interface IFooCallback {};

// hardware/interfaces/bar/1.0/types.hal
package android.hardware.bar@1.0;
typedef string S;

// hardware/interfaces/bar/1.0/IFooCallback.hal
package android.hardware.bar@1.0;
interface IFooCallback {};

// hardware/interfaces/bar/1.0/IBar.hal
package android.hardware.bar@1.0;
import android.hardware.foo@1.0;
interface IBar {
    baz1(S s); // android.hardware.bar@1.0::S
    baz2(IFooCallback s); // android.hardware.foo@1.0::IFooCallback
};

• S değeri şöyle hesaplanır: android.hardware.bar@1.0::S ve şurada bulunur: bar/1.0/types.hal (çünkü types.hal otomatik olarak içe aktarılmıştır).
• IFooCallback değeri şöyle hesaplanır: android.hardware.bar@1.0::IFooCallback, 2. kuralı kullanıyor, ancak bar/1.0/IFooCallback.hal içe aktarılmadığı için bulunamıyor (types.hal gibi). Bu durumda, 3. kural Bunun yerine android.hardware.foo@1.0::IFooCallback (içe aktarılan) (import android.hardware.foo@1.0; üzerinden).

türler.hal

Her HIDL paketi UDT içeren bir types.hal dosyası içerir dahil edilir. HIDL türleri her zaman herkese açıktır, bir UDT’nin beyan edilmiş olup olmamasından bağımsız olarak types.hal bölümünde veya arayüz açıklamasında, bu türler kapsamın dışında kalan kişilere ulaşmaya yardımcı olur. types.hal. bir paketin genel API'sini açıklamak değil, UDT'leri barındırmaktır tüm arayüzler tarafından kullanılır. HIDL'nin yapısı nedeniyle tüm UDT'ler arayüzün parçasıdır.

types.hal, UDT'lerden ve import ifadelerinden oluşur. Çünkü types.hal, JavaScript'in paket (dolaylı bir içe aktarma işlemidir), bu import ifadeleri paket düzeyinde sunulur. types.hal kapsamındaki UDT'ler şunları da içerebilir: UDT'ler ve arayüzler içe aktarıldı.

Örneğin, IFoo.hal için:

package android.hardware.foo@1.0;
// whole package import
import android.hardware.bar@1.0;
// types only import
import android.hardware.baz@1.0::types;
// partial imports
import android.hardware.qux@1.0::IQux.Quux;
// partial imports
import android.hardware.quuz@1.0::Quuz;

Aşağıdakiler içe aktarılır:

• android.hidl.base@1.0::IBase (dolaylı olarak)
• android.hardware.foo@1.0::types (dolaylı olarak)
• android.hardware.bar@1.0 alanındaki her şey (tüm arayüzleri ve types.hal)
• types.hal, kalkış: android.hardware.baz@1.0::types (android.hardware.baz@1.0 ürünündeki arayüzler içe aktarılmaz)
• Şuradan IQux.hal ve types.hal: android.hardware.qux@1.0
• android.hardware.quuz@1.0 konumundan Quuz (varsa) Quuz, types.hal içinde tanımlanmıştır. types.hal dosyası ayrıştırıldı, ancak Quuz dışında türler içe aktarılmaz).

Arayüz düzeyinde sürüm oluşturma

Paket içindeki her arayüz kendi dosyasında bulunur. Paket ait olduğu arayüz, arayüzün üst kısmında package ifadesi. Paket beyanının ardından sıfır veya daha fazla arayüz düzeyinde içe aktarmalar (kısmi veya tam paket) listelenebilir. Örnek:

package android.hardware.nfc@1.0;

HIDL'de, arayüzler extends anahtar kelime. Bir arayüzün başka bir arayüzü genişletmesi için bu dosyaya import ekstresi ile erişmesi gerekir. Kişinin adı genişletilen arayüz (temel arayüz) type-name kurallarına uyuyor nitelendirmesi gerekir. Bir arayüz yalnızca bir arayüzden devralabilir; HIDL, çoklu devri desteklemez.

Aşağıdaki yükseltme sürümü örneklerinde şu paket kullanılmaktadır:

// types.hal
package android.hardware.example@1.0
struct Foo {
    struct Bar {
        vec<uint32_t> val;
    };
};

// IQuux.hal
package android.hardware.example@1.0
interface IQuux {
    fromFooToBar(Foo f) generates (Foo.Bar b);
}

Artış kuralları

package@major.minor paketini tanımlamak için A'yı veya B'nin tamamını tanımlayın doğru olmalıdır:

A Kuralı	"Başlangıç alt sürümüdür": Önceki tüm alt sürümler, package@major.0, package@major.1... package@major.(minor-1) tanımlanmamalıdır.

VEYA

B Kuralı

Aşağıdakilerin tümü doğrudur: "Önceki alt sürüm geçerli": package@major.(minor-1) tanımlanmalı ve aynı A kuralına ( package@major.0 - package@major.(minor-2) tanımlanmıştır) veya B kuralı (@major.(minor-2) tarihindeki artışsa); VE "Aynı ada sahip en az bir arayüz devral": Mevcut bir genişleyen package@major.minor::IFoo arayüzü package@major.(minor-1)::IFoo (önceki pakette arayüz varsa); VE "Farklı bir ada sahip devralınan arayüz yok": Farklı bir ad olmamalıdır package@major.minor::IBar uzatıldı package@major.(minor-1)::IBaz, burada IBar ve IBaz iki farklı addır. Bir arayüz varsa aynı ad, package@major.minor::IBar uzantısı uzun olmalıdır package@major.(minor-k)::IBar daha küçük k.

A kuralı nedeniyle:

• Paket, herhangi bir alt sürüm numarasıyla (örneğin, android.hardware.biometrics.fingerprint için başlangıç değeri: @2.1) dokunun.
• "android.hardware.foo@1.0" şartı tanımlanmadı anlamı hardware/interfaces/foo/1.0 dizininin olmaması bile gerekiyordu.

Ancak A kuralı, paket adı aynı ancak paket adı aynı olan farklı ana sürüm (örneğin, android.hardware.camera.device hem @1.0 hem de sahip @3.2 tanımlandı; @3.2 adlı kullanıcının, @1.0.) Dolayısıyla, @3.2::IExtFoo uzatılabilir @1.0::IFoo.

Paket adının farklı olması koşuluyla, package@major.minor::IBar, farklı bir ad kullanabilirsiniz (örneğin, android.hardware.bar@1.0::IBar android.hardware.baz@2.2::IBaz süresini uzatın). Bir arayüzde extend anahtar kelimesiyle açıkça bir süper tür tanımladığında, bu android.hidl.base@1.0::IBase tarihinde uzatılır (IBase hariç) ) ekleyebilirsiniz.

B.2 ve B.3 aynı anda izlenmelidir. Örneğin, android.hardware.foo@1.1::IFoo uzatma B.2 kuralına geçmek için android.hardware.foo@1.0::IFoo android.hardware.foo@1.1::IExtBar uzatma android.hardware.foo@1.0::IBar, bu hâlâ geçerli bir fiyat artışı değil.

Uprev arayüzleri

android.hardware.example@1.0 (yukarıda tanımlanmıştır) değerini şu değere yükseltmek için: @1.1:

// types.hal
package android.hardware.example@1.1;
import android.hardware.example@1.0;

// IQuux.hal
package android.hardware.example@1.1
interface IQuux extends @1.0::IQuux {
    fromBarToFoo(Foo.Bar b) generates (Foo f);
}

Bu, şu sürümün 1.0 sürümünün paket düzeyindeki import öğesidir: types.hal içinde android.hardware.example. Yeni olmasa da UDT'ler, paketin 1.1 sürümüne eklenir ve UDT'lere hâlâ 1.0 sürümü gerekiyor. Bu nedenle paket düzeyinde içe aktarma types.hal içinde. (Aynı etki, tek bir anahtar kelime ile IQuux.hal ürününde arayüz düzeyinde içe aktarma.)

extends @1.0::IQuux içindeki beyanda IQuux için geçerli olan IQuux sürümünü belirttik. devralınmıştır (IQuux, bir arayüz tanımlaması ve bir arayüzden devralması). Bu beyanlar sitesindeki tüm paket ve sürüm özelliklerini devralan açıklama, temel arayüzün adında olmalıdır; biz tam nitelikli UDT'yi de kullanabilirdi, ancak bu gereksiz.

Yeni arayüz IQuux, yöntemi yeniden bildirmiyor @1.0::IQuux öğesinden devraldığı fromFooToBar(); basitçe fromBarToFoo() eklediği yeni yöntemi listeliyor. HIDL'de, devralınan yöntemler alt arayüzlerde tekrar bildirilemez. Bu nedenle, IQuux arayüzü fromFooToBar() öğesini tanımlayamaz yöntemini açıkça belirtmelisiniz.

Artış kuralları

Bazen arayüz adları, genişleyen arayüzü yeniden adlandırmalıdır. Önerilerimiz: uzantı, struct ve union'ların, genişlettikleri uzantıyla aynı ada sahip olduğunu yeterli düzeyde farklı olmadıkları sürece geçerlidir. Örnekler:

// in parent hal file
enum Brightness : uint32_t { NONE, WHITE };

// in child hal file extending the existing set with additional similar values
enum Brightness : @1.0::Brightness { AUTOMATIC };

// extending the existing set with values that require a new, more descriptive name:
enum Color : @1.0::Brightness { HW_GREEN, RAINBOW };

Bir yöntemin yeni bir anlamsal adı varsa (örneğin, fooWithLocation) tercih edilir. Aksi takdirde benzer bir ada sahip olur. Örneğin, Bu işlev, @1.1::IFoo içinde foo_1_1 yerine kullanılabilir daha iyi bir yöntem değilse @1.0::IFoo içinde foo yönteminden tıklayın.

Paket düzeyinde sürüm oluşturma

HIDL sürümleri paket düzeyinde gerçekleşir; bir paketin yayınlanmasından sonra sabittir (arayüz grubu ve UDT'leri değiştirilemez). Paketler birbirleriyle birkaç şekilde ilişki kurabilir ve bunların tümü UDT'lerin kompozisyona göre oluşturulması ve arayüz düzeyinde devralmanın kombinasyonundan oluşur.

Ancak, bir ilişki türü kesin olarak tanımlanır ve uygulanması gerekir: Paket düzeyinde geriye dönük uyumlu devralma. Bu senaryoda parent paketi, devralınmakta olan pakettir ve child paketi, üst öğenin kapsamını genişleten pakettir. Paket düzeyi Geriye dönük uyumlu devralma kuralları şöyledir:

1. Üst paketin tüm üst düzey arayüzleri alt paketidir.
2. Yeni arayüzler de yeni pakete eklenebilir ( diğer paketlerdeki diğer arayüzlerle olan ilişkileri).
3. Yeni veri türleri de eklenebilir. Bu veri türleri, veya yeni arayüzler olabilir.

Bu kurallar, HIDL arayüz düzeyinde devralma ve UDT kullanılarak uygulanabilir ancak bu ilişkileri bilmek için üst düzey bilgiye geriye dönük uyumlu paket uzantıları oluşturur. Bu bilgi, projenin şu şekildedir:

Bir paket bu koşulu karşılıyorsa hidl-gen, geriye dönük uyumluluk kuralları da vardır.