Android 10에서 ConfigStore HAL은 빌드 플래그를 사용하여 vendor 파티션에 구성 값을 저장하며 system 파티션의 서비스는 HIDL을 사용하여 이러한 값에 액세스합니다(이는 Android 9에도 적용됨). 그러나 높은 메모리 소비와 어려운 사용법으로 인해 ConfigStore HAL은 지원 중단되었습니다.
ConfigStore HAL은 기존 공급업체 파티션을 지원할 수 있도록 AOSP에 남아 있습니다. Android 10 이상을 실행하는 기기에서는 surfaceflinger가 먼저 시스템 속성을 읽습니다. `SurfaceFlingerProperties.sysprop`에서 구성 항목에 정의된 시스템 속성이 없으면 `surfaceflinger`는 ConfigStore HAL로 대체됩니다.
Android 8.0은 모놀리식 Android OS를 일반(system.img) 및 하드웨어 전용(vendor.img 및 odm.img) 파티션으로 분할합니다. 이러한 변화에 따른 결과로, 조건부 컴파일이 시스템 파티션에 설치된 모듈에서 삭제되어야 하며, 이러한 모듈은 런타임 시의 시스템 구성을 파악해야 합니다(또한 구성에 따라 다르게 작동함).
ConfigStore HAL은 Android 프레임워크를 구성하는 데 사용되는 읽기 전용 구성 항목에 액세스하기 위한 API 모음을 제공합니다. 이 페이지에서는 ConfigStore HAL 디자인(및 시스템 속성이 이 용도로 사용되지 않은 이유)에 관해 설명합니다. 같은 섹션의 다른 페이지에서는 HAL 인터페이스, 서비스 구현 및 클라이언트 측 사용량을 자세히 설명하며, 모두 surfaceflinger를 예로 사용합니다. ConfigStore 인터페이스 클래스에 관한 도움말은 인터페이스 클래스 및 항목 추가를 참조하세요.
시스템 속성을 사용하지 않는 이유는 무엇인가요?
Google에서는 시스템 속성 사용을 고려했지만 다음과 같은 여러 기본적인 문제를 발견했습니다.
값의 길이 제한. 시스템 속성에는 값의 길이에 관한 엄격한 제한이 있습니다(92바이트). 또한 이러한 제한이 Android 앱에 C 매크로로 직접적으로 노출되므로 길이가 늘어날 경우 역호환성 문제가 발생할 수 있습니다.
유형 지원 없음. 모든 값은 기본적으로 문자열이며 API는 문자열을 int 또는 bool로 파싱할 수 없습니다.
다른 복합 데이터 유형(배열 및 구조 등)은 클라이언트에 의해 인코딩/디코딩되어야 합니다(예를 들어 "aaa,bbb,ccc"는 문자열 3개의 배열로 코딩할 수 있음).
덮어쓰기. 읽기 전용 시스템 속성은 write-once 속성으로 구현됩니다. 따라서 AOSP에서 정의한 읽기 전용 값을 재정의하고 싶은 공급업체/ODM은 AOSP에서 정의한 읽기 전용 값에 앞서 자체적인 읽기-전용 값을 가져와야 합니다. 이 경우에는 공급업체에서 정의한 재작성 가능한 값이 AOSP에서 정의한 값에 의해 재정의되는 결과로 이어집니다.
주소 공간 요구사항. 시스템 속성은 프로세스별로 상당한 크기의 주소 공간을 차지합니다. 시스템 속성은 128KB의 고정 크기로 지정된 prop_area 단위로 그룹화되며, 이러한 모든 단위는 그 안의 단일 시스템 속성만 액세스되고 있는 경우에도 프로세스 주소 공간에 할당됩니다. 이는 주소 공간이 부족한 32비트 기기에 문제를 야기할 수 있습니다.
Google은 호환성의 손실없이 이러한 한계를 극복해보려 했지만 시스템 속성이 읽기 전용 구성 항목의 액세스를 지원하기 위한 용도로 설계되지 않았다는 점을 계속해서 우려했습니다. 결국에는 시스템 속성이 Android 전체에 걸쳐 동적으로 업데이트된 몇 개의 항목을 공유하는 데 훨씩 적합하며, 읽기 전용 구성 항목의 액세스를 전담하는 새로운 시스템이 필요하다는 결론에 이르렀습니다.
ConfigStore HAL 디자인
기본 디자인은 간단합니다.
그림 1. ConfigStore HAL 디자인
HIDL의 빌드 플래그를 설명합니다(현재 프레임워크를 조건부로 컴파일링하기 위한 용도로 사용되고 있음).
공급업체 및 OEM에서 HAL 서비스를 구현하여 빌드 플래그의 SoC 및 기기 전용 값을 제공합니다.
프레임워크를 수정하고 HAL 서비스를 사용하여 런타임 시의 구성 항목 값을 찾습니다.
현재 프레임워크에 의해 참조되고 있는 구성 항목은 버전 관리형 HIDL 패키지에 포함됩니다(android.hardware.configstore@1.0). 공급업체/OEM은 이 패키지에 인터페이스를 구현하여 구성 항목에 값을 제공하며, 프레임워크는 구성 항목의 값을 가져와야 할 때 인터페이스를 사용합니다.
보안 고려사항
같은 인터페이스에서 정의된 빌드 플래그는 동일한 SELinux 정책의 영향을 받습니다. 1개 이상의 빌드 플래그에 다른 SELinux 정책이 포함된 경우 빌드 플래그를 다른 인터페이스로 분리해야 합니다. 이 경우 분리된 인터페이스가 더 이상 이전 버전과 호환되지 않을 수 있으므로 android.hardware.configstore package의 주 버전이 필요합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[null,null,["최종 업데이트: 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)."]]
