Arayüzler ve Paketler

HIDL, nesne yönelimli dillerde davranışları tanımlamak için kullanılan soyut bir tür olan arayüzler etrafında oluşturulmuştur. Her arayüz bir paketin parçasıdır.

Paketler

Paket adlarının package.subpackage gibi alt düzeyleri olabilir. Yayınlanan HIDL paketlerinin kök dizini hardware/interfaces veya vendor/vendorName (ör. Pixel cihazları için vendor/google ). Paket adı, kök dizin altında bir veya daha fazla alt dizin oluşturur; Bir paketi tanımlayan tüm dosyalar aynı dizindedir. Örneğin, package android.hardware.example.extension.light@2.0 hardware/interfaces/example/extension/light/2.0 altında bulunabilir.

Aşağıdaki tabloda paket önekleri ve konumları listelenmektedir:

Paket dizini .hal uzantılı dosyalar içerir. Her dosya, dosyanın parçası olduğu paketi ve sürümü adlandıran bir package ifadesi içermelidir. types.hal dosyası, eğer mevcutsa, bir arayüz tanımlamaz ancak bunun yerine paketteki her arayüz tarafından erişilebilen veri türlerini tanımlar.

Arayüz tanımı

types.hal dışında diğer tüm .hal dosyaları bir arayüz tanımlar. Bir arayüz genellikle şu şekilde tanımlanır:

interface IBar extends IFoo { // IFoo is another interface
    // embedded types
    struct MyStruct {/*...*/};

    // interface methods
    create(int32_t id) generates (MyStruct s);
    close();
};

