시스템 속성 추가

이 페이지에서는 기존 시스템 속성을 리팩토링하기 위한 지침과 함께 Android에서 시스템 속성을 추가하거나 정의하는 표준 방법을 제공합니다. 달리 지시하는 강력한 호환성 문제가 없는 한 리팩토링할 때 지침을 사용해야 합니다.

1단계: 시스템 속성 정의

시스템 속성을 추가할 때 속성의 이름을 결정하고 SELinux 속성 컨텍스트와 연결합니다. 적절한 기존 컨텍스트가 없으면 새 컨텍스트를 만듭니다. 이름은 속성에 액세스할 때 사용됩니다. 속성 컨텍스트는 SELinux 측면에서 액세스 가능성을 제어하는 ​​데 사용됩니다. 이름은 임의의 문자열이 될 수 있지만 AOSP는 구조화된 형식을 사용하여 명확하게 할 것을 권장합니다.

속성 이름

snake_case 대/소문자와 함께 다음 형식을 사용하십시오.

[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]

요소 prefix 에 ""(생략), ro (속성이 한 번만 설정된 경우) 또는 persist (재부팅 후에도 지속되는 속성의 경우)을 사용합니다.

주의 사항

미래에 쓰기 가능하도록 prefix 가 필요하지 않다고 확신하는 경우에만 ro 를 사용하십시오. ** ro 접두사를 지정하지 마십시오.** 대신 sepolicy에 의존하여 prefix 를 읽기 전용으로 만듭니다(즉, init 에서만 쓰기 가능).

값이 재부팅 후에도 지속되어야 하고 시스템 속성을 사용하는 것이 유일한 옵션이라고 확신하는 경우에만 persist 을 사용하십시오. (자세한 내용은 준비 섹션을 참조하십시오.)

Google은 ro 또는 persist 속성이 있는 시스템 속성을 엄격하게 검토합니다.

group 이라는 용어는 관련 속성을 집계하는 데 사용됩니다. audio 또는 telephony 와 유사한 하위 시스템 이름을 사용하기 위한 것입니다. sys , system , dev , default 또는 config 와 같은 모호하거나 오버로드된 용어 를 사용하지 마십시오 .

시스템 속성에 대해 독점적인 읽기 또는 쓰기 액세스 권한이 있는 프로세스의 도메인 유형 이름을 사용하는 것이 일반적입니다. 예를 들어, vold 프로세스가 쓰기 권한이 있는 시스템 속성의 경우 그룹 이름으로 vold (프로세스의 도메인 유형 이름)를 사용하는 것이 일반적입니다.

필요한 경우 subgroup 을 추가하여 속성을 추가로 분류하되 이 요소를 설명하기 위해 모호하거나 과부하된 용어를 사용하지 마십시오. (또한 두 개 이상의 subgroup 을 가질 수 있습니다.)

많은 그룹 이름이 이미 정의되었습니다. system/sepolicy/private/property_contexts 파일을 확인하고 가능한 경우 새 그룹 이름을 만드는 대신 기존 그룹 이름을 사용합니다. 다음 표에는 자주 사용하는 그룹 이름의 예가 나와 있습니다.

도메인 그룹(및 하위 그룹)
블루투스 관련 bluetooth
커널 cmdline의 sysprops boot
빌드를 식별하는 sysprops build
전화 관련 telephony
오디오 관련 audio
그래픽 관련 graphics
볼드 관련 vold

다음은 이전 정규식 예제 에서 name 과 type 의 사용을 정의합니다.

[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]

  • name 은 그룹 내의 시스템 속성을 식별합니다.

  • type 은 시스템 속성의 유형 또는 의도를 명확히 하는 선택적 요소입니다. 예를 들어 sysprop의 이름을 audio.awesome_feature_enabled 또는 audio.awesome_feature.enabled 로 지정하는 대신 audio.awesome_feature 로 이름을 변경하여 시스템 속성 유형 및 의도를 반영합니다.

