Sürüm oluşturma

HIDL, HIDL'de yazılan her arayüzün sürümlendirilmesini gerektirir. Bir HAL arayüzü yayınlandıktan sonra dondurulur ve bu arayüzün yeni bir sürümünde başka değişiklikler yapılması gerekir. Belirli bir yayınlanmış arayüz değiştirilemezken, başka bir arayüz tarafından genişletilebilir.

HIDL kod yapısı

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

• Kullanıcı tanımlı türler (UDT'ler) . HIDL, yapılar, birleşimler ve numaralandırmalar yoluyla daha karmaşık türler oluşturmak için kullanılabilecek bir dizi ilkel veri türüne erişim sağlar. UDT'ler arayüz yöntemlerine aktarılır ve bir paket düzeyinde (tüm arayüzler için ortak) veya yerel olarak bir arayüze tanımlanabilir.
• Arayüzler . HIDL'nin temel yapı taşı olan arayüz, UDT ve yöntem bildirimlerinden oluşur. Arayüzler başka bir arayüzden de miras alabilir.
• Paketler . İlgili HIDL arayüzlerini ve bunların üzerinde çalıştığı veri türlerini düzenler. Bir paket, bir ad ve sürümle tanımlanır ve aşağıdakileri içerir:
  • types.hal adı verilen veri türü tanımlama dosyası.
  • Sıfır veya daha fazla arayüz, her biri kendi .hal dosyasında.

Veri türü tanımlama dosyası types.hal yalnızca UDT'leri içerir (tüm paket düzeyindeki UDT'ler tek bir dosyada tutulur). Hedef dildeki gösterimler paketteki tüm arayüzlerde mevcuttur.

Sürüm oluşturma felsefesi

Bir HIDL paketi ( android.hardware.nfc gibi) belirli bir sürüm için ( 1.0 gibi) yayınlandıktan sonra değiştirilemez; değiştirilemez. Paketteki arayüzlerde veya UDT'lerinde yapılacak değişiklikler yalnızca başka bir pakette yapılabilir.

HIDL'de sürüm oluşturma, arayüz düzeyinde değil paket düzeyinde uygulanır ve bir paketteki tüm arayüzler ve UDT'ler aynı sürümü paylaşır. Paket sürümleri, yama düzeyi ve yapı meta veri bileşenleri olmadan anlamsal sürüm oluşturmayı takip eder. Belirli bir pakette küçük sürüm artışı, paketin yeni sürümünün eski paketle geriye dönük olarak uyumlu olduğu anlamına gelirken, büyük sürüm artışı, paketin yeni sürümünün eski paketle geriye dönük olarak uyumlu olmadığı anlamına gelir.

Kavramsal olarak bir paket başka bir paketle çeşitli yollardan biriyle ilişkilendirilebilir:

• Hiç de bile .
• Paket düzeyinde geriye doğru uyumlu genişletilebilirlik . Bu, bir paketin yeni alt sürüm yükseltmelerinde (sonraki artan revizyon) meydana gelir; yeni paket eski paketle aynı ada ve ana sürüme sahiptir ancak daha yüksek bir ikincil sürüme sahiptir. İşlevsel olarak yeni paket eski paketin bir üst kümesidir, yani:
  • Ana paketin üst düzey arayüzleri yeni pakette mevcuttur, ancak arayüzler yeni yöntemlere, yeni arayüz-yerel UDT'lere (aşağıda açıklanan arayüz seviyesi uzantısı) ve types.hal yeni UDT'lere sahip olabilir.
  • Yeni pakete yeni arayüzler de eklenebilir.
  • Ana paketin tüm veri türleri yeni pakette mevcuttur ve eski paketteki (muhtemelen yeniden uygulanan) yöntemlerle işlenebilir.
  • Güncellenen mevcut arayüzlerin yeni yöntemleri veya yeni arayüzler tarafından kullanılmak üzere yeni veri türleri de eklenebilir.
