Sistem özellikleri ekleme

Bu sayfada, Android'de sistem özelliklerini eklemek veya tanımlamak için standart bir yöntem sunulmakta ve mevcut sistem özelliklerini yeniden düzenlemeyle ilgili yönergeler verilmektedir. Aksi yönde güçlü bir uyumluluk sorununuz yoksa yeniden düzenleme yaparken yönergeleri kullandığınızdan emin olun.

1. adım: Sistem özelliğini tanımlayın

Bir sistem özelliği eklediğinizde özelliğin adını belirleyin ve bunu bir SELinux özelliği bağlamıyla ilişkilendirin. Mevcut bağlam uygun değilse yeni bir bağlam oluştur. Mülke erişilirken ad kullanılır. Mülk bağlamı, SELinux açısından erişilebilirliği kontrol etmek için kullanılır. Adlar herhangi bir dize olabilir ancak AOSP, adların anlaşılır olması için yapılandırılmış bir biçim kullanmanızı önerir.

Mülk adı

snake_case büyük/küçük harf biçimini kullanarak şu biçimi kullanın:

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

prefix öğesi için "" (atlanmış), ro (yalnızca bir kez ayarlanan özellikler için) veya persist (yeniden başlatma işlemleri boyunca kalıcı olan özellikler için) değerlerinden birini kullanın.

Uyarılar

ro öğesini yalnızca gelecekte prefix öğesinin yazılabilir olmasının gerekmeyeceğinden emin olduğunuzda kullanın. ** ro önekini belirtmeyin.** Bunun yerine, prefix'yı salt okunur (diğer bir deyişle yalnızca init tarafından yazılabilir) hale getirmek için sepolicy'ye güvenin.

persist öğesini yalnızca değerin yeniden başlatma işlemleri arasında kalıcı olması gerektiğinden ve sistem özelliklerini kullanmanın tek seçeneğiniz olduğundan eminseniz kullanın.

Google, ro veya persist özelliklerine sahip sistem özelliklerini titizlikle inceler.

group terimi, ilgili mülkleri toplamak için kullanılır. audio veya telephony'ye benzer bir alt sistem adı olması amaçlanmıştır. Kullanmayın sys, system, dev, default veya config gibi belirsiz ya da aşırı yüklenmiş terimler.

Sistemin özelliklerine özel okuma veya yazma erişimi olan bir sürecin alan türünün adını kullanmak yaygın bir uygulamadır. Örneğin, vold işleminin yazma erişimine sahip olduğu sistem özellikleri için grup adı olarak vold (işlemin alan türünün adı) kullanılması yaygındır.

Gerekirse özellikleri daha ayrıntılı şekilde sınıflandırmak için subgroup özelliğini ekleyin ancak bu öğeyi açıklamak için belirsiz veya aşırı yüklenmiş terimler kullanmayın. (Birden fazla subgroup da kullanabilirsiniz.)

Birçok grup adı zaten tanımlanmıştır. system/sepolicy/private/property_contexts dosyasını kontrol edin ve mümkün olduğunda yeni grup adları oluşturmak yerine mevcut grup adlarını kullanın. Aşağıdaki tabloda, sık kullanılan grup adlarıyla ilgili örnekler verilmiştir.

Aşağıda, önceki normal ifade örneğinde name ve type kullanımının tanımı verilmiştir.

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

• name, bir gruptaki sistem özelliğini tanımlar.

• type, sistem özelliğinin türünü veya amacını netleştiren isteğe bağlı bir öğedir. Örneğin, bir sysprop'u audio.awesome_feature_enabled veya yalnızca audio.awesome_feature olarak adlandırmak yerine, sistem özelliği türünü ve amacını yansıtacak şekilde audio.awesome_feature.enabled olarak yeniden adlandırın.

Türün ne olması gerektiğiyle ilgili belirli bir kural yoktur. Bunlar kullanım önerileridir:

• enabled: Tür, bir özelliği etkinleştirmek veya devre dışı bırakmak için kullanılan bir boole sistem özelliği ise kullanın.
• config: Sistem özelliğinin sistemin dinamik bir durumunu temsil etmediğini, önceden yapılandırılmış bir değeri (ör. salt okunur bir öğe) temsil ettiğini netleştirmek için kullanılır.
• List: Değeri liste olan bir sistem özelliği ise kullanın.
• Timeoutmillis: Bir zaman aşımı değerinin ms birimlerindeki sistem özelliği ise kullanın.