유형이 무엇이어야 하는지에 대한 특정 규칙은 없습니다. 다음은 사용 권장 사항입니다.

  • enabled 됨 : 유형이 기능을 켜거나 끄는 데 사용되는 부울 시스템 속성인 경우 사용합니다.
  • config : 시스템 속성이 시스템의 동적 상태를 나타내지 않는다는 것을 명확히 하려는 경우 사용합니다. 미리 구성된 값(예: 읽기 전용)을 나타냅니다.
  • List : 값이 목록인 시스템 속성인 경우 사용합니다.
  • Timeoutmillis : ms 단위의 시간 초과 값에 대한 시스템 속성인 경우 사용합니다.

예:

  • persist.radio.multisim.config
  • drm.service.enabled

속성 컨텍스트

새로운 SELinux 속성 컨텍스트 체계를 사용하면 더 세밀하고 설명적인 이름을 사용할 수 있습니다. 속성 이름에 사용되는 것과 유사하게 AOSP는 다음 형식을 권장합니다.

{group}[_{subgroup}]*_prop

용어는 다음과 같이 정의됩니다.

group 및 subgroup 은 이전 샘플 regex 에 대해 정의된 것과 동일한 의미를 갖습니다. 예를 들어, vold_config_prop 은 공급업체의 구성이고 vendor_init 에 의해 설정되는 속성을 나타내는 반면 vold_status_prop 또는 vold_prop 은 현재 vold 상태를 노출하는 속성을 나타냅니다.

속성 컨텍스트의 이름을 지정할 때 속성의 일반적인 사용법을 반영하는 이름을 선택합니다. 특히 다음 유형의 용어는 사용하지 마십시오.

  • sys , system , default 와 같이 너무 일반적이고 모호해 보이는 용어.
  • exported , apponly , ro , public , private 와 같이 접근성을 직접 인코딩하는 용어.

exported_vold_prop 또는 vold_vendor_writable_prop 등보다 vold_config_prop 과 같은 이름 사용을 선호합니다.

유형

속성 유형은 표에 나열된 대로 다음 중 하나일 수 있습니다.

유형 정의
부울 true 또는 참이면 1 , 거짓이면 false 또는 0
정수 부호 있는 64비트 정수
부호 없는 정수 부호 없는 64비트 정수
더블 배정밀도 부동 소수점
끈 유효한 UTF-8 문자열
열거 값은 공백이 없는 유효한 UTF-8 문자열일 수 있습니다.
위의 목록 쉼표( , )는 구분 기호로 사용됩니다.
정수 목록 [1, 2, 3] 은 1,2,3 으로 저장됩니다.

내부적으로 모든 속성은 문자열로 저장됩니다. property_contexts 파일로 지정하여 유형을 적용할 수 있습니다. 자세한 내용은 3단계 의 property_contexts 를 참조하십시오.

2단계: 필요한 접근성 수준 결정

속성을 정의하는 4개의 도우미 매크로가 있습니다.

접근성 유형 의미
system_internal_prop /system 에서만 사용되는 속성
system_restricted_prop /system 외부에서 읽지만 쓰지 않는 속성
system_vendor_config_prop /system 외부에서 읽고 vendor_init 에서만 쓰는 속성
system_public_prop /system 외부에서 읽고 쓰는 속성

가능한 한 좁게 시스템 속성에 대한 액세스 범위를 지정합니다. 과거에는 광범위한 액세스로 인해 앱이 손상되고 보안 취약점이 발생했습니다. 범위를 지정할 때 다음 질문을 고려하십시오.

  • 이 시스템 속성을 유지해야 합니까? (만일 그렇다면 왜?)
  • 이 속성에 대한 읽기 액세스 권한이 있어야 하는 프로세스는 무엇입니까?
  • 이 속성에 대한 쓰기 액세스 권한이 있어야 하는 프로세스는 무엇입니까?

