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'yi 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 avantajları içerir:

  • Sürümlendirilmiş (yeni yapılandırma öğeleri eklemek için satıcıların/OEM'lerin HAL'yi açıkça genişletmesi gerekir)
  • İyi belgelenmiş
  • SELinux kullanarak erişim kontrolü
  • Satıcı Test Paketi aracılığıyla yapılandırma öğelerinin sağlamlık kontrolü (aralık kontrolü, öğeler arasında karşılıklı bağımlılık kontrolü vb.)
  • Hem C++ hem de Java'da otomatik olarak 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 daha küçük hale getirmek için eski yapılandırmaları bırakın. Örneğin, surfaceflinger için aşağıdaki derleme bayrakları 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 arayüzü oluşturma

Bir alt sistemin yapı yapılandırmalarına HAL arabirimi aracılığıyla erişilirken, yapılandırma değerlerinin verilmesine yönelik arabirimler HAL paketi android.hardware.configstore (şu anda sürüm 1.0'da) gruplandırılmıştır. Örneğin, hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal dosyasında surfaceflinger için bir HAL arayüz 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 çalıştırın.

Derleme bayrakları için işlevler ekleme

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

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 işlev eklerken:

  • İsimler konusunda 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ı, geçerli değerleri ve diğer ilgili bilgileri nasıl değiştirdiğini anlamalarına yardımcı olun.

İşlev dönüş türleri Optional[Bool|String|Int32|UInt32|Int64|UInt64] olabilir. Türler aynı dizindeki types.hal dosyasında tanımlanır ve temel 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, konfigürasyon öğ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 numaralandırması geçerli değerlerin sayısını sınırlandıracak şekilde 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 bir numaralandırma 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 dosyasında iki yapı bayrağını tek bir yapıda toplamak için bir seçenek şöyledir:

 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 ayrıca getBoolean(string key) ve getInteger(string key) gibi basit işlevler de sağlar. Gerçek key=value çiftleri ayrı dosyalarda saklanır ve HAL hizmeti bu dosyaları okuyarak/ayrıştırarak değerler sağlar.

Bu yaklaşımın tanımlanması kolay olsa da, HIDL'nin sağladığı faydaları (zorunlu 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 arayüzünün tasarımı iki seçenek sunar:

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

Tek bir arayüz daha kolaydır ancak tek dosyaya daha fazla konfigürasyon öğesi eklendikçe sürdürülemez hale gelebilir. Ayrıca, erişim kontrolü ayrıntılı değildir, dolayısıyla arayüze erişim izni verilen bir süreç tüm yapılandırma öğelerini okuyabilir (kısmi bir yapılandırma öğeleri kümesine erişim izni verilemez). Alternatif olarak, erişim izni verilmezse yapılandırma öğeleri okunamaz.

Bu sorunlardan dolayı Android, bir grup ilgili yapılandırma öğesi için tek bir HAL arayüzüne sahip birden fazla arayüz kullanır. Örneğin, surfaceflinger ile ilgili yapılandırma öğeleri için ISurfaceflingerConfigs ve Bluetooth ile ilgili yapılandırma öğeleri için IBluetoothConfigs .