Örnekler:

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

Tesis bağlamı

Yeni SELinux özelliği bağlam şeması, daha ayrıntılı ve açıklayıcı adlara olanak tanır. AOSP, mülk adları için kullanılanlara benzer şekilde aşağıdaki biçimi önerir:

{group}[_{subgroup}]*_prop

Terimler aşağıdaki şekilde tanımlanır:

group ve subgroup, önceki örnek normal ifade için tanımlanan anlamla aynıdır. Örneğin, vold_config_prop, bir tedarikçinin yapılandırmaları olan ve vendor_init tarafından ayarlanması gereken özellikleri belirtirken vold_status_prop veya yalnızca vold_prop, vold öğesinin mevcut durumunu göstermesi gereken özellikleri belirtir.

Bir mülk bağlamına ad verirken mülklerin genel kullanımını yansıtan adlar seçin. Özellikle aşağıdaki terim türlerinden kaçının:

• sys, system, default gibi çok genel ve belirsiz görünen terimler.
• Doğrudan erişilebilirliği kodlayan terimler: Örneğin exported, apponly, ro, public, private.

vold_config_prop gibi ad kullanımlarını exported_vold_prop veya vold_vendor_writable_prop'ye tercih edin.

Tür

Mülk türü, tabloda listelenenlerden biri olabilir.

Dahili olarak tüm özellikler dize olarak saklanır. property_contexts dosyası olarak belirterek türü zorunlu kılabilirsiniz. Daha fazla bilgi için 3. adım bölümündeki property_contexts işaretine bakın.

2. adım: Gerekli erişilebilirlik düzeylerini belirleyin

Bir özelliği tanımlayan dört yardımcı makro vardır.

Sistem özelliklerine erişimi mümkün olduğunca dar bir kapsamda tutun. Geçmişte geniş erişim, uygulamaların bozulmasına ve güvenlik açıklarına yol açmıştır. Kapsamı belirlerken aşağıdaki soruları göz önünde bulundurun:

• Bu sistem özelliğinin kalıcı olması gerekiyor mu? (Varsa neden?)
• Hangi sürecin bu mülke okuma erişimi olmalıdır?
• Bu mülke hangi süreç yazma erişimine sahip olmalıdır?

Erişim için uygun kapsamı belirlemek üzere önceki soruları ve aşağıdaki karar ağacını araç olarak kullanın.

1. şekil. Sistem özelliklerine erişim kapsamını belirlemeye yönelik karar ağacı

3. adım: Sisteme/sepolicy'ye ekleyin

SELinux, sysprop'a erişirken işlemlerin erişilebilirliğini kontrol eder. Hangi düzeyde erişilebilirlik gerektiğini belirledikten sonra, system/sepolicy altında mülk bağlamlarını tanımlayın. Ayrıca, işlemlerin okumasına veya yazmasına izin verilen (ve verilmeyen) içeriklerle ilgili ek izin ver ve izin verme kurallarını da tanımlayın.

Öncelikle system/sepolicy/public/property.te dosyasında mülk bağlamını tanımlayın. Özellik sistem içinde kullanılıyorsa system/sepolicy/private/property.te dosyasında tanımlayın. Sistem özelliğinizin gerektirdiği erişilebilirliği sağlayan system_[accessibility]_prop([context]) makrolarından birini kullanın. Aşağıda system/sepolicy/public/property.te dosyası için bir örnek verilmiştir:

system_public_prop(audio_foo_prop)
system_vendor_config_prop(audio_bar_prop)

system/sepolicy/private/property.te dosyasına eklenecek örnek:

system_internal_prop(audio_baz_prop)

İkinci olarak, mülk bağlamına okuma ve/veya yazma erişimi verin. set_prop ve get_prop makrolarını kullanarak system/sepolicy/public/{domain}.te veya system/sepolicy/private/{domain}.te dosyasında erişim izni verin. Mümkün olduğunda private kullanın. public yalnızca set_prop veya get_prop makrosu, temel alanın dışındaki alanları etkiliyorsa uygundur.

Örneğin, system/sepolicy/private/audio.te dosyasında:

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

Örneğin, system/sepolicy/public/domain.te dosyasında:

get_prop(domain, audio_bar_prop)