적절한 액세스 범위를 결정하기 위한 도구로 앞의 질문과 다음 의사 결정 트리를 사용하십시오.

Decision tree for determining the scope of access

그림 1. 시스템 속성에 대한 액세스 범위를 결정하기 위한 의사결정 트리

3단계: 시스템/sepolicy에 추가

sysprop에 액세스할 때 SELinux는 프로세스의 액세스 가능성을 제어합니다. 필요한 접근성 수준을 결정한 후 system/sepolicy 아래에 속성 컨텍스트를 정의하고 프로세스가 읽거나 쓸 수 있는 항목과 허용되지 않는 항목에 대한 추가 허용 및 절대 허용 규칙을 정의합니다.

먼저 system/sepolicy/public/property.te 파일에서 속성 컨텍스트를 정의합니다. 속성이 시스템 내부인 경우 system/sepolicy/private/property.te 파일에서 정의합니다. 시스템 속성에 필요한 접근성을 제공하는 system_[accessibility]_prop([context]) 매크로 중 하나를 사용하세요. 다음은 system/sepolicy/public/property.te 파일의 예입니다.

system_public_prop(audio_foo_prop)
system_vendor_config_prop(audio_bar_prop)

system/sepolicy/private/property.te 파일에 추가하는 예:

system_internal_prop(audio_baz_prop)

둘째, 속성 컨텍스트에 대한 읽기 및(또는) 쓰기 액세스 권한을 부여합니다. system/sepolicy/public/{domain}.te 또는 system/sepolicy/private/{domain}.te 파일에서 set_prop 및 get_prop 매크로를 사용하여 액세스 권한을 부여합니다. 가능하면 private 를 사용하십시오. public 은 set_prop 또는 get_prop 매크로가 핵심 도메인 외부의 모든 도메인에 영향을 미치는 경우에만 적합합니다.

예: system/sepolicy/private/audio.te 파일에서:

set_prop(audio, audio_foo_prop)
set_prop(audio, audio_bar_prop)

예: system/sepolicy/public/domain.te 파일에서:

get_prop(domain, audio_bar_prop)

셋째, 매크로에 의해 범위가 지정된 액세스 가능성을 더 줄이기 위해 몇 가지 Neverallow 규칙을 추가합니다. 예를 들어 시스템 속성은 공급업체 프로세스에서 읽어야 하므로 system_restricted_prop 을 사용했다고 가정합니다. 읽기 액세스가 모든 공급업체 프로세스에 필요하지 않고 특정 프로세스 집합(예: vendor_init )에서만 필요한 경우 읽기 액세스가 필요하지 않은 공급업체 프로세스를 금지합니다.

쓰기 및 읽기 액세스를 제한하려면 다음 구문을 사용하십시오.

쓰기 액세스를 제한하려면:

neverallow [domain] [context]:property_service set;

읽기 액세스를 제한하려면:

neverallow [domain] [context]:file no_rw_file_perms;

Neverallow 규칙이 특정 도메인에 바인딩된 경우 system/sepolicy/private/{domain}.te 파일에 Neverallow 규칙을 배치합니다. 더 광범위한 Neverallow 규칙의 경우 적절한 경우 다음과 같은 일반 도메인을 사용하세요.

  • system/sepolicy/private/property.te
  • system/sepolicy/private/coredomain.te
  • system/sepolicy/private/domain.te

system/sepolicy/private/audio.te 파일에 다음을 배치합니다.

neverallow {
    domain -init -audio
} {audio_foo_prop audio_bar_prop}:property_service set;

system/sepolicy/private/property.te 파일에 다음을 배치합니다.

neverallow {
    domain -coredomain -vendor_init
} audio_prop:file no_rw_file_perms;

{domain -coredomain} 은 모든 공급업체 프로세스를 캡처합니다. 따라서 {domain -coredomain -vendor_init} 은 " vendor_init 를 제외한 모든 공급업체 프로세스"를 의미합니다.