• Arayüz düzeyinde geriye doğru uyumlu genişletilebilirlik . Yeni paket aynı zamanda orijinal paketi, temel işlevsellik yerine yalnızca ek işlevsellik sağlayan mantıksal olarak ayrı arayüzlerden oluşarak genişletebilir. Bu amaçla aşağıdakiler istenebilir:
  • Yeni paketteki arayüzlerin eski paketin veri türlerine başvurması gerekiyor.
  • Yeni paketteki arayüzler bir veya daha fazla eski paketin arayüzlerini genişletebilir.
• Orijinalin geriye dönük uyumsuzluğunu genişletin . Bu, paketin ana sürüm yükseltmesidir ve ikisi arasında herhangi bir korelasyon olması gerekmez. Var olduğu ölçüde, paketin eski sürümündeki türlerin bir kombinasyonu ve eski paket arayüzlerinin bir alt kümesinin kalıtımı ile ifade edilebilir.

Arayüzlerin yapılandırılması

İyi yapılandırılmış bir arayüz için, orijinal tasarımın parçası olmayan yeni işlevsellik türlerinin eklenmesi, HIDL arayüzünde değişiklik yapılmasını gerektirmelidir. Tersine, arayüzün kendisini değiştirmeden arayüzün her iki tarafında da yeni işlevler getiren bir değişiklik yapabiliyorsanız veya yapmayı bekliyorsanız, o zaman arayüz yapılandırılmış değildir.

Treble, bir cihazdaki vendor.img ve system.img ayrı ayrı derlenebildiği ayrı ayrı derlenmiş satıcı ve sistem bileşenlerini destekler. vendor.img ve system.img arasındaki tüm etkileşimler, uzun yıllar çalışmaya devam edebilmeleri için açıkça ve kapsamlı bir şekilde tanımlanmalıdır. Bu, birçok API yüzeyini içerir, ancak önemli bir yüzey, HIDL'nin system.img / vendor.img sınırında işlemler arası iletişim için kullandığı IPC mekanizmasıdır.

Gereksinimler

HIDL'den geçen tüm veriler açıkça tanımlanmalıdır. Bir uygulamanın ve istemcinin ayrı ayrı derlendiğinde veya bağımsız olarak geliştirildiğinde bile birlikte çalışmaya devam edebilmesini sağlamak için verilerin aşağıdaki gereksinimlere uyması gerekir:

• Anlamsal adlar ve anlamlarla doğrudan HIDL'de tanımlanabilir (yapı numaralandırmaları vb. kullanılarak).
• ISO/IEC 7816 gibi genel bir standartla tanımlanabilir.
• Bir donanım standardı veya donanımın fiziksel düzeni ile tanımlanabilir.
• Gerekirse opak veriler (genel anahtarlar, kimlikler vb.) olabilir.

Opak veri kullanılıyorsa, HIDL arayüzünün yalnızca bir tarafı tarafından okunmalıdır. Örneğin, vendor.img kodu, system.img dosyasındaki bir bileşene bir dize mesajı veya vec<uint8_t> verisi veriyorsa, bu veriler system.img kendisi tarafından ayrıştırılamaz; yorumlamak için yalnızca vendor.img geri aktarılabilir. vendor.img system.img satıcı koduna veya başka bir cihaza bir değer aktarırken, verinin formatı ve nasıl yorumlanacağı tam olarak tanımlanmalıdır ve yine de arayüzün bir parçasıdır.

Yönergeler

Yalnızca .hal dosyalarını kullanarak bir HAL uygulamasını veya istemcisini yazabilmeniz gerekir (yani, Android kaynağına veya genel standartlara bakmanıza gerek olmamalıdır). Gerekli davranışı tam olarak belirtmenizi öneririz. "Bir uygulama A veya B yapabilir" gibi ifadeler, uygulamaların birlikte geliştirildiği istemcilerle iç içe geçmesini teşvik etmektedir.

HIDL kod düzeni

HIDL, çekirdek ve satıcı paketlerini içerir.

