Ç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_
veBOARD_
ö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
.