마지막으로 시스템 속성을 속성 컨텍스트와 연결합니다. 이렇게 하면 부여된 액세스 권한과 속성 컨텍스트에 적용되는 Neverallow 규칙이 실제 속성에 적용됩니다. 이렇게 하려면 시스템 속성과 속성 컨텍스트 간의 매핑을 설명하는 파일인 property_contexts 파일에 항목을 추가합니다. 이 파일에서 단일 속성을 지정하거나 컨텍스트에 매핑할 속성의 접두사를 지정할 수 있습니다.

다음은 단일 속성을 매핑하는 구문입니다.

[property_name] u:object_r:[context_name]:s0 exact [type]

다음은 접두사 매핑 구문입니다.

[property_name_prefix] u:object_r:[context_name]:s0 prefix [type]

다음 중 하나일 수 있는 속성 유형을 선택적으로 지정할 수 있습니다.

  • bool
  • int
  • uint
  • double
  • enum [list of possible values...]
  • string (목록 속성에 string 을 사용합니다.)

property 을 설정할 때 type 이 적용되므로 가능한 한 모든 항목에 지정된 유형이 있는지 확인하십시오. 다음 예에서는 매핑을 작성하는 방법을 보여줍니다.

# binds a boolean property "ro.audio.status.enabled"
# to the context "audio_foo_prop"
ro.audio.status.enabled u:object_r:audio_foo_prop:s0 exact bool

# binds a boolean property "vold.decrypt.status"
# to the context "vold_foo_prop"
# The property can only be set to one of these: on, off, unknown
vold.decrypt.status u:object_r:vold_foo_prop:s0 exact enum on off unknown

# binds any properties starting with "ro.audio.status."
# to the context "audio_bar_prop", such as
# "ro.audio.status.foo", or "ro.audio.status.bar.baz", and so on.
ro.audio.status. u:object_r:audio_bar_prop:s0 prefix

정확한 항목과 접두어 항목이 충돌하는 경우 정확한 항목이 우선합니다. 더 많은 예는 system/sepolicy/private/property_contexts 를 참조하십시오.

4단계: 안정성 요구 사항 결정

안정성은 시스템 속성의 또 다른 측면이며 접근성과 다릅니다. 안정성은 미래에 시스템 속성을 변경할 수 있는지(예: 이름을 바꾸거나 제거할 수 있는지 여부)에 관한 것입니다. 이는 Android OS가 모듈화됨에 따라 특히 중요합니다. Treble을 사용하면 시스템, 공급업체 및 제품 파티션을 서로 독립적으로 업데이트할 수 있습니다. Mainline을 사용하면 OS의 일부가 APEX 또는 APK에서 업데이트 가능한 모듈로 모듈화됩니다.

시스템 속성이 업데이트 가능한 소프트웨어 부분(예: 시스템 및 공급업체 파티션 전체)에서 사용되는 경우 안정적이어야 합니다. 그러나 예를 들어 특정 Mainline 모듈 내에서만 사용되는 경우 해당 이름, 유형 또는 속성 컨텍스트를 변경하고 제거할 수도 있습니다.

시스템 속성의 안정성을 확인하려면 다음 질문을 하십시오.

  • 이 시스템 속성은 파트너가 구성하기 위한 것입니까(또는 장치별로 다르게 구성됨)? 그렇다면 안정적이어야 합니다.
  • 이 AOSP 정의 시스템 속성은 vendor.img 또는 product.img 와 같은 비시스템 파티션에 있는 코드(프로세스 아님)에 쓰거나 읽기 위한 것입니까? 그렇다면 안정적이어야 합니다.
  • 이 시스템 속성은 메인라인 모듈 또는 메인라인 모듈과 플랫폼의 업데이트할 수 없는 부분에 걸쳐 액세스됩니까? 그렇다면 안정적이어야 합니다.