Açık bir extends olmayan bir arayüz örtülü olarak android.hidl.base@1.0::IBase uzanır (Java'daki java.lang.Object benzer). Örtülü olarak içe aktarılan IBase arayüzü, yeniden bildirilmemesi gereken ve bildirilemeyecek birkaç ayrılmış yöntemi bildirir. kullanıcı tanımlı arayüzlerde veya başka şekilde kullanılır. Bu yöntemler şunları içerir:

• ping
• interfaceChain
• interfaceDescriptor
• notifySyspropsChanged
• linkToDeath
• unlinkToDeath
• setHALInstrumentation
• getDebugInfo
• debug
• getHashChain

İthalat

import ifadesi, başka bir paketteki paket arayüzlerine ve türlerine erişim sağlayan HIDL mekanizmasıdır. Bir import beyanı iki varlıkla ilgilidir:

• Bir paket veya arayüz olabilen içe aktaran varlık; Ve
• İçe aktarılan varlık; bu da bir paket veya arayüz olabilir.

İçe aktaran varlık, import bildiriminin konumuna göre belirlenir. İfade bir paketin types.hal içinde olduğunda, içe aktarılan şey paketin tamamı tarafından görülebilir; bu paket düzeyinde bir içe aktarmadır. İfade bir arayüz dosyasının içinde olduğunda, içe aktaran varlık arayüzün kendisidir; bu arayüz düzeyinde bir içe aktarmadır.

İçe aktarılan varlık, import anahtar sözcüğünden sonraki değere göre belirlenir. Değerin tam olarak nitelenmiş bir ad olması gerekmez; bir bileşen atlanırsa otomatik olarak geçerli paketteki bilgilerle doldurulur. Tam nitelikli değerler için aşağıdaki içe aktarma durumları desteklenir:

• Tam paket ithalatı . Değer bir paket adı ve sürümse (sözdizimi aşağıda açıklanmıştır), paketin tamamı içe aktaran varlığa içe aktarılır.
• Kısmi ithalat . Değer şuysa:
  • Bir arayüz, paketin types.hal ve bu arayüz, içe aktaran varlığa aktarılır.
  • types.hal içinde tanımlanan bir UDT, ardından içe aktaran varlığa yalnızca bu UDT içe aktarılır ( types.hal içindeki diğer türler içe aktarılmaz).
• Yalnızca türlerin içe aktarılması . Değer, yukarıda açıklanan kısmi içe aktarmanın sözdizimini kullanıyorsa ancak Arayüz adı yerine types anahtar sözcüğüyle kullanılıyorsa, yalnızca belirlenen paketin types.hal dosyasındaki UDT'ler içe aktarılır.

İçe aktaran varlık aşağıdakilerin bir kombinasyonuna erişebilir:

• İçe aktarılan paketin types.hal dosyasında tanımlanan ortak UDT'leri;
• İçe aktarılan paketin arayüzleri (tüm paketin içe aktarımı için) veya belirtilen arayüzler (kısmi içe aktarma için), bunları çağırmak, bunlara tanıtıcılar aktarmak ve/veya onlardan miras almak amacıyla.

Import deyimi, içe aktarılan paketin veya arayüzün adını ve sürümünü sağlamak için tam nitelikli tür adı sözdizimini kullanır:

import android.hardware.nfc@1.0;            // import a whole package
import android.hardware.example@1.0::IQuux; // import an interface and types.hal
import android.hardware.example@1.0::types; // import just types.hal

Arayüz mirası

Bir arayüz önceden tanımlanmış bir arayüzün uzantısı olabilir. Uzantılar aşağıdaki üç türden biri olabilir:

• Arayüz, API'sini değiştirmeden birleştirerek diğerine işlevsellik ekleyebilir.
• Paket, API'sini değiştirmeden birleştirerek diğerine işlevsellik ekleyebilir.
• Arayüz, türleri bir paketten veya belirli bir arayüzden içe aktarabilir.

Bir arayüz yalnızca bir diğer arayüzü genişletebilir (çoklu miras yoktur). Sıfırdan farklı bir alt sürüm numarasına sahip bir paketteki her arayüz, paketin önceki sürümündeki bir arayüzü genişletmelidir. Örneğin, derivative paketinin 4.0 sürümündeki bir IBar arayüzü, original paketinin 1.2 sürümündeki IFoo arayüzünü temel alıyorsa (genişletiyorsa) ve original paketin 1.3 sürümü oluşturulduysa, IBar sürüm 4.1, IFoo 1.3 sürümünü genişletemez. Bunun yerine, IBar sürüm 4.1'in, IFoo sürüm 1.2'ye bağlı olan IBar sürüm 4.0'ı genişletmesi gerekir. IBar sürüm 5.0, istenirse IFoo sürüm 1.3'ü genişletebilir.

Arayüz uzantıları, kütüphane bağımlılığını veya oluşturulan koda çapraz HAL dahil edilmesini ima etmez; yalnızca veri yapısını ve yöntem tanımlarını HIDL düzeyinde içe aktarırlar. Bir HAL'deki her yöntemin o HAL'de uygulanması gerekir.

Satıcı uzantıları

Bazı durumlarda satıcı uzantıları, genişlettikleri çekirdek arayüzü temsil eden temel nesnenin bir alt sınıfı olarak uygulanacaktır. Aynı nesne, temel HAL adı ve sürümü ile uzantının (satıcı) HAL adı ve sürümü altında kaydedilecektir.

Sürüm oluşturma

Paketler sürümlendirilmiştir ve arayüzler paketlerinin sürümüne sahiptir. Sürümler major olmak üzere iki tam sayıyla ifade edilir. küçük .

• Ana sürümler geriye dönük olarak uyumlu değildir. Ana sürüm numarasını artırmak, ikincil sürüm numarasını 0'a sıfırlar.
• Küçük sürümler geriye dönük olarak uyumludur. Küçük sayının artırılması, yeni sürümün önceki sürümle tamamen geriye dönük uyumlu olduğunu gösterir. Yeni veri yapıları ve yöntemleri eklenebilir ancak mevcut veri yapıları veya yöntem imzaları değiştirilemez.

Bir HAL'ın birden fazla ana veya alt sürümü bir cihazda aynı anda mevcut olabilir. Ancak, önceki bir alt sürüm arayüzüyle çalışan istemci kodu, aynı arayüzün daha sonraki alt sürümleriyle de çalışacağından, ana sürüme göre küçük bir sürüm tercih edilmelidir. Sürüm oluşturma ve satıcı uzantıları hakkında daha fazla ayrıntı için bkz. HIDL Sürüm Oluşturma .

Arayüz düzeni özeti

Bu bölüm bir HIDL arayüz paketinin ( hardware/interfaces gibi) nasıl yönetileceğini özetlemekte ve HIDL bölümü boyunca sunulan bilgileri bir araya getirmektedir. Okumadan önce, HIDL Sürüm Oluşturma , hidl-gen ile Hashing'deki karma kavramları, genel olarak HIDL ile çalışmanın ayrıntıları ve aşağıdaki tanımlara aşina olduğunuzdan emin olun:

Daha fazla tanım için bkz. HIDL Terminolojisi .

Her dosya paketin kök eşlemesinden ve tam adından bulunabilir.

Paket kökleri hidl-gen -r android.hardware:hardware/interfaces argümanı olarak belirtilir. Örneğin, paket vendor.awesome.foo@1.0::IFoo ise ve hidl-gen -r vendor.awesome:some/device/independent/path/interfaces gönderilirse, arayüz dosyası $ANDROID_BUILD_TOP/some/device/independent/path/interfaces/foo/1.0/IFoo.hal konumunda bulunmalıdır. $ANDROID_BUILD_TOP/some/device/independent/path/interfaces/foo/1.0/IFoo.hal .

Uygulamada, awesome adlı bir satıcının veya OEM'in standart arayüzlerini vendor.awesome içine koyması önerilir. Bir paket yolu seçildikten sonra, arayüzün ABI'sine ekleneceği için değiştirilmemelidir.

Paket yolu eşlemesi benzersiz olmalıdır

Örneğin, -rsome.package:$PATH_A ve -rsome.package:$PATH_B varsa, tutarlı bir arayüz dizini için $PATH_A $PATH_B eşit olması gerekir (bu aynı zamanda arayüzlerin sürümlendirilmesini de çok kolaylaştırır).

Paket kökünün bir sürüm dosyası olması gerekir

-r vendor.awesome:vendor/awesome/interfaces gibi bir paket yolu oluşturursanız, aynı zamanda -Lhash kullanılarak oluşturulan arayüz karmalarını içermesi gereken $ANDROID_BUILD_TOP/vendor/awesome/interfaces/current.txt dosyasını da oluşturmalısınız. hidl-gen seçenek (bu , Hashing with hidl-gen'de kapsamlı olarak tartışılmıştır).

Arayüzler cihazdan bağımsız konumlara gider

Uygulamada şubeler arasında arayüzlerin paylaşılması tavsiye edilmektedir. Bu, kodun maksimum yeniden kullanımına ve farklı cihazlar ve kullanım senaryoları arasında maksimum kod testine olanak tanır.