2026'dan itibaren, ana kararlı geliştirme modelimizle uyumlu olmak ve ekosistem için platform kararlılığını sağlamak amacıyla kaynak kodunu 2. ve 4. çeyreklerde AOSP'de yayınlayacağız. AOSP'yi oluşturmak ve AOSP'ye katkıda bulunmak için android-latest-release kullanın. android-latest-release manifest dalı her zaman AOSP'ye gönderilen en son sürümü referans alır. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

ConfigStore HAL

Android 10'da ConfigStore HAL, yapılandırma değerlerini vendor bölümünde depolamak için derleme işaretlerini kullanır ve system bölümündeki bir hizmet, bu değerlere HIDL kullanarak erişir (bu durum Android 9'da da geçerlidir). Ancak yüksek bellek tüketimi ve zor kullanımı nedeniyle ConfigStore HAL desteği sonlandırıldı.

ConfigStore HAL, eski tedarikçi bölümlerini desteklemek için AOSP'de kalır. Android 10 veya sonraki sürümlerin yüklü olduğu cihazlarda surfaceflinger önce sistem özellikleri okunur. `SurfaceFlingerProperties.sysprop` içinde bir yapılandırma öğesi için sistem özelliği tanımlanmamışsa `surfaceflinger`, ConfigStore HAL'e geri döner.

Android 8.0, tek parçalı Android OS'yi genel (system.img) ve donanıma özel (vendor.img ve odm.img) bölümlere ayırır. Bu değişiklik sonucunda, sistem bölümüne yüklenen modüllerden koşullu derleme kaldırılmalı ve bu tür modüller, sistemin yapılandırmasını çalışma zamanında belirlemelidir (ve bu yapılandırmaya bağlı olarak farklı şekilde davranmalıdır).

ConfigStore HAL, Android çerçevesini yapılandırmak için kullanılan salt okunur yapılandırma öğelerine erişmek üzere bir dizi API sağlar. Bu sayfada ConfigStore HAL'ın tasarımı (ve bu amaçla neden sistem özelliklerinin kullanılmadığı) açıklanmaktadır. Bu bölümdeki diğer sayfalarda ise surfaceflinger örneği kullanılarak HAL arayüzü, hizmet uygulaması ve istemci tarafı kullanımı ayrıntılı olarak açıklanmaktadır. ConfigStore arayüz sınıflarıyla ilgili yardım için Arayüz Sınıfları ve Öğeleri Ekleme başlıklı makaleyi inceleyin.

Neden sistem özelliklerini kullanmıyorsunuz?

Sistem özelliklerini kullanmayı düşündük ancak aşağıdakiler de dahil olmak üzere çeşitli temel sorunlar tespit ettik:

Değerlerdeki uzunluk sınırları. Sistem özelliklerinin değer uzunluğuyla ilgili katı sınırlar (92 bayt) vardır. Ayrıca, bu sınırlar C makroları olarak doğrudan Android uygulamalarına sunulduğundan uzunluğun artırılması geriye dönük uyumluluk sorunlarına neden olabilir.
Yazma desteği yok. Tüm değerler aslında dizelerdir ve API'ler dizeyi yalnızca int veya bool olarak ayrıştırır. Diğer bileşik veri türleri (örneğin, dizi ve yapı) istemciler tarafından kodlanmalı/kod çözülmelidir (örneğin, "aaa,bbb,ccc" üç dizeden oluşan bir dizi olarak kodlanabilir).
Üzerine yazma. Salt okunur sistem özellikleri bir kez yazılan özellikler olarak uygulandığından, AOSP tarafından tanımlanan salt okunur değerleri geçersiz kılmak isteyen tedarikçiler/ODM'ler, AOSP tarafından tanımlanan salt okunur değerlerden önce kendi salt okunur değerlerini içe aktarmalıdır. Bu durum da satıcı tarafından tanımlanan yeniden yazılabilir değerlerin AOSP tarafından tanımlanan değerlerle geçersiz kılınmasına neden olur.
Alanla ilgili koşulları karşılayın. Sistem özellikleri, her işlemde nispeten büyük miktarda adres alanı kullanır. Sistem özellikleri, 128 KB'lık sabit boyuta sahip prop_area birimler halinde gruplandırılır. Bu birimlerdeki yalnızca tek bir sistem özelliğine erişiliyor olsa bile birimlerin tamamı bir işlem adres alanına ayrılır. Bu durum, 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ığı konusunda endişelenmeye devam ettik. Sonunda, sistem özelliklerinin birkaç dinamik olarak güncellenen öğenin Android'in tamamında gerçek zamanlı olarak paylaşılması için daha uygun olduğuna ve salt okunur yapılandırma öğelerine erişmeye yönelik yeni bir sisteme ihtiyaç duyulduğuna karar verdik.

ConfigStore HAL tasarımı

Temel tasarım basittir:

Configstore HAL tasarımı

Şekil 1. ConfigStore HAL tasarımı

HIDL'de derleme işaretlerini (şu anda çerçeveyi koşullu olarak derlemek için kullanılır) açıklayın.
Tedarikçiler ve OEM'ler, HAL hizmetini uygulayarak derleme işaretleri için SoC ve cihaza özel değerler sağlar.
Çalışma zamanında bir yapılandırma öğesinin değerini bulmak için çerçeveyi HAL hizmetini kullanacak şekilde değiştirin.

Çerçeve tarafından şu anda referans verilen yapılandırma öğeleri, sürüm oluşturulmuş bir HIDL paketine (android.hardware.configstore@1.0) dahil edilir. Tedarikçiler/OEM'ler, bu paketteki arayüzleri uygulayarak yapılandırma öğelerine değerler sağlar ve çerçeve, bir yapılandırma öğesi için değer alması gerektiğinde arayüzleri kullanır.

Güvenlikle ilgili olarak göz önünde bulundurulması gerekenler

Aynı arayüzde tanımlanan derleme işaretleri aynı SELinux politikasından etkilenir. Bir veya daha fazla derleme işaretinin farklı SELinux politikaları olması gerekiyorsa bunlar başka bir arayüze ayrılmalıdır. Ayrılmış arayüzler artık geriye dönük uyumlu olmadığından android.hardware.configstore package'da büyük bir revizyon yapılması gerekebilir.