27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
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, HIDL'yi kullanarak bu değerlere erişir (bu durum Android 9 için de geçerlidir). Ancak yüksek bellek tüketimi ve zor kullanım nedeniyle ConfigStore HAL'in desteği sonlandırıldı.
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ç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ça Android OS'i genel (system.img) ve donanıma özel (vendor.img ve odm.img) bölümlere ayırır. Bu değişiklik sonucunda, koşullu derleme sistem bölümüne yüklenen modüllerden kaldırılmalı ve bu modüller çalışma zamanında sistemin yapılandırmasını belirlemelidir (ve bu yapılandırmaya bağlı olarak farklı 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'in tasarımı (ve bu amaç için sistem özelliklerinin neden kullanılmadığı) açıklanmaktadır. Bu bölümdeki diğer sayfalarda ise HAL arayüzü, hizmet uygulaması ve istemci tarafı kullanımı ayrıntılı olarak açıklanmaktadır. Bu açıklamalarda surfaceflinger her zaman örnek olarak kullanılmaktadı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.
Sistem özelliklerini neden kullanmalısınız?
Sistem özelliklerini kullanmayı düşündük ancak aşağıdakiler dahil olmak üzere birkaç temel sorun tespit ettik:
Değerlerin uzunluğuyla ilgili sınırlamalar Sistem özelliklerinin değerlerinin uzunluğuyla ilgili sıkı sınırlamalar vardır (92 bayt). Ayrıca bu sınırlar, Android uygulamalarına doğrudan C makrosu olarak sunulduğundan uzunluğun artırılması geriye dönük uyumluluk sorunlarına neden olabilir.
Tür desteği yok. Tüm değerler temelde dizedir ve API'ler yalnızca dizeyi bir int veya bool olarak ayrıştırır.
Diğer bileşik veri türleri (ör. dizi ve yapı) istemciler tarafından kodlanmalı/kodları çözülmelidir (ör. "aaa,bbb,ccc" üç dizenin dizisi olarak kodlanabilir).
Üzerine yazma. Salt okunur sistem özellikleri bir kez yazılabilir özellikler olarak uygulandığından, AOSP tarafından tanımlanan salt okunur değerleri geçersiz kılmak isteyen tedarikçilerin/ODM'lerin AOSP tarafından tanımlanan salt okunur değerlerden önce kendi salt okunur değerlerini içe aktarması gerekir. Bu da tedarikçi firma tarafından tanımlanan yeniden yazılabilir değerlerin AOSP tarafından tanımlanan değerlerle geçersiz kılınmasına neden olur.
Alan adı koşulları Sistem özellikleri, her işlemde nispeten büyük miktarda adres alanı kaplar. Sistem özellikleri, sabit boyutu 128 KB olan prop_area birimleri halinde gruplandırılır. Bu birimlerin tümü, içinde yalnızca tek bir sistem özelliğine erişiliyor olsa bile bir işlem adres alanına ayrılır. Bu durum, adres alanının değerli olduğu 32 bitlik cihazlarda sorunlara yol açabilir.
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, dinamik olarak güncellenen birkaç öğeyi Android'in tamamında gerçek zamanlı olarak paylaşmak için sistem özelliklerinin daha uygun olduğuna ve salt okunur yapılandırma öğelerine erişmeye özel 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 işaretlerini (şu anda çerçeveyi koşullu olarak derlemek için kullanılır) tanımlayın.
Tedarikçiler ve OEM'ler, HAL hizmetini uygulayarak derleme işaretleri 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üm numaralı bir HIDL paketine (android.hardware.configstore@1.0) dahil edilir. Tedarikçi firmalar/OEM'ler bu pakette arayüzleri uygulayarak yapılandırma öğelerine değer sağlar ve çerçeve, bir yapılandırma öğesi için değer aldığında bu 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ı arayüzler artık geriye dönük uyumlu olmadığından bu işlem için android.hardware.configstore package'te büyük bir düzeltme gerekebilir.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 2025-07-27 UTC."],[],[],null,["# ConfigStore HAL\n\nIn Android 10, ConfigStore HAL uses build flags to store\nconfig values in the `vendor` partition, and a service in the `system`\npartition accesses those values using HIDL (this is also true in Android 9). However, due to high\nmemory consumption and difficult usage, the ConfigStore HAL has been deprecated.\n\n\nThe ConfigStore HAL remains in AOSP to support legacy vendor partitions. On\ndevices running Android 10 or later, `surfaceflinger`\nreads system properties first; if no system property is defined for a config\nitem in \\`SurfaceFlingerProperties.sysprop\\`, \\`surfaceflinger\\` falls back to the\nConfigStore HAL.\n| **Warning:** Android 10 deprecates the ConfigStore HAL and replaces the HAL with system properties. For details, refer to [Configuring](/docs/core/architecture/configuration).\n\nAndroid 8.0 splits the monolithic Android OS into generic\n(`system.img`) and hardware-specific (`vendor.img` and\n`odm.img`) partitions. As a result of this\nchange, conditional compilation must be removed from modules installed to the\nsystem partition and such modules must determine the configuration of the\nsystem at runtime (and behave differently depending on that configuration).\n\nThe ConfigStore HAL provides a set of APIs for accessing read-only\nconfiguration items used to configure the Android framework. This page describes\nthe design of ConfigStore HAL (and why system properties weren't used for this\npurpose); other pages in this section detail the\n[HAL interface](/docs/core/architecture/configstore/interface),\n[service\nimplementation](/docs/core/architecture/configstore/service), and\n[client-side usage](/docs/core/architecture/configstore/client),\nall using `surfaceflinger` as an example. For help with ConfigStore\ninterface classes, see\n[Adding Interface\nClasses and Items](/docs/core/architecture/configstore/add-class-item).\n\nWhy not use system properties?\n------------------------------\n\nWe considered using system properties but found several fundamental issues,\nincluding:\n\n- **Length limits on values.** System properties have tight limits on the length of their values (92 bytes). In addition, as these limits have been directly exposed to Android apps as C macros, increasing the length can cause backward-compatibility issues.\n- **No type support.** All values are essentially strings, and APIs simply parse the string into an `int` or `bool`. Other compound data types (for example, array and struct) should be encoded/decoded by the clients (for example, `\"aaa,bbb,ccc\"` can be coded as an array of three strings).\n- **Overwrites.** Because read-only system properties are implemented as write-once properties, vendors/ODMs that want to override AOSP-defined read-only values must import their own read-only values prior to AOSP-defined read-only values. This, in turn, results in vendor-defined rewritable values being overridden by AOSP-defined values.\n- **Address space requirements.** System properties take a relatively large amount of address space in each process. System properties are grouped in `prop_area` units with a fixed size of 128 KB, all of which is allocated to a process address space even if only a single system property in it is being accessed. This can cause problems on 32-bit devices where address space is precious.\n\nWe attempted to overcome these limitations without sacrificing compatibility,\nbut continued to be concerned that system properties weren't designed to\nsupport accessing read-only configuration items. Eventually we decided that\nsystem properties are better suited for sharing a few dynamically updated items\nacross all of Android in real time, and that a need existed for a new system\ndedicated to accessing read-only configuration items.\n\nConfigStore HAL design\n----------------------\n\nThe basic design is simple:\n\n**Figure 1.** ConfigStore HAL design\n\n- Describe build flags (currently used for conditionally compiling the framework) in HIDL.\n- Vendors and OEMs provide SoC and device-specific values for build flags by implementing the HAL service.\n- Modify the framework to use the HAL service to find the value of a configuration item at runtime.\n\nConfiguration items currently referenced by the framework are included in a\nversioned HIDL package (`android.hardware.configstore@1.0`).\nVendors/OEMs provide values to the configuration items by implementing\ninterfaces in this package, and the framework uses the interfaces when it needs\nto get a value for a configuration item.\n\nSecurity considerations\n-----------------------\n\nBuild flags defined in the same interface are affected by same SELinux\npolicy. If one or more build flags should have different SELinux policies,\n**they must be separated to another interface** . This can require\nmajor revision of `android.hardware.configstore package` as the\nseparated interfaces are no longer backward-compatible.\n| **Note:** For details on SELinux, see [SELinux Overview](/docs/security/features/selinux)."]]