안정적인 시스템 속성의 경우 6단계 에서 설명한 대로 각각을 공식적으로 API로 정의하고 API를 사용하여 시스템 속성에 액세스합니다.

5단계: 빌드 시 속성 설정

makefile 변수를 사용하여 빌드 시 속성을 설정합니다. 기술적으로 값은 {partition}/build.prop 에 구워집니다. 그런 다음 init 는 {partition}/build.prop 을 읽어 속성을 설정합니다. 이러한 변수에는 PRODUCT_{PARTITION}_PROPERTIES 및 TARGET_{PARTITION}_PROP 의 두 가지 세트가 있습니다.

PRODUCT_{PARTITION}_PROPERTIES 에는 속성 값 목록이 포함되어 있습니다. 구문은 {prop}={value} 또는 {prop}?={value} 입니다.

{prop}={value} 는 {prop} 가 {value} 로 설정되도록 하는 일반 할당입니다. 이러한 할당은 단일 속성당 하나만 가능합니다.

{prop}?={value} 는 선택적 할당입니다. {prop} 는 {prop}={value} 할당이 없는 경우에만 {value} }로 설정합니다. 여러 선택적 할당이 있는 경우 첫 번째 할당이 이깁니다.

# sets persist.traced.enable to 1 with system/build.prop
PRODUCT_SYSTEM_PROPERTIES += persist.traced.enable=1

# sets ro.zygote to zygote32 with system/build.prop
# but only when there are no other assignments to ro.zygote
# optional are useful when giving a default value to a property
PRODUCT_SYSTEM_PROPERTIES += ro.zygote?=zygote32

# sets ro.config.low_ram to true with vendor/build.prop
PRODUCT_VENDOR_PROPERTIES += ro.config.low_ram=true

TARGET_{PARTITION}_PROP 에는 {partition}/build.prop 으로 직접 내보내지는 파일 목록이 포함되어 있습니다. 각 파일에는 {prop}={value} 쌍의 목록이 포함되어 있습니다.

# example.prop

ro.cp_system_other_odex=0
ro.adb.secure=0
ro.control_privapp_permissions=disable

# emits example.prop to system/build.prop
TARGET_SYSTEM_PROP += example.prop

자세한 내용은 build/make/core/sysprop.mk 를 참조하십시오.

6단계: 런타임 시 속성 액세스

물론 속성은 런타임에 읽고 쓸 수 있습니다.

초기화 스크립트

초기화 스크립트 파일(보통 *.rc 파일)은 ${prop} 또는 ${prop:-default} 로 속성을 읽을 수 있고, 속성이 특정 값이 될 때마다 실행되는 작업을 설정할 수 있으며, setprop 을 사용하여 속성을 작성할 수 있습니다. 명령.

# when persist.device_config.global_settings.sys_traced becomes 1,
# set persist.traced.enable to 1
on property:persist.device_config.global_settings.sys_traced=1
    setprop persist.traced.enable 1

# when security.perf_harden becomes 0,
# write /proc/sys/kernel/sample_rate to the value of
# debug.sample_rate. If it's empty, write -100000 instead
on property:security.perf_harden=0
    write /proc/sys/kernel/sample_rate ${debug.sample_rate:-100000}

getprop 및 setprop 셸 명령

각각 getprop 또는 setprop 셸 명령을 사용하여 속성을 읽거나 쓸 수 있습니다. 자세한 내용은 getprop --help 또는 setprop --help 를 호출하십시오.

$ adb shell getprop ro.vndk.version
$
$ adb shell setprop security.perf_harden 0

C++/Java용 API로서의 Sysprop

