Sürüm oluşturma

HIDL, HIDL ile yazılan her arayüzün versiyonlanmasını gerektirir. Bir HAL arabirimi yayınlandıktan sonra dondurulur ve bu arabirimin yeni bir sürümünde daha fazla değişiklik yapılması gerekir. Belirli bir yayınlanmış arabirim değiştirilemezken, başka bir arabirim 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 aracılığıyla daha karmaşık türleri oluşturmak için kullanılabilecek bir dizi ilkel veri türüne erişim sağlar. UDT'ler arabirim yöntemlerine iletilir ve bir paket düzeyinde (tüm arabirimler için ortak) veya yerel olarak bir arabirime tanımlanabilir.
• Arayüzler . HIDL'nin temel bir yapı taşı olan bir arabirim, UDT ve yöntem bildirimlerinden oluşur. Arayüzler başka bir arayüzden de miras alabilir.
• Paketler . İlgili HIDL arayüzlerini ve üzerinde çalıştıkları veri türlerini düzenler. Bir paket, bir ad ve sürümle tanımlanır ve aşağıdakileri içerir:
  • types.hal adlı veri türü tanımlama dosyası.
  • Her biri kendi .hal dosyasında sıfır veya daha fazla arabirim.

Veri türü tanım dosyası types.hal yalnızca UDT'leri içerir (tüm paket düzeyinde UDT'ler tek bir dosyada tutulur). Hedef dilde temsiller, paketteki tüm arayüzlerde mevcuttur.

Sürüm oluşturma felsefesi

Bir HIDL paketi (örneğin android.hardware.nfc ), belirli bir sürüm (örneğin 1.0 ) için yayınlandıktan sonra değişmezdir; değiştirilemez. Paketteki arabirimlerde yapılan değişiklikler veya UDT'lerinde yapılan değişiklikler yalnızca başka bir pakette gerçekleştirilebilir.

HIDL'de sürüm oluşturma, arabirim düzeyinde değil paket düzeyinde uygulanır ve bir paketteki tüm arabirimler 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 paket içinde, küçük sürüm tümseği, paketin yeni sürümünün eski paketle geriye dönük uyumlu olduğunu ve büyük sürüm tümseği, paketin yeni sürümünün eski paketle geriye dönük uyumlu olmadığını gösterir.

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

• Hiç de değil .
• Paket düzeyinde geriye dönük uyumlu genişletilebilirlik . Bu, bir paketin yeni alt sürüm yükseltmeleri (sonraki artan revizyon) için gerçekleşir; yeni paket, eski paketle aynı ada ve ana sürüme sahiptir, ancak daha yüksek bir alt sürüme sahiptir. İşlevsel olarak, yeni paket eski paketin bir üst kümesidir, yani:
  • Üst paketin üst düzey arabirimleri yeni pakette bulunur, ancak arabirimlerin yeni yöntemleri, yeni arabirim yerel UDT'leri (aşağıda açıklanan arabirim düzeyi uzantısı) ve type.hal içinde yeni types.hal .
  • Yeni pakete yeni arayüzler de eklenebilir.
  • Ana paketin tüm veri türleri yeni pakette bulunur ve eski paketteki (muhtemelen yeniden uygulanan) yöntemlerle işlenebilir.
  • Yeni veri türleri, güncellenmiş mevcut arayüzlerin yeni yöntemleri veya yeni arayüzler tarafından kullanılmak üzere eklenebilir.
• Arayüz düzeyinde geriye dönük uyumlu genişletilebilirlik . Yeni paket, aynı zamanda, asıl paketi değil, yalnızca ek işlevsellik sağlayan mantıksal olarak ayrı arabirimlerden oluşan orijinal paketi genişletebilir. Bu amaçla aşağıdakiler istenebilir:
  • Yeni paketteki arabirimler, eski paketin veri türlerine başvurmalıdır.
  • Yeni paketteki arabirimler, bir veya daha fazla eski paketin arabirimlerini genişletebilir.
• Orijinal geriye dönük uyumsuzluğu genişletin . Bu, paketin büyük bir versiyonudur ve ikisi arasında herhangi bir korelasyon olması gerekmez. Olduğu ölçüde, paketin eski sürümünden türlerin bir kombinasyonu ve eski paket arabirimlerinin bir alt kümesinin mirası ile ifade edilebilir.

