HAL Arayüzü Oluşturma

Çerçeveyi koşullu olarak derlemek için kullanılan tüm yapı bayraklarını tanımlamak için HIDL kullanmalısınız. İlgili derleme bayrakları gruplandırılmalı ve tek bir .hal dosyasına dahil edilmelidir. Yapılandırma öğelerini belirtmek için HIDL'nin kullanılması aşağıdaki faydaları içerir:

• Sürümlü (yeni yapılandırma öğeleri eklemek için satıcılar/OEM'ler HAL'ı açıkça genişletmelidir)
• İyi belgelenmiş
• SELinux kullanarak erişim kontrolü
• Satıcı Test Paketi aracılığıyla yapılandırma öğeleri için sağlık kontrolü (aralık kontrolü, öğeler arasında bağımlılık kontrolü vb.)
• Hem C++ hem de Java'da otomatik oluşturulan API'ler

Çerçeve tarafından kullanılan yapı bayraklarını belirleme

Çerçeveyi koşullu olarak derlemek için kullanılan yapı yapılandırmalarını tanımlayarak başlayın, ardından seti küçültmek için eski yapılandırmalardan vazgeçin. Örneğin, surfaceflinger için aşağıdaki derleme işaretleri tanımlanmıştır:

• TARGET_USES_HWC2
• TARGET_BOARD_PLATFORM
• TARGET_DISABLE_TRIPLE_BUFFERING
• TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
• NUM_FRAMEBUFFER_SURFACE_BUFFERS
• TARGET_RUNNING_WITHOUT_SYNC_FRAMEWORK
• VSYNC_EVENT_PHASE_OFFSET_NS
• SF_VSYNC_EVENT_PHASE_OFFSET_NS
• PRESENT_TIME_OFFSET_FROM_VSYNC_NS
• MAX_VIRTUAL_DISPLAY_DIMENSION

HAL arabirimi oluşturma

Bir alt sistem için yapı yapılandırmalarına bir HAL arabirimi aracılığıyla erişilirken, yapılandırma değerleri vermek için arabirimler HAL paketi android.hardware.configstore (şu anda sürüm 1.0'da) içinde gruplandırılmıştır. Örneğin, hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal içinde yüzey surfaceflinger için bir HAL arabirim dosyası oluşturmak için:

package android.hardware.configstore@1.0;

interface ISurfaceFlingerConfigs {
    // TO-BE-FILLED-BELOW
};

.hal dosyasını oluşturduktan sonra, yeni .hal dosyasını Android.bp ve Android.mk dosyalarına eklemek için hardware/interfaces/update-makefiles.sh dosyasını çalıştırın.

Oluşturma bayrakları için işlevler ekleme

Her yapı bayrağı için arayüze yeni bir işlev ekleyin. Örneğin, hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal :

interface ISurfaceFlingerConfigs {
    disableTripleBuffering() generates(OptionalBool ret);
    forceHwcForVirtualDisplays() generates(OptionalBool ret);
    enum NumBuffers: uint8_t {
        USE_DEFAULT = 0,
        TWO = 2,
        THREE = 3,
    };
    numFramebufferSurfaceBuffers() generates(NumBuffers ret);
    runWithoutSyncFramework() generates(OptionalBool ret);
    vsyncEventPhaseOffsetNs generates (OptionalUInt64 ret);
    presentTimeOffsetFromSyncNs generates (OptionalUInt64 ret);
    maxVirtualDisplayDimension() generates(OptionalInt32 ret);
};

Bir fonksiyon eklerken:

• İsimlerle kısa olun. makefile değişken adlarını işlev adlarına dönüştürmekten kaçının ve TARGET_ ve BOARD_ öneklerinin artık gerekli olmadığını unutmayın.
• Yorum ekle. Geliştiricilerin yapılandırma öğesinin amacını, çerçeve davranışını nasıl değiştirdiğini, geçerli değerleri ve diğer ilgili bilgileri anlamasına yardımcı olun.

İşlev dönüş türleri, Optional[Bool|String|Int32|UInt32|Int64|UInt64] . Türler, aynı dizindeki types.hal içinde tanımlanır ve ilkel değerleri, değerin HAL tarafından belirtilip belirtilmediğini gösteren bir alanla sarar; değilse, varsayılan değer kullanılır.

struct OptionalString {
    bool specified;
    string value;
};

Uygun olduğunda, yapılandırma öğesinin türünü en iyi temsil eden numaralandırmayı tanımlayın ve bu numaralandırmayı dönüş türü olarak kullanın. Yukarıdaki örnekte, NumBuffers enum, geçerli değerlerin sayısını sınırlamak için tanımlanmıştır. Bu tür özel veri türlerini tanımlarken, değerin HAL tarafından belirtilip belirtilmediğini belirtmek için bir alan veya enum değeri (örneğin, USE_DEFAULT ) ekleyin.

HIDL'de tek bir yapı bayrağının tek bir işlev haline gelmesi zorunlu değildir. Modül sahipleri alternatif olarak yakından ilişkili yapı bayraklarını bir yapı içinde toplayabilir ve bu yapıyı döndüren bir işleve sahip olabilir (bunu yapmak işlev çağrılarının sayısını azaltabilir).

Örneğin, hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal iki yapı bayrağını tek bir yapıda toplama seçeneği:

 interface ISurfaceFlingerConfigs {
    // other functions here
    struct SyncConfigs {
        OptionalInt64 vsyncEventPhaseoffsetNs;
        OptionalInt64 presentTimeoffsetFromSyncNs;
    };
    getSyncConfigs() generates (SyncConfigs ret);
    // other functions here
};

Tek bir HAL işlevine alternatifler

Tüm yapı bayrakları için tek bir HAL işlevi kullanmaya alternatif olarak, HAL arabirimi getBoolean(string key) ve getInteger(string key) gibi basit işlevler de sağlar. Gerçek key=value çiftleri ayrı dosyalarda depolanır ve HAL hizmeti bu dosyaları okuyarak/ayrışarak değerler sağlar.

Bu yaklaşımın tanımlanması kolay olmakla birlikte, HIDL tarafından sağlanan faydaları (zorlanmış sürüm oluşturma, dokümantasyon kolaylığı, erişim kontrolü) içermez ve bu nedenle önerilmez.

Tek ve çoklu arayüzler

Yapılandırma öğeleri için HAL arabiriminin tasarımı iki seçenek sunar:

• Tüm konfigürasyon öğelerini kapsayan tek bir arayüz
• Her biri bir dizi ilgili yapılandırma öğesini kapsayan çoklu arayüzler

Tek bir arabirim daha kolaydır ancak tek dosyaya daha fazla yapılandırma öğesi eklendiğinden sürdürülemez hale gelebilir. Ayrıca, erişim denetimi ayrıntılı değildir, bu nedenle arabirime erişim izni verilen bir işlem tüm yapılandırma öğelerini okuyabilir (kısmi bir yapılandırma öğeleri kümesine erişim verilemez). Alternatif olarak, erişim verilmezse yapılandırma öğeleri okunamaz.

Bu sorunlar nedeniyle Android, bir grup ilgili yapılandırma öğesi için tek bir HAL arabirimiyle birden çok arabirim kullanır. Örneğin, yüzey surfaceflinger ile ilgili yapılandırma öğeleri için ISurfaceflingerConfigs ve Bluetooth ile ilgili yapılandırma öğeleri için IBluetoothConfigs .