sysprop을 API로 사용하면 시스템 속성을 정의하고 구체적이고 유형이 지정된 자동 생성 API를 사용할 수 있습니다. Public 으로 scope 를 설정하면 생성된 API를 경계를 넘어 모듈에서 사용할 수 있으며 API 안정성이 보장됩니다. 다음은 .sysprop 파일, Android.bp 모듈 및 이를 사용하는 C++ 및 Java 코드의 샘플입니다.

# AudioProps.sysprop
# module becomes static class (Java) / namespace (C++) for serving API
module: "android.sysprop.AudioProps"
# owner can be Platform or Vendor or Odm
owner: Platform
# one prop defines one property
prop {
    prop_name: "ro.audio.volume.level"
    type: Integer
    scope: Public
    access: ReadWrite
    api_name: "volume_level"
}
…

// Android.bp
sysprop_library {
    name: "AudioProps",
    srcs: ["android/sysprop/AudioProps.sysprop"],
    property_owner: "Platform",
}

// Both java and cc module can link against sysprop_library
java_library {
    static_libs: ["AudioProps"],
    …
}

cc_binary {
    static_libs: ["AudioProps"],
    …
}

// Java codes accessing generated API
// get volume. use 50 as the default value.
int vol = android.sysprop.AudioProps.volume_level().orElse(50);
// add 10 to the volume level.
android.sysprop.AudioProps.volume_level(vol + 10);

// C++ codes accessing generated API
// get volume. use 50 as the default value.
int vol = android::sysprop::AudioProps::volume_level().value_or(50);
// add 10 to the volume level.
android::sysprop::AudioProps::volume_level(vol + 10);

자세한 내용은 시스템 속성을 API로 구현 을 참조하십시오.

C/C++ 및 Java 저수준 속성 함수 및 메서드

저수준 C/C++ 함수 또는 저수준 Java 메소드를 사용할 수 있더라도 Sysprop을 API로 사용하십시오. 가능하면 Sysprop 사용을 선호하십시오.

libc , libbase 및 libcutils 는 C++ 시스템 속성 기능을 제공합니다. libc 에는 기본 API가 있고 libbase 및 libcutils 함수는 래퍼입니다. 가능하면 libbase sysprop 함수를 사용하십시오. 가장 편리하고 호스트 바이너리는 libbase 기능을 사용할 수 있습니다. 자세한 내용은 sys/system_properties.h ( libc ), android-base/properties.h ( libbase ) 및 cutils/properties.h ( libcutils )를 참조하세요.

android.os.SystemProperties 클래스는 Java 시스템 속성 메서드를 제공합니다.

부록: 공급업체별 속성 추가

파트너(Pixel 개발 환경에서 일하는 Google 직원 포함)는 하드웨어별(또는 기기별) 시스템 속성을 정의하려고 합니다. 공급업체별 속성은 플랫폼이 아닌 자체 하드웨어 또는 장치에 고유한 파트너 소유 속성입니다. 하드웨어 또는 장치에 따라 다르므로 /vendor 또는 /odm 파티션 내에서 사용해야 합니다.

프로젝트 트레블 이후로 플랫폼 속성과 공급업체 속성은 충돌을 방지하기 위해 완전히 분리되었습니다. 다음은 공급업체 속성을 정의하는 방법을 설명하고 항상 사용해야 하는 공급업체 속성을 알려줍니다.

속성 및 컨텍스트 이름의 네임스페이스

모든 공급업체 속성은 다음 접두사 중 하나로 시작하여 해당 속성과 다른 파티션 속성 간의 충돌을 방지해야 합니다.

  • ctl.odm.
  • ctl.vendor.
  • ctl.start$odm.
  • ctl.start$vendor.
  • ctl.stop$odm.
  • ctl.stop$vendor.
  • init.svc.odm.
  • init.svc.vendor.
  • ro.odm.
  • ro.vendor.
  • odm.
  • persist.odm.
  • persist.vendor.
  • vendor.

ro.hardware. 접두사로 허용되지만 호환성을 위해서만 가능합니다. 일반적인 속성에는 사용하지 마십시오.

