HAL Yapılandırması

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 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'in tasarımını (ve sistem özelliklerinin neden bu amaç için kullanılmadığını) açıklamaktadır; Bu bölümdeki diğer sayfalar HAL arabirimi , hizmet uygulaması ve istemci tarafı kullanımı hakkında ayrıntılı bilgi verir ve tümü surfaceflinger örnek olarak kullanır. 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. Ek olarak, 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 bir int veya bool olarak 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, 128 KB'lik sabit bir boyuta sahip prop_area birimlerinde 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:

HAL tasarımını yapılandırma

Ş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 ( android.hardware.configstore@1.0 ). 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.