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.
- Ü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
- 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 vebar/1.0/types.hal
içinde bulunur (çünkütypes.hal
otomatik olarak içe aktarılır). -
IFooCallback
, kural 2 kullanılarakandroid.hardware.bar@1.0::IFooCallback
olarak enterpole edilir, ancakbar/1.0/IFooCallback.hal
otomatik olarak içe aktarılmadığından (types.hal
olduğu gibi) bulunamaz. Bu nedenle, kural 3 onuandroid.hardware.foo@1.0::IFooCallback
olarak çözer veimport 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 onuntypes.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
vetypes.hal
-
android.hardware.quuz@1.0
gelenQuuz
(Quuz
içinde tanımlandığı varsayılırsa,types.hal
dosyasının tamamı ayrıştırılır, ancaktypes.hal
dışındakiQuuz
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:
Kural A | "Bir başlangıç minör sürümüdür": Tüm önceki küçük sürümler, package@major.0 , package@major.1 , …, package@major.(minor-1) tanımlanmamalıdır. |
---|
Kural B | Aşağıdakilerin tümü doğrudur:
|
---|
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:
- Üst paketin tüm üst düzey arabirimleri, alt paketteki arabirimler tarafından devralınır.
- Yeni pakete yeni arayüzler de eklenebilir (diğer paketlerdeki diğer arayüzlerle ilişkiler konusunda herhangi bir kısıtlama yoktur).
- 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.