Android 10'da ConfigStore HAL,
vendor bölümünde yapılandırma değerlerini depolamak için derleme bayrakları 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ılmıştır.
ConfigStore HAL, eski satıcı bölümlerini desteklemek için AOSP'de kalır. Android 10 veya sonraki sürümleri ç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ımlanmadıysa, "surfaceflinger", ConfigStore HAL'a 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şikliğin bir sonucu olarak, sistem bölümüne kurulan modüllerden koşullu derlemenin kaldırılması ve bu tür modüllerin sistemin çalışma zamanındaki yapılandırmasını belirlemesi (ve bu yapılandırmaya bağlı olarak farklı davranması) gerekir.
ConfigStore HAL, Android çerçevesini yapılandırmak için kullanılan salt okunur yapılandırma öğelerine erişmek için bir dizi API sağlar. Bu sayfa, ConfigStore HAL'ın tasarımını (ve sistem özelliklerinin neden bu amaç için kullanılmadığını) açıklamaktadır; bu bölümdeki diğer sayfalar, tümü
surfaceflinger örnek olarak kullanan HAL arabirimi , hizmet uygulaması ve istemci tarafı kullanımı hakkında ayrıntılı bilgi verir. ConfigStore arabirim sınıflarıyla ilgili yardım için bkz. Arabirim 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 özellikleri, değerlerinin uzunluğu (92 bayt) konusunda sıkı sınırlara sahiptir. Ayrıca, bu sınırlar doğrudan Android uygulamalarına C makroları olarak maruz kaldığından, uzunluğu artırmak geriye dönük uyumluluk sorunlarına neden olabilir.
- Tip desteği yok. Tüm değerler aslında dizelerdir ve API'ler dizeyi basitçe
intveya
boololarak ayrıştırır. Diğer bileşik veri türleri (örneğin, dizi ve yapı) istemciler tarafından kodlanmalıdır/kodları çözülmelidir (örneğin,
"aaa,bbb,ccc", üç dizelik bir dizi olarak kodlanabilir).
- Üzerine yazar. Salt okunur sistem özellikleri bir kez yazılır özellikler olarak uygulandığından, AOSP tanımlı salt okunur değerleri geçersiz kılmak isteyen satıcılar/ODM'ler, AOSP tanımlı salt okunur değerlerden önce kendi salt okunur değerlerini içe aktarmalıdır. 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.
- Adres alanı gereksinimleri. Sistem özellikleri, her işlemde nispeten büyük miktarda adres alanı alır. Sistem özellikleri, sabit bir 128 KB boyutunda
prop_areabirimlerinde gruplandırılır ve bunların tümü, içinde yalnızca tek bir sistem özelliğine erişilse bile bir süreç adres alanına atanır. 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 desteklemek için tasarlanmadığı konusunda endişelenmeye devam ettik. Sonunda, sistem özelliklerinin dinamik olarak güncellenen birkaç öğeyi gerçek zamanlı olarak tüm Android'de paylaşmak için daha uygun olduğuna ve salt okunur yapılandırma öğelerine erişmeye adanmış yeni bir sisteme ihtiyaç olduğuna karar verdik.
ConfigStore HAL tasarımı
Temel tasarım basittir:
Şekil 1. ConfigStore HAL tasarımı
- HIDL'de derleme bayraklarını (şu anda çerçeveyi koşullu olarak derlemek için kullanılıyor) tanımlayın.
- Satıcılar ve OEM'ler, HAL hizmetini uygulayarak derleme bayrakları için SoC ve cihaza özel değerler sağlar.
- Çalışma zamanında bir yapılandırma öğesinin değerini bulmak için HAL hizmetini kullanmak için çerçeveyi değiştirin.
Şu anda çerçeve tarafından başvurulan yapılandırma öğeleri, sürümlü bir HIDL paketine dahil edilmiştir (
firstname.lastname@example.org ). Satıcılar/OEM'ler, bu paketteki arabirimleri uygulayarak yapılandırma öğelerine değerler sağlar ve çerçeve, bir yapılandırma öğesi için bir değer alması gerektiğinde arabirimleri kullanır.
Güvenlik Hususları
Aynı arabirimde tanımlanan yapı bayrakları, aynı SELinux ilkesinden etkilenir. Bir veya daha fazla yapı bayrağının farklı SELinux ilkelerine sahip olması gerekiyorsa, bunların başka bir arabirime ayrılması gerekir . Ayrılmış arayüzler artık geriye dönük uyumlu olmadığından bu,
android.hardware.configstore package büyük bir revizyonunu gerektirebilir.