Android 10'da ConfigStore HAL, yapılandırma değerlerini vendor
bölümünde depolamak için derleme bayraklarını kullanır ve system
bölümündeki bir hizmet bu değerlere HIDL kullanarak erişir (bu Android 9'da da geçerlidir). Ancak yüksek bellek tüketimi ve zor kullanım nedeniyle ConfigStore HAL kullanımdan kaldırıldı.
ConfigStore HAL, eski satıcı bölümlerini desteklemek için AOSP'de kalır. Android 10 veya üzerini çalıştıran cihazlarda, surfaceflinger
önce sistem özelliklerini okur; 'SurfaceFlingerProperties.sysprop' içindeki bir yapılandırma öğesi için hiçbir sistem özelliği tanımlanmamışsa, 'surfaceflinger' ConfigStore HAL'ye geri döner.
Android 8.0, monolitik Android işletim sistemini genel ( system.img
) ve donanıma özgü ( vendor.img
ve odm.img
) bölümlere ayırır. Bu değişiklik sonucunda sistem bölümüne kurulan modüllerden koşullu derlemenin kaldırılması ve bu modüllerin çalışma zamanında sistemin konfigürasyonunu belirlemesi (ve bu konfigürasyona bağlı olarak farklı davranması) gerekmektedir.
ConfigStore HAL, Android çerçevesini yapılandırmak için kullanılan salt okunur yapılandırma öğelerine erişim için bir dizi API sağlar. Bu sayfada ConfigStore HAL'in tasarımı (ve sistem özelliklerinin neden bu amaç için kullanılmadığı) açıklanmaktadır; Bu bölümdeki diğer sayfalarda HAL arayüzü , hizmet uygulaması ve istemci tarafı kullanımı ayrıntılarıyla anlatılmakta olup, bunların tamamında surfaceflinger
örnek olarak kullanılmaktadır. ConfigStore arayüz sınıflarıyla ilgili yardım için bkz. Arayüz Sınıfları ve Öğeleri Ekleme .
Neden sistem özelliklerini kullanmıyorsunuz?
Sistem özelliklerini kullanmayı düşündük ancak aşağıdakiler de dahil olmak üzere birkaç temel sorun bulduk:
- Değerlerde uzunluk sınırları. Sistem özelliklerinin, değerlerinin uzunluğu (92 bayt) konusunda sıkı sınırları vardır. Ayrıca bu sınırlar doğrudan Android uygulamalarına C makroları olarak sunulduğundan uzunluğun arttırılması geriye dönük uyumluluk sorunlarına neden olabilir.
- Tür desteği yok. Tüm değerler aslında dizelerdir ve API'ler dizeyi basitçe
int
veyabool
olarak ayrıştırır. Diğer bileşik veri türleri (örneğin dizi ve yapı) istemciler tarafından kodlanmalı/kodu çözülmelidir (örneğin,"aaa,bbb,ccc"
üç dizeden oluşan bir dizi olarak kodlanabilir). - Üzerine yazar. Salt okunur sistem özellikleri bir kez yazılabilir özellikler olarak uygulandığından, AOSP tanımlı salt okunur değerleri geçersiz kılmak isteyen satıcıların/ODM'lerin, AOSP tanımlı salt okunur değerlerden önce kendi salt okunur değerlerini içe aktarmaları gerekir. Bu da satıcı tarafından tanımlanan yeniden yazılabilir değerlerin AOSP tarafından tanımlanan değerler tarafından geçersiz kılınmasına neden olur.
- Alan gereksinimlerini karşılayın. Sistem özellikleri, her işlemde nispeten büyük miktarda adres alanı kaplar. Sistem özellikleri, sabit boyutta 128 KB olan
prop_area
birimlerinde gruplandırılır; bunların tümü, içindeki yalnızca tek bir sistem özelliğine erişiliyor olsa bile bir işlem adres alanına tahsis edilir. Bu, adres alanının değerli olduğu 32 bit cihazlarda sorunlara neden olabilir.
Uyumluluktan ödün vermeden bu sınırlamaların üstesinden gelmeye çalıştık, ancak sistem özelliklerinin salt okunur yapılandırma öğelerine erişimi destekleyecek şekilde tasarlanmadığından endişe duymaya devam ettik. Sonunda, sistem özelliklerinin, dinamik olarak güncellenen birkaç öğeyi gerçek zamanlı olarak Android'in tamamında paylaşmak için daha uygun olduğuna ve salt okunur yapılandırma öğelerine erişmeye adanmış yeni bir sisteme ihtiyaç duyulduğuna karar verdik.
ConfigStore HAL tasarımı
Temel tasarım basittir:
Şekil 1. ConfigStore HAL tasarımı
- HIDL'deki derleme bayraklarını (şu anda çerçeveyi koşullu olarak derlemek için kullanılmaktadır) açıklayın.
- Satıcılar ve OEM'ler, HAL hizmetini uygulayarak yapı bayrakları için SoC ve cihaza özgü değerler sağlar.
- Çalışma zamanında bir yapılandırma öğesinin değerini bulmak için HAL hizmetini kullanacak şekilde çerçeveyi değiştirin.
Şu anda çerçeve tarafından referans verilen yapılandırma öğeleri, sürümlendirilmiş bir HIDL paketine ( android.hardware.configstore@1.0
) dahil edilmiştir. Satıcılar/OEM'ler, bu paketteki arayüzleri uygulayarak konfigürasyon öğelerine değerler sağlar ve çerçeve, bir konfigürasyon öğesi için değer alması gerektiğinde arayüzleri kullanır.
Güvenlik Hususları
Aynı arayüzde tanımlanan derleme bayrakları aynı SELinux politikasından etkilenir. Bir veya daha fazla yapı bayrağının farklı SELinux politikalarına sahip olması gerekiyorsa, bunların başka bir arayüze ayrılması gerekir . Ayrılan arayüzler artık geriye dönük olarak uyumlu olmadığından bu, android.hardware.configstore package
büyük ölçüde revizyonunu gerektirebilir.