Çekirdek HIDL arayüzleri Google tarafından belirtilen arayüzlerdir. Ait oldukları paketler android.hardware. ve potansiyel olarak iç içe geçmiş adlandırma düzeyleriyle alt sisteme göre adlandırılır. Örneğin, NFC paketinin adı android.hardware.nfc , kamera paketinin adı ise android.hardware.camera . Genel olarak bir çekirdek paket android.hardware. [ name1 ].[ name2 ]…. HIDL paketlerinin ismine ek olarak bir versiyonu da vardır. Örneğin, android.hardware.camera paketi 3.4 sürümünde olabilir; Bu önemlidir, çünkü bir paketin sürümü onun kaynak ağaçtaki yerleşimini etkiler.

Tüm çekirdek paketler yapı sisteminde hardware/interfaces/ altına yerleştirilir. android.hardware. [ name1 ].[ name2 ]… $m.$n sürümünde hardware/interfaces/name1/name2/ … /$m.$n/ altındadır; android.hardware.camera sürüm 3.4 paketi hardware/interfaces/camera/3.4/. android.hardware. ve hardware/interfaces/ yolu.

Çekirdek olmayan (satıcı) paketler, SoC satıcısı veya ODM tarafından üretilen paketlerdir. Çekirdek olmayan paketlerin öneki vendor.$(VENDOR).hardware. burada $(VENDOR) bir SoC satıcısını veya OEM/ODM'yi ifade eder. Bu, ağaçtaki vendor/$(VENDOR)/interfaces yolu ile eşleşir (bu eşleme aynı zamanda sabit kodlanmıştır).

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

HIDL'de her UDT'nin, UDT adından, UDT'nin tanımlandığı paket adından ve paket sürümünden oluşan tam nitelikli bir adı vardır. Tam nitelenmiş ad, türün kendisinin tanımlandığı yerde değil, yalnızca türün örnekleri bildirildiğinde kullanılır. Örneğin, android.hardware.nfc, sürüm 1.0 NfcData adında bir yapıyı tanımladığını varsayalım. Bildirimin sitesinde ( types.hal veya bir arayüzün bildiriminde olsun), bildirim basitçe şunu belirtir:

struct NfcData {
    vec<uint8_t> data;
};

Bu türün bir örneğini bildirirken (bir 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özdizimi PACKAGE @ VERSION :: UDT şeklindedir; burada:

• PACKAGE , bir HIDL paketinin noktalarla ayrılmış adıdır (örneğin, android.hardware.nfc ).
• VERSION , paketin noktayla ayrılmış major.minor sürüm biçimidir (örneğin, 1.0 ).
• UDT , HIDL UDT'nin noktalarla ayrılmış adıdır. HIDL iç içe UDT'leri desteklediğinden ve HIDL arayüzleri UDT'leri (bir tür iç içe bildirim) içerebildiğinden, adlara erişmek için noktalar kullanılır.

Örneğin, android.hardware.example sürüm 1.0 paketindeki ortak türler dosyasında aşağıdaki iç içe bildirim tanımlandıysa:

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

Bar tam adı android.hardware.example@1.0::Foo.Bar . Yukarıdaki pakete ek olarak iç içe geçmiş bildirim IQuux adlı bir arayüzde olsaydı:

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

Bar tam adı android.hardware.example@1.0::IQuux.Foo.Bar .

Her iki durumda da Bar , yalnızca Foo bildirimi kapsamında Bar olarak anılabilir. Paket veya arayüz düzeyinde, yukarıdaki doSomething yönteminin bildiriminde olduğu gibi, Foo : Foo.Bar aracılığıyla Bar başvurmalısınız. Alternatif olarak, yöntemi daha ayrıntılı olarak şu şekilde bildirebilirsiniz:

// 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 numaralandırma türüyse, numaralandırma türünün her değeri, numaralandırma türünün tam nitelikli adıyla başlayan, ardından iki nokta üst üste gelen ve ardından numaralandırma değerinin adıyla başlayan tam nitelikli bir ada sahiptir. Örneğin, android.hardware.nfc, sürüm 1.0 NfcStatus enum türünü tanımladığını varsayalım:

enum NfcStatus {
    STATUS_OK,
    STATUS_FAILED
};

STATUS_OK atıfta bulunulduğunda, tam nitelikli ad şöyledir:

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

Genel sözdizimi PACKAGE @ VERSION :: UDT : VALUE şeklindedir; burada:

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

Otomatik çıkarım kuralları

Tam nitelikli bir UDT adının belirtilmesine gerek yoktur. Bir UDT adı aşağıdakileri güvenli bir şekilde atlayabilir:

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

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

Kural 1

Paket ve sürüm sağlanmazsa yerel ad araması yapılmaya çalışılır. Örnek:

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

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

Kural 2

Kural 1 başarısız olursa ve tam adın bir bileşeni eksikse (paket, sürüm veya paket ve sürüm), bileşen geçerli paketteki bilgilerle otomatik olarak doldurulur. HIDL derleyicisi daha sonra otomatik olarak doldurulmuş tam nitelikli adı bulmak için geçerli dosyaya (ve tüm içe aktarmalara) bakar. Yukarıdaki örneği kullanarak, ExtendedNfcData beyanının aşağıdaki gibi NfcData ile aynı pakette ( android.hardware.nfc ) ve aynı sürümde ( 1.0 ) yapıldığını varsayalım:

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

HIDL derleyicisi, tam nitelikli UDT adını android.hardware.nfc@1.0::NfcData oluşturmak için geçerli paketteki paket adını ve sürüm adını doldurur. Adın geçerli pakette mevcut olması nedeniyle (doğru şekilde içe aktarıldığı varsayılarak), bildirim için kullanılır.

Geçerli paketteki bir ad yalnızca aşağıdakilerden biri doğruysa içe aktarılır:

• Bir import ifadesiyle açıkça içe aktarılır.
• Mevcut paketteki types.hal dosyasında tanımlanmıştır.

NfcData yalnızca sürüm numarasıyla nitelendirilmişse aynı süreç izlenir:

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

Kural 3

Kural 2 bir eşleşme üretemezse (UDT geçerli pakette tanımlanmamıştır), HIDL derleyicisi içe aktarılan tüm paketlerde bir eşleşme arar. Yukarıdaki örneği kullanarak, ExtendedNfcData android.hardware.nfc paketinin 1.1 sürümünde bildirildiğini, 1.1 1.0 olması gerektiği gibi içe aktardığını (bkz . Paket Düzeyi Uzantıları ) ve tanımın yalnızca UDT adını belirttiğini varsayalım:

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

Derleyici, NfcData adlı herhangi bir UDT'yi arar ve sürüm 1.0 android.hardware.nfc içinde bir tane bulur; bu android.hardware.nfc@1.0::NfcData tam nitelikli bir UDT'siyle sonuçlanır. Belirli bir kısmen nitelikli UDT için birden fazla eşleşme bulunursa HIDL derleyicisi bir hata verir.

Örnek

Kural 2'yi kullanarak, geçerli pakette tanımlanan içe aktarılan tür, başka bir paketten içe aktarılan türe göre tercih edilir:

// 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 android.hardware.bar@1.0::S olarak enterpolasyonludur ve bar/1.0/types.hal dosyasında bulunur (çünkü types.hal otomatik olarak içe aktarılır).
• IFooCallback kural 2 kullanılarak android.hardware.bar@1.0::IFooCallback olarak enterpolasyona tabi tutulur, ancak bar/1.0/IFooCallback.hal otomatik olarak içe aktarılmadığından ( types.hal olduğu gibi) bulunamaz. Böylece, kural 3 bunu android.hardware.foo@1.0::IFooCallback olarak çözer; bu, import android.hardware.foo@1.0; aracılığıyla içe aktarılır. ).

türleri.hal

Her HIDL paketi, o pakete katılan tüm arayüzler arasında paylaşılan UDT'leri içeren bir types.hal dosyası içerir. HIDL türleri her zaman geneldir; Bir UDT'nin types.hal mi yoksa bir arayüz bildiriminde mi bildirildiğine bakılmaksızın, bu türlere tanımlandıkları kapsamın dışından erişilebilir. types.hal bir paketin genel API'sini tanımlamak için değil, paket içindeki tüm arayüzler tarafından kullanılan UDT'leri barındırmak için tasarlanmıştır. HIDL'in doğası gereği tüm UDT'ler arayüzün bir parçasıdır.

types.hal UDT'lerden ve import ifadelerinden oluşur. types.hal paketin her arayüzünde mevcut olduğundan (bu örtülü bir içe aktarmadır), bu import ifadeleri tanım gereği paket düzeyindedir. types.hal UDT'ler, bu şekilde içe aktarılan UDT'leri ve arayüzleri de içerebilir.

Örneğin, bir 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 (örtük olarak)
• android.hardware.foo@1.0::types (örtük olarak)
• android.hardware.bar@1.0 içindeki her şey (tüm arayüzler ve types.hal dahil)
• android.hardware.baz@1.0::types adresinden types.hal ( android.hardware.baz@1.0 arayüzler içe aktarılmaz)
• android.hardware.qux@1.0 adresinden IQux.hal ve types.hal
• android.hardware.quuz@1.0 adresinden Quuz ( Quuz types.hal içinde tanımlandığı varsayılırsa, tüm types.hal dosyası ayrıştırılır, ancak Quuz dışındaki türler içe aktarılmaz).

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

Bir paket içindeki her arayüz kendi dosyasında bulunur. Arayüzün ait olduğu paket, package ifadesi kullanılarak arayüzün üst kısmında bildirilir. Paket bildiriminin ardından sıfır veya daha fazla arayüz düzeyinde içe aktarma (kısmi veya tam paket) listelenebilir. Örneğin:

package android.hardware.nfc@1.0;

HIDL'de arayüzler, extends anahtar sözcüğünü kullanarak diğer arayüzlerden miras alabilir. Bir arayüzün başka bir arayüzü genişletebilmesi için, ona bir import ifadesi aracılığıyla erişebilmesi gerekir. Genişletilen arayüzün adı (temel arayüz), yukarıda açıklanan tür adı nitelendirme kurallarına uygundur. Bir arayüz yalnızca bir arayüzden miras alabilir; HIDL çoklu kalıtımı desteklemez.

Aşağıdaki güncel sürüm oluşturma örnekleri aşağıdaki paketi kullanı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);
}

Yükseliş kuralları

package@major.minor paketini tanımlamak için A'nın veya B'nin tamamının doğru olması gerekir:

A kuralı nedeniyle:

• Paket herhangi bir küçük sürüm numarasıyla başlayabilir (örneğin, android.hardware.biometrics.fingerprint @2.1 ile başlar.)
• " android.hardware.foo@1.0 tanımlı değil" gereksinimi hardware/interfaces/foo/1.0 dizininin mevcut olmaması gerektiği anlamına gelir.

Ancak kural A, aynı paket adına sahip ancak farklı bir ana sürüme sahip bir paketi etkilemez (örneğin, android.hardware.camera.device hem @1.0 hem de @3.2 tanımlanmıştır; @3.2 @1.0 ile etkileşime girmesi gerekmez) .) Dolayısıyla, @3.2::IExtFoo @1.0::IFoo genişletebilir.

Paket adının farklı olması koşuluyla package@major.minor::IBar farklı bir ada sahip bir arayüzden genişletilebilir (örneğin, android.hardware.bar@1.0::IBar android.hardware.baz@2.2::IBaz genişletebilir) ). Bir arayüz, extend anahtar sözcüğüyle açıkça bir süper tür bildirmezse, android.hidl.base@1.0::IBase genişletecektir ( IBase kendisi hariç).

B.2 ve B.3 aynı anda takip edilmelidir. Örneğin, android.hardware.foo@1.1::IFoo , B.2 kuralını geçmek için android.hardware.foo@1.0::IFoo genişletse bile, bir android.hardware.foo@1.1::IExtBar android.hardware.foo@1.0::IBar , bu hala geçerli bir artış değil.

Arayüzlerin iyileştirilmesi

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

// 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, types.hal dosyasındaki android.hardware.example sürümünün 1.0 sürümünün paket düzeyinde içe import . Paketin 1.1 sürümünde yeni UDT'ler eklenmese de, sürüm 1.0 UDT'lere yapılan referanslara hala ihtiyaç duyulmaktadır; dolayısıyla, types.hal dosyasında paket düzeyinde içe aktarma yapılması gerekmektedir. (Aynı etki, IQuux.hal arayüz düzeyinde bir içe aktarma işlemiyle de elde edilebilirdi.)

IQuux bildirimindeki extends @1.0::IQuux IQuux'da, miras alınan IQuux sürümünü belirttik ( IQuux bir arayüz bildirmek ve bir arayüzden miras almak için kullanıldığı için belirsizliğin giderilmesi gerekiyor). Bildirimler, bildirimin yapıldığı sitedeki tüm paket ve sürüm niteliklerini devralan basit adlar olduğundan, belirsizliğin giderilmesi temel arabirimin adında olmalıdır; tam nitelikli UDT'yi de kullanabilirdik, ancak bu gereksiz olurdu.

Yeni arayüz IQuux @1.0::IQuux devraldığı fromFooToBar() yöntemini yeniden bildirmez; sadece fromBarToFoo() dan eklediği yeni yöntemi listeler. HIDL'de, devralınan yöntemler alt arabirimlerde yeniden bildirilemez , dolayısıyla IQuux arabirimi fromFooToBar() yöntemini açıkça bildiremez.

Uprev sözleşmeleri

Bazen arayüz adlarının genişleyen arayüzü yeniden adlandırması gerekir. Enum uzantılarının, yapılarının ve birleşimlerinin, yeni bir adı garanti edecek kadar farklı olmadıkları sürece, genişlettikleri ile aynı ada sahip olmalarını öneririz. Ö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 ), bu tercih edilir. Aksi takdirde uzandığı şeye benzer şekilde isimlendirilmelidir. Örneğin, @1.1::IFoo foo_1_1 yöntemi, daha iyi bir alternatif ad yoksa @1.0::IFoo IFoo'daki foo yönteminin işlevselliğinin yerini alabilir.

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

HIDL sürüm oluşturma paket düzeyinde gerçekleşir; Bir paket yayınlandıktan sonra değiştirilemez (arayüzler ve UDT'ler değiştirilemez). Paketler birbirleriyle çeşitli şekillerde ilişki kurabilir; bunların tümü, arayüz düzeyinde kalıtım ve bileşime göre UDT'lerin oluşturulması kombinasyonuyla ifade edilebilir.

Ancak bir tür ilişki kesin olarak tanımlanmıştır ve uygulanması gerekir: Paket düzeyinde geriye dönük uyumlu miras . Bu senaryoda ana paket, devralınan pakettir ve alt paket, üst paketi genişleten pakettir. Paket düzeyinde geriye dönük uyumlu miras kuralları aşağıdaki gibidir:

1. Ana paketin tüm üst düzey arayüzleri, alt paketteki arayüzlerden miras alınır.
2. Yeni pakete yeni arayüzler de eklenebilir (diğer paketlerdeki diğer arayüzlerle ilişkiler konusunda herhangi bir kısıtlama yoktur).
3. Güncellenen mevcut arayüzlerin yeni yöntemleri veya yeni arayüzler tarafından kullanılmak üzere yeni veri türleri de eklenebilir.

Bu kurallar, HIDL arayüz düzeyinde kalıtım ve UDT bileşimi kullanılarak uygulanabilir, ancak bu ilişkilerin geriye dönük uyumlu bir paket uzantısı oluşturduğunu bilmek için meta düzeyinde bilgi gerekir. Bu bilgi şu şekilde anlaşılmaktadır:

Bir paket bu gereksinimi karşılıyorsa, hidl-gen geriye dönük uyumluluk kurallarını zorunlu kılar.