Üçüncüsü, makro tarafından kapsamı belirlenen erişilebilirliği daha da azaltmak için bazı neverallow kuralları ekleyin. Örneğin, sistem özelliklerinizin satıcı işlemleri tarafından okunması gerektiği için system_restricted_prop kullandığınızı varsayalım. Okuma erişimi tüm satıcı işlemleri için gerekli değilse ve yalnızca belirli bir işlem grubu (ör. vendor_init) için gerekliyse okuma erişimine ihtiyaç duymayan satıcı işlemlerini yasaklayın.

Yazma ve okuma erişimini kısıtlamak için aşağıdaki söz dizimini kullanın:

Yazma erişimini kısıtlamak için:

neverallow [domain] [context]:property_service set;

Okuma erişimini kısıtlamak için:

neverallow [domain] [context]:file no_rw_file_perms;

neverallow kuralı belirli bir alana bağlıysa system/sepolicy/private/{domain}.te dosyasına neverallow kuralları yerleştirin. Daha kapsamlı neverallow kuralları için uygun olan her yerde aşağıdaki gibi genel alanları kullanın:

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

system/sepolicy/private/audio.te dosyasında aşağıdakileri yerleştirin:

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

system/sepolicy/private/property.te dosyasında aşağıdakileri yerleştirin:

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

{domain -coredomain} simgesinin tüm tedarikçi süreçlerini kapsadığını unutmayın. Yani {domain -coredomain -vendor_init}, "vendor_init hariç tüm satıcı süreçleri" anlamına gelir.

Son olarak, bir sistem özelliğini mülk bağlamıyla ilişkilendirin. Bu sayede, verilen erişim ve mülk bağlamlarına uygulanan neverallow kurallarının gerçek mülklere uygulanması sağlanır. Bunu yapmak için property_contexts dosyasına bir giriş ekleyin. Bu dosya, sistem özellikleri ile özellik bağlamları arasındaki eşlemeyi açıklar. Bu dosyada tek bir özellik veya bir bağlama eşlenecek özelliklerin ön ekini belirtebilirsiniz.

Tek bir mülkü eşlemek için kullanılan söz dizimi:

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

Önek eşleme söz dizimi:

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

İsteğe bağlı olarak mülk türünü belirtebilirsiniz. Mülk türü aşağıdakilerden biri olabilir:

• bool
• int
• uint
• double
• enum [list of possible values...]
• string (Liste özelliklerinde string simgesini kullanın.)

type, property ayarlanırken zorunlu kılındığından mümkün olduğunda her girişin belirlenen türe sahip olduğundan emin olun. Aşağıdaki örnekte bir eşlemenin nasıl yazılacağı gösterilmektedir:

# 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

Tam giriş ile önek girişi çakıştığında tam giriş öncelikli olur. Daha fazla örnek için system/sepolicy/private/property_contexts sayfasına bakın.

4. adım: Kararlılık şartlarını belirleyin

Kararlılık, sistem özelliklerinin bir diğer yönüdür ve erişilebilirlikten farklıdır. Kararlılık, bir sistem özelliğinin gelecekte değiştirilip değiştirilemeyeceği (örneğin, yeniden adlandırılıp adlandırılamayacağı veya hatta kaldırılıp kaldırılamayacağı) ile ilgilidir. Android işletim sistemi modüler hale geldiğinden bu durum özellikle önemlidir. Treble ile sistem, satıcı ve ürün bölümleri birbirinden bağımsız olarak güncellenebilir. Mainline ile işletim sisteminin bazı bölümleri, güncellenebilir modüller (APEX veya APK'larda) olarak modüler hale getirilir.

Bir sistem özelliği, güncellenebilir yazılım parçalarında (ör. sistem ve tedarikçi bölümleri arasında) kullanılacaksa kararlı olmalıdır. Ancak, örneğin yalnızca belirli bir Mainline modülünde kullanılıyorsa adını, türünü veya özellik bağlamlarını değiştirebilir, hatta kaldırabilirsiniz.

Bir sistem özelliğinin kararlılığını belirlemek için aşağıdaki soruları sorun:

• Bu sistem özelliği iş ortakları tarafından yapılandırılmak (veya cihaz başına farklı şekilde yapılandırılmak) için mi tasarlanmıştır? Evetse kararlı olmalıdır.
• Bu AOSP tanımlı sistem özelliği, vendor.img veya product.img gibi sistem dışı bölümlerde bulunan kodlara (işlem değil) yazılmak ya da bu kodlardan okunmak için mi tasarlanmıştır? Evetse kararlı olmalıdır.
• Bu sistem özelliği, Mainline modülleri arasında mı yoksa bir Mainline modülü ile platformun güncellenemeyen kısmı arasında mı kullanılıyor? Evetse kararlı olmalıdır.

Kararlı sistem özellikleri için her birini resmi olarak API olarak tanımlayın ve 6. adımda açıklandığı gibi sistem özelliğine erişmek için API'yi kullanın.

5. adım: Derleme sırasında özellikleri ayarlayın

Makefile değişkenleriyle derleme zamanında özellikleri ayarlayın. Teknik olarak değerler {partition}/build.prop'a yerleştirilir. Ardından, özellikleri ayarlamak için init hareketini yapın.{partition}/build.prop Bu tür değişkenlerden iki grup vardır: PRODUCT_{PARTITION}_PROPERTIES ve TARGET_{PARTITION}_PROP.

PRODUCT_{PARTITION}_PROPERTIES, özellik değerlerinin listesini içerir. Söz dizimi {prop}={value} veya {prop}?={value} şeklindedir.

{prop}={value}, {prop} değerinin {value} olarak ayarlanmasını sağlayan normal bir atamadır. Tek bir mülk için yalnızca bir atama yapılabilir.

{prop}?={value} isteğe bağlı bir atamadır; {prop}, yalnızca {prop}={value} ataması yoksa {value} olarak ayarlanır. Birden fazla isteğe bağlı atama varsa ilk atama geçerli olur.

# 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, doğrudan {partition}/build.prop'ye gönderilen bir dosya listesi içerir. Her dosya {prop}={value} çiftinin listesini içerir.

# 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

Daha ayrıntılı bilgi için build/make/core/sysprop.mk başlıklı makaleyi inceleyin.

6. adım: Çalışma zamanında özelliklere erişin

Özellikler çalışma zamanında okunabilir ve yazılabilir.

Init komut dosyaları

Başlatma komut dosyaları (genellikle *.rc dosyaları) ${prop} veya ${prop:-default} ile bir özelliği okuyabilir, bir özellik belirli bir değer haline geldiğinde çalışan bir işlem ayarlayabilir ve setprop komutunu kullanarak özellikleri yazabilir.

# 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 ve setprop kabuk komutları

Özellikleri okumak veya yazmak için sırasıyla getprop veya setprop kabuk komutlarını kullanabilirsiniz. Daha fazla bilgi için getprop --help veya setprop --help öğesini çağırın.

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

C++/Java/Rust için API olarak Sysprop

API olarak sysprop ile sistem özelliklerini tanımlayabilir ve somut ve türü belirlenmiş otomatik olarak oluşturulan API'yi kullanabilirsiniz. scope ile Public ayarlanması, oluşturulan API'lerin sınırlar arası modüller tarafından kullanılabilmesini sağlar ve API kararlılığını garanti eder. Aşağıda, .sysprop dosyası, Android.bp modülü ve bunları kullanan C++, Java ve Rust koduna dair bir örnek verilmiştir.

# 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",
}

// Rust, Java and C++ modules can link against the sysprop_library
rust_binary {
    rustlibs: ["libaudioprops_rust"],
    …
}

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

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

// Rust code accessing generated API.
// Get volume. Use 50 as the default value.
let vol = audioprops::volume_level()?.unwrap_or_else(50);

// 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);

Daha fazla bilgi için Sistem özelliklerini API olarak uygulama başlıklı makaleyi inceleyin.

C/C++, Java ve Rust düşük seviyeli özellik işlevleri ve yöntemleri

Mümkün olduğunda, düşük düzeyli C/C++ veya Rust işlevleri ya da düşük düzeyli Java yöntemleri kullanılabiliyor olsa bile API olarak Sysprop'u kullanın.

libc, libbase ve libcutils, C++ sistem özelliği işlevleri sunar. libc temel API'ye sahipken libbase ve libcutils işlevleri sarmalayıcıdır. Mümkünse libbase sysprop işlevlerini kullanın. Bu işlevler en uygun olanlardır ve ana makine ikilileri libbase işlevlerini kullanabilir. Daha fazla bilgi için sys/system_properties.h (libc), android-base/properties.h (libbase) ve cutils/properties.h (libcutils) başlıklı makaleleri inceleyin.

android.os.SystemProperties sınıfı, Java sistem özelliği yöntemleri sunar.

rustutils::system_properties modülü, Rust sistem özelliği işlevleri ve türleri sunar.

Ek: Tedarikçiye özel özellikler ekleme

İş ortakları (Pixel geliştirme bağlamında çalışan Google çalışanları dahil) donanıma özgü (veya cihaza özgü) sistem özellikleri tanımlamak istiyor. Tedarikçiye özgü özellikler, platforma değil, kendi donanımlarına veya cihazlarına özgü olan ve iş ortağına ait özelliklerdir. Bunlar donanıma veya cihaza bağlı olduğundan /vendor ya da /odm bölümlerinde kullanılmak üzere tasarlanmıştır.

Project Treble'dan beri, platform özellikleri ve satıcı özellikleri çakışmalarını önlemek için tamamen ayrılmıştır. Aşağıda, satıcı özelliklerinin nasıl tanımlanacağı ve hangi satıcı özelliklerinin her zaman kullanılması gerektiği açıklanmaktadır.

Mülk ve bağlam adlarındaki ad alanı

Tüm satıcı özellikleri, kendileri ile diğer bölümlerin özellikleri arasında çakışmayı önlemek için aşağıdaki öneklerden biriyle başlamalıdır.

• 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. ön ek olarak kullanılabilir ancak yalnızca uyumluluk için. Normal mülkler için kullanmayın.

Aşağıdaki örneklerin tümünde, yukarıda listelenen öneklerden biri kullanılmaktadır:

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

Tüm satıcı mülkü bağlamları vendor_ ile başlamalıdır. Bu, uyumluluk için de geçerlidir. Örnekler:

• vendor_radio_prop.
• vendor_faceauth_prop.
• vendor_usb_prop.

Özellikleri adlandırmak ve korumak satıcının sorumluluğundadır. Bu nedenle, satıcı ad alanları şartlarının yanı sıra 2. adımda önerilen biçimi uygulayın.

Tedarikçiye özel SEPolicy kuralları ve property_contexts

Tedarikçi özellikleri vendor_internal_prop makrosuyla tanımlanabilir. Tanımladığınız tedarikçiye özel kuralları BOARD_VENDOR_SEPOLICY_DIRS dizinine yerleştirin. Örneğin, mercan renginde bir vendor faceauth özelliği tanımladığınızı varsayalım.

BoardConfig.mk dosyasında (veya herhangi bir BoardConfig.mk dosyasında) aşağıdakileri girin:

BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy

device/google/coral-sepolicy/private/property.te dosyasında aşağıdakileri girin:

vendor_internal_prop(vendor_faceauth_prop)

device/google/coral-sepolicy/private/property_contexts dosyasında aşağıdakileri girin:

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

Tedarikçi özelliklerinin sınırlamaları

Sistem ve ürün bölümleri tedarikçiye bağlı olamayacağından, tedarikçi özelliklerine system, system-ext veya product bölümlerinden erişilmesine asla izin vermeyin.

Ek: Mevcut özellikleri yeniden adlandırma

Bir mülkün desteğini sonlandırıp yeni bir mülke geçmeniz gerektiğinde mevcut mülklerinizi yeniden adlandırmak için Sysprop as APIs'yi kullanın. Bu, hem eski adı hem de yeni mülk adını belirterek geriye dönük uyumluluğu korur. Özellikle, .sysprop dosyasındaki legacy_prop_name alanını kullanarak eski adı ayarlayabilirsiniz. Oluşturulan API, prop_name değerini okumaya çalışır ve prop_name değeri yoksa legacy_prop_name değerini kullanır.

Örneğin, aşağıdaki adımlarda awesome_feature_foo_enabled, foo.awesome_feature.enabled olarak yeniden adlandırılır.

foo.sysprop dosyasında

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++ kodunda

// 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);

Aşağıdaki uyarıları dikkate alın:

• İlk olarak, sysprop türünü değiştiremezsiniz. Örneğin, int öğesini string öğesine dönüştüremezsiniz. Yalnızca adı değiştirebilirsiniz.

• İkinci olarak, yalnızca okuma API'si eski ada geri döner. Yazma API'si geri dönüş yapmaz. Sysprop yazılabilir bir öğe ise yeniden adlandıramazsınız.