다음 예에서는 모두 앞에 나열된 접두사 중 하나를 사용합니다.

  • vendor.display.primary_red
  • persist.vendor.faceauth.use_disk_cache
  • ro.odm.hardware.platform

모든 공급업체 속성 컨텍스트는 vendor_ 로 시작해야 합니다. 이것은 호환성을 위한 것이기도 합니다. 다음은 예입니다.

  • vendor_radio_prop .
  • vendor_faceauth_prop .
  • vendor_usb_prop .

속성의 이름을 지정하고 유지 관리하는 것은 공급업체의 책임이므로 공급업체 네임스페이스 요구 사항과 함께 2단계 에서 제안된 형식을 따르십시오.

공급업체별 SEPolicy 규칙 및 property_contexts

플랫폼 속성과 유사하게 공급업체 속성은 다음 매크로 중 하나로 정의할 수 있습니다.

접근성 유형 의미
vendor_internal_prop /vendor 에서만 사용되는 속성
vendor_restricted_prop /vendor 외부에서 읽지만 쓰지 않는 속성
vendor_public_prop /vendor 외부에서 읽고 쓰는 속성

정의한 공급업체별 규칙을 BOARD_VENDOR_SEPOLICY_DIRS 디렉토리에 넣습니다. 예를 들어 산호에서 공급업체 faceauth 속성을 정의한다고 가정합니다.

BoardConfig.mk 파일(또는 BoardConfig.mk 포함)에 다음을 입력합니다.

BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy

device/google/coral-sepolicy/private/property.te 파일에 다음을 입력합니다.

vendor_internal_prop(vendor_faceauth_prop)

device/google/coral-sepolicy/private/property_contexts 파일에 다음을 입력합니다.

vendor.faceauth.trace u:object_r:vendor_faceauth_prop:s0 exact bool

공급업체 속성의 제한 사항

시스템 및 제품 파티션은 공급업체에 의존할 수 없으므로 system , system-ext 또는 product 파티션에서 공급업체 속성에 액세스하는 것을 허용하지 마십시오.

부록: 기존 속성 이름 바꾸기

속성을 더 이상 사용하지 않고 새 속성으로 이동해야 하는 경우 Sysprop을 API 로 사용하여 기존 속성의 이름을 바꿉니다. 이렇게 하면 레거시 이름과 새 속성 이름을 모두 지정하여 이전 버전과의 호환성을 유지합니다. 특히 .sysprop 파일의 legacy_prop_name 필드로 레거시 이름을 설정할 수 있습니다. 생성된 API는 prop_name 읽기를 시도하고 legacy_prop_name 이 없으면 prop_name 을 사용합니다.

예를 들어 다음 단계에서는 Awesome_feature_foo_enabled의 이름을 awesome_feature_foo_enabled 로 foo.awesome_feature.enabled .

foo.sysprop 파일(Java에서)

module: "android.sysprop.foo"
owner: Platform
prop {
    api_name: "is_awesome_feature_enabled"
    type: Boolean
    scope: Public
    access: Readonly
    prop_name: "foo.awesome_feature.enabled"
    legacy_prop_name: "awesome_feature_foo_enabled"
}

C++ 코드에서

// is_awesome_feature_enabled() reads "foo.awesome_feature.enabled".
// If it doesn't exist, reads "awesome_feature_foo_enabled" instead
using android::sysprop::foo;

bool enabled = foo::is_awesome_feature_enabled().value_or(false);

다음 주의 사항에 유의하십시오.

  • 첫째, sysprop의 유형을 변경할 수 없습니다. 예를 들어 int prop을 string prop으로 만들 수 없습니다. 이름만 변경할 수 있습니다.

  • 둘째, 읽기 API만 레거시 이름으로 대체됩니다. 쓰기 API는 대체되지 않습니다. sysprop이 쓰기 가능한 경우 이름을 바꿀 수 없습니다.