Yapılandırma arayüzleri

İyi yapılandırılmış bir arayüz için, orijinal tasarımın parçası olmayan yeni işlevsellik türleri eklemek için HIDL arayüzünde bir değişiklik yapılması gerekir. Tersine, arayüzün kendisini değiştirmeden yeni işlevsellik getiren arayüzün her iki tarafında bir değişiklik yapabilir veya yapmayı bekliyorsanız, arayüz yapılandırılmamıştır.

Treble, bir aygıttaki vendor.img ve system.img ayrı ayrı derlenebildiği, ayrı olarak 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 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 süreçler 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 müşterinin ayrı ayrı derlendiğinde veya bağımsız olarak geliştirildiğinde bile birlikte çalışmaya devam edebilmesini sağlamak için veriler aşağıdaki gereksinimlere uymalıdır:

• Anlamsal adları ve anlamları ile HIDL'de doğrudan (yapı enumları vb. kullanılarak) tanımlanabilir.
• 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 veriler kullanılıyorsa, HIDL arayüzünün yalnızca bir tarafı tarafından okunmalıdır. Örneğin, vendor.img kodu system.img bir bileşene bir dize mesajı veya vec<uint8_t> verisi verirse, bu veriler system.img kendisi tarafından ayrıştırılamaz; yorumlanması için yalnızca vendor.img geri gönderilebilir. 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 açıklanmalıdır ve yine de arayüzün bir parçasıdır .

Yönergeler

Yalnızca .hal dosyalarını kullanarak bir HAL uygulaması veya istemcisi yazabilmeniz gerekir (yani Android kaynağına veya genel standartlara bakmanız gerekmez). Tam olarak gerekli davranışı belirtmenizi öneririz. "Bir uygulama A veya B yapabilir" gibi ifadeler, uygulamaların geliştirildikleri müşterilerle iç içe geçmesini teşvik eder.

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 adlandırma düzeyleriyle alt sistem tarafından adlandırılır. Örneğin, NFC paketi android.hardware.nfc olarak adlandırılır ve kamera paketi android.hardware.camera şeklindedir. Genel olarak, bir çekirdek paketin adı android.hardware. [ name1 ].[ name2 ]…. HIDL paketlerinin adlarına ek olarak bir sürümü vardır. Örneğin, android.hardware.camera paketi 3.4 sürümünde olabilir; Bu önemlidir, çünkü paketin sürümü kaynak ağaçtaki yerleşimini etkiler.

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

Ç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ına veya OEM/ODM'ye atıfta bulunur. Bu, ağaçtaki vendor/$(VENDOR)/interfaces yoluna eşlenir (bu eşleme ayrıca sabit kodlanmıştır).

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

HIDL'de her UDT, UDT adından, UDT'nin tanımlandığı paket adından ve paket sürümünden oluşan tam nitelikli bir ada sahiptir. Tam nitelikli 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 adlı bir yapı tanımladığını varsayalım. Bildirimin sitesinde ( types.hal içinde veya bir arabirimin bildirimi içinde), bildirim basitçe şunları belirtir:

struct NfcData {
    vec<uint8_t> data;
};

Bu türden bir örnek bildirirken (bir veri yapısı içinde veya bir 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 noktayla ayrılmış adıdır (örneğin, android.hardware.nfc ).
• VERSION , paketin noktayla ayrılmış majör.minor-sürüm biçimidir (örneğin, 1.0 ).
• UDT , bir HIDL UDT'nin noktayla ayrılmış adıdır. HIDL iç içe UDT'leri desteklediğinden ve HIDL arabirimleri 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ımlanmışsa:

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

Bar tam adı android.hardware.example@1.0::Foo.Bar . İç içe bildirim, yukarıdaki pakette olmanın yanı sıra IQuux adlı bir arabirimdeyse:

// 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 adlandırılabilir. Paket veya arabirim düzeyinde, yukarıdaki doSomething yönteminin bildiriminde olduğu gibi, Bar aracılığıyla Foo : Foo.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

Bir UDT bir numaralandırma türüyse, numaralandırma türünün her değeri, numaralandırma türünün tam adıyla başlayan, ardından iki nokta üst üste ve ardından numaralandırma değerinin adıyla başlayan tam nitelikli bir ada sahiptir. Örneğin, android.hardware.nfc, paketinin sürüm 1.0 bir NfcStatus enum türü tanımladığını varsayalım:

enum NfcStatus {
    STATUS_OK,
    STATUS_FAILED
};

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

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ı tam addır.
• VALUE , değerin adıdır.

Otomatik çıkarım kuralları

Tam nitelikli bir UDT adının belirtilmesi gerekmez. Bir UDT adı aşağıdakileri güvenle 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 (düşük kural numarası, daha yüksek öncelik anlamına gelir).

Kural 1

Paket ve sürüm sağlanmazsa, yerel ad araması denenir. Ö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 yerel olarak da aranır, ancak yerel olarak tanımlanmadığı için kural 2 ve 3 kullanılır. @1.0::NfcStatus bir sürüm sağlar, bu nedenle kural 1 uygulanmaz.

Kural 2

Kural 1 başarısız olursa ve tam nitelikli adın bir bileşeni (paket, sürüm veya paket ve sürüm) eksikse, bileşen geçerli paketteki bilgilerle otomatik olarak doldurulur. HIDL derleyicisi, 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 bildiriminin aşağıdaki gibi aynı pakette ( android.hardware.nfc ) NfcData ile 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 mevcut paketten paket adını ve sürüm adını doldurur. Geçerli pakette ad bulunduğundan (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 ifadesi ile açıkça içe aktarılır.
• Mevcut pakette types.hal içinde 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ımlanmaz), HIDL derleyicisi içe aktarılan tüm paketler içinde 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 gerektiği gibi içe aktardığını (bkz.

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

Derleyici, NfcData adlı herhangi bir NfcData ve 1.0 sürümünde android.hardware.nfc bir UDT bulur, bu da android.hardware.nfc@1.0::NfcData için tam nitelikli bir UDT ile 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 bir tür, başka bir paketten alınan bir tü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 içinde bulunur (çünkü types.hal otomatik olarak içe aktarılır).
• IFooCallback , kural 2 kullanılarak android.hardware.bar@1.0::IFooCallback olarak enterpole edilir, ancak bar/1.0/IFooCallback.hal otomatik olarak içe aktarılmadığından ( types.hal olduğu gibi) bulunamaz. Bu nedenle, kural 3 onu android.hardware.foo@1.0::IFooCallback olarak çözer ve import android.hardware.foo@1.0; ).

türler.hal

Her HIDL paketi, o pakete katılan tüm arabirimler arasında paylaşılan UDT'leri içeren bir types.hal dosyası içerir. HIDL türleri her zaman geneldir; Bir types.hal içinde mi yoksa bir arabirim bildirimi içinde mi bildirilmiş olduğuna bakılmaksızın, bu türlere tanımlandıkları kapsamın dışında erişilebilir. types.hal , bir paketin genel API'sini tanımlamayı değil, paket içindeki tüm arabirimler tarafından kullanılan UDT'leri barındırmayı amaçlar. HIDL'nin 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 arabiriminde kullanıma sunulduğundan (örtük bir içe aktarmadır), bu import ifadeleri tanım gereği paket düzeyindedir. type.hal içindeki types.hal ayrıca UDT'leri ve bu şekilde içe aktarılan arabirimleri 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 (dolaylı olarak)
• android.hardware.foo@1.0::types (dolaylı olarak)
• android.hardware.bar@1.0 içindeki her şey (tüm arayüzler ve onun types.hal dahil)
• android.hardware.baz@1.0::types types.hal ( android.hardware.baz@1.0 içindeki arayüzler içe aktarılmaz)
• android.hardware.qux@1.0 IQux.hal ve types.hal
• android.hardware.quuz@1.0 gelen Quuz ( Quuz içinde tanımlandığı varsayılırsa, types.hal dosyasının tamamı ayrıştırılır, ancak types.hal dışındaki Quuz içe aktarılmaz).

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

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

package android.hardware.nfc@1.0;

extends arabirimler, extensions anahtar sözcüğünü kullanarak diğer arabirimlerden miras alabilir. Bir arabirimin başka bir arabirimi genişletmesi için, ona bir import ifadesi aracılığıyla erişimi olması gerekir. Genişletilen arabirimin adı (temel arabirim), yukarıda açıklanan tür adı niteleme kurallarını takip eder. Bir arabirim yalnızca bir arabirimden miras alabilir; HIDL çoklu kalıtımı desteklemez.

Aşağıdaki uprev 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ükseltme kuralları

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

A kuralı nedeniyle:

• Paket herhangi bir küçük sürüm numarasıyla başlayabilir (örneğin, android.hardware.biometrics.fingerprint @2.1 başlar.)
• " android.hardware.foo@1.0 tanımlanmadı" gereksinimi, hardware/interfaces/foo/1.0 dizininin bile 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ımlıdır; @3.2 @1.0 ile etkileşime girmesi gerekmez) .) Bu nedenle, @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 arabirimden uzayabilir (örneğin, android.hardware.bar@1.0::IBar , android.hardware.baz@2.2:: android.hardware.baz@2.2::IBaz genişletebilir) ). Bir arabirim, extension anahtar sözcüğüyle açıkça bir süper tür bildirmezse, android.hidl.base@1.0::IBase extend ( IBase kendisi hariç).

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

Yükseltme arayüzleri

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, android.hardware.example 1.0 sürümünün types.hal içindeki paket düzeyinde import aktarımıdır. Paketin 1.1 sürümünde yeni UDT'ler eklenmemiş olsa da, sürüm 1.0 UDT'lere hala ihtiyaç vardır, bu nedenle types.hal içindeki paket düzeyinde içe aktarma. (Aynı etki, IQuux.hal arabirim düzeyinde içe aktarma ile elde edilebilirdi.)

IQuux bildirimindeki extends @1.0::IQuux IQuux , miras alınan IQuux sürümünü belirledik (anlam ayrımı gereklidir, çünkü IQuux bir arabirimi bildirmek ve bir arabirimden miras almak için kullanılır). Bildirimler, bildirimin sitesindeki tüm paket ve sürüm özniteliklerini devralan basit adlar olduğundan, anlam ayrımının temel arabirimin adında olması gerekir; tam nitelikli UDT'yi de kullanabilirdik, ancak bu gereksiz olurdu.

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

uprev sözleşmeleri

Bazen arabirim adları, genişleyen arabirimi yeniden adlandırmalıdır. Enum uzantılarının, yapılarının ve birleşimlerin, yeni bir ad gerektirecek kadar farklı olmadıkça, genişlettikleri adla aynı ada sahip olması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 semantik adı varsa (örneğin fooWithLocation ) bu tercih edilir. Aksi takdirde, genişlettiği şeye benzer şekilde adlandırılmalıdır. Örneğin, @1.1::IFoo foo_1_1 , daha iyi bir alternatif ad yoksa @1.0::IFoo foo yönteminin işlevselliğini değiştirebilir.

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şmezdir (arayüz seti ve UDT'leri değiştirilemez). Paketler birbirleriyle çeşitli şekillerde ilişkilendirilebilir ve bunların tümü, arayüz düzeyinde kalıtım ve UDT'lerin bileşime göre oluşturulmasının bir kombinasyonu yoluyla 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 devralma . Bu senaryoda, üst paket, devralınan pakettir ve alt paket, üst paketi genişleten pakettir. Paket düzeyinde geriye dönük uyumlu devralma kuralları aşağıdaki gibidir:

1. Üst paketin tüm üst düzey arabirimleri, alt paketteki arabirimler tarafından devralı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. Yeni veri türleri, güncellenmiş mevcut arayüzlerin yeni yöntemleri veya yeni arayüzler tarafından kullanılmak üzere eklenebilir.

Bu kurallar, HIDL arabirim düzeyinde miras 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 gerektirir. Bu bilgi şu şekilde anlaşılır:

Bir paket bu gereksinimi karşılarsa, hidl-gen geriye dönük uyumluluk kurallarını uygular.