ConfigStore HAL 提供了一组 API，可供访问用于配置 Android 框架的只读配置项。本页面介绍了 ConfigStore HAL 的设计（以及不使用系统属性访问只读配置项的原因）；本部分的其他页面详细介绍了 HAL 接口、服务实现和客户端使用情况，所有这些均以 surfaceflinger 为例。如需获得 ConfigStore 接口类的相关帮助，请参阅添加接口类和项。
为什么不使用系统属性？
我们考虑过使用系统属性，但发现了以下几个重大问题，其中包括：
值的长度受限。系统属性对其值的长度具有严格限制（92 个字节）。此外，由于这些限制已作为 C 宏直接提供给 Android 应用，因此增加长度会导致向后兼容性问题。
无类型支持。所有值本质上都是字符串，而 API 仅仅是将字符串解析为 int 或 bool。其他复合数据类型（如数组和结构体）应由客户端进行编码/解码（例如，"aaa,bbb,ccc" 可以编码为由三个字符串组成的数组）。
[null,null,["最后更新时间 (UTC)：2025-03-05。"],[],[],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)."]]
