Halaman ini menyediakan metode kanonik untuk menambahkan atau mendefinisikan properti sistem di Android, dengan pedoman untuk memfaktorkan ulang properti sistem yang ada. Pastikan Anda menggunakan pedoman saat melakukan refaktorisasi, kecuali Anda memiliki masalah kompatibilitas kuat yang menentukan sebaliknya.
Langkah 1: Mendefinisikan properti sistem
Saat Anda menambahkan properti sistem, tentukan nama untuk properti tersebut, dan kaitkan dengan konteks properti SELinux. Jika tidak ada konteks yang sesuai, buat konteks baru. Nama tersebut digunakan saat mengakses properti; konteks properti digunakan untuk mengontrol aksesibilitas dalam hal SELinux. Nama dapat berupa string apa pun, namun AOSP menyarankan Anda mengikuti format terstruktur agar jelas.
Nama properti
Gunakan format ini dengan casing ular_case:
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
Gunakan “” (dihilangkan), ro
(untuk properti yang disetel hanya sekali), atau persist
(untuk properti yang bertahan selama reboot) untuk prefix
elemen .
Peringatan
Gunakan ro
hanya jika Anda yakin bahwa Anda tidak memerlukan prefix
agar dapat ditulis di masa mendatang. ** Jangan tentukan awalan ro
.** Sebaliknya, andalkan sepolicy untuk menjadikan prefix
hanya-baca (dengan kata lain, hanya dapat ditulis oleh init
).
Gunakan persist
hanya ketika Anda yakin bahwa nilainya harus dipertahankan saat reboot, dan menggunakan properti sistem adalah satu-satunya pilihan Anda. (Untuk detailnya lihat bagian Persiapan .)
Google secara ketat meninjau properti sistem yang memiliki properti ro
atau persist
.
Istilah group
digunakan untuk menggabungkan properti terkait. Ini dimaksudkan sebagai nama subsistem yang serupa penggunaannya dengan audio
atau telephony
. Jangan gunakan istilah yang ambigu atau berlebihan seperti sys
, system
, dev
, default
, atau config
.
Merupakan praktik umum untuk menggunakan nama jenis domain dari suatu proses yang memiliki akses baca atau tulis eksklusif ke properti sistem. Misalnya, untuk properti sistem yang akses tulisnya dimiliki oleh proses vold
, biasanya menggunakan vold
(nama tipe domain untuk proses tersebut) sebagai nama grup.
Jika perlu, tambahkan subgroup
untuk mengkategorikan properti lebih lanjut, namun hindari istilah yang ambigu atau berlebihan untuk mendeskripsikan elemen ini. (Anda juga dapat memiliki lebih dari satu subgroup
.)
Banyak nama grup telah ditentukan. Periksa file system/sepolicy/private/property_contexts
dan gunakan nama grup yang ada jika memungkinkan, daripada membuat yang baru. Tabel berikut memberikan contoh nama grup yang sering digunakan.
Domain | Grup (dan subgrup) |
---|---|
terkait bluetooth | bluetooth |
sysprops dari cmdline kernel | boot |
sysprops yang mengidentifikasi build | build |
berhubungan dengan telepon | telephony |
terkait audio | audio |
terkait grafis | graphics |
terkait vol | vold |
Berikut ini definisi penggunaan name
dan type
pada contoh regex sebelumnya.
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
name
mengidentifikasi properti sistem dalam grup.type
adalah elemen opsional yang memperjelas tipe atau maksud properti sistem. Misalnya, alih-alih memberi nama sysprop sebagaiaudio.awesome_feature_enabled
atau hanyaaudio.awesome_feature
, ganti namanya menjadiaudio.awesome_feature.enabled
untuk mencerminkan jenis dan maksud properti sistem.
Tidak ada aturan khusus tentang jenisnya; ini adalah rekomendasi penggunaan:
-
enabled
: Gunakan jika tipenya adalah properti sistem boolean yang digunakan untuk mengaktifkan atau menonaktifkan fitur. -
config
: Gunakan jika tujuannya adalah untuk memperjelas bahwa properti sistem tidak mewakili keadaan dinamis sistem; itu mewakili nilai yang telah dikonfigurasi sebelumnya (misalnya, sesuatu yang hanya bisa dibaca). -
List
: Gunakan jika itu adalah properti sistem yang nilainya berupa daftar. -
Timeoutmillis
: Gunakan jika itu adalah properti sistem untuk nilai batas waktu dalam satuan ms.
Contoh:
-
persist.radio.multisim.config
-
drm.service.enabled
Konteks Properti
Skema konteks properti SELinux yang baru memungkinkan perincian yang lebih halus dan nama yang lebih deskriptif. Mirip dengan yang digunakan untuk nama properti, AOSP merekomendasikan format berikut:
{group}[_{subgroup}]*_prop
Istilah-istilah tersebut didefinisikan sebagai berikut:
group
dan subgroup
memiliki arti yang sama seperti yang didefinisikan untuk sampel regex sebelumnya. Misalnya, vold_config_prop
menandakan properti yang merupakan konfigurasi dari vendor dan dimaksudkan untuk disetel oleh vendor_init
, sedangkan vold_status_prop
atau hanya vold_prop
menandakan properti yang mengekspos status vold
saat ini.
Saat memberi nama konteks properti, pilih nama yang mencerminkan penggunaan umum properti tersebut. Secara khusus, hindari jenis istilah berikut:
- Istilah yang terlihat terlalu umum dan ambigu, seperti
sys
,system
,default
. - Istilah yang secara langsung menyandikan aksesibilitas: seperti
exported
,apponly
,ro
,public
,private
.
Lebih suka penggunaan nama seperti vold_config_prop
ke exported_vold_prop
, atau vold_vendor_writable_prop
, dan seterusnya.
Jenis
Tipe properti dapat berupa salah satu dari berikut ini seperti yang tercantum dalam tabel.
Jenis | Definisi |
---|---|
Boolean | true atau 1 untuk benar, false atau 0 untuk salah |
Bilangan bulat | menandatangani bilangan bulat 64-bit |
Bilangan bulat yang tidak ditandatangani | bilangan bulat 64-bit yang tidak ditandatangani |
Dobel | titik mengambang presisi ganda |
Rangkaian | string UTF-8 apa pun yang valid |
enum | nilai dapat berupa string UTF-8 yang valid tanpa spasi |
Daftar di atas | Tanda koma ( , ) digunakan sebagai pembatasDaftar bilangan bulat [1, 2, 3] disimpan sebagai 1,2,3 |
Secara internal, semua properti disimpan sebagai string. Anda dapat menerapkan tipe ini dengan menetapkannya sebagai file property_contexts
. Untuk informasi selengkapnya, lihat property_contexts
di Langkah 3 .
Langkah 2: Menentukan tingkat aksesibilitas yang diperlukan
Ada empat makro pembantu yang mendefinisikan properti.
Jenis aksesibilitas | Arti |
---|---|
system_internal_prop | Properti yang hanya digunakan di /system |
system_restricted_prop | Properti yang dibaca di luar /system , tetapi tidak ditulis |
system_vendor_config_prop | Properti yang dibaca di luar /system , dan hanya ditulis oleh vendor_init |
system_public_prop | Properti yang dibaca dan ditulis di luar /system |
Cakupan akses ke properti sistem sesempit mungkin. Di masa lalu, akses yang luas mengakibatkan kerusakan aplikasi dan kerentanan keamanan. Pertimbangkan pertanyaan-pertanyaan berikut saat melakukan pelingkupan:
- Apakah properti sistem ini perlu dipertahankan? (jika ya, mengapa?)
- Proses manakah yang seharusnya memiliki akses baca ke properti ini?
- Proses mana yang harus memiliki akses tulis ke properti ini?
Gunakan pertanyaan sebelumnya dan pohon keputusan berikut sebagai alat untuk menentukan cakupan akses yang tepat.
Gambar 1. Pohon keputusan untuk menentukan cakupan akses ke properti sistem
Langkah 3: Menambahkannya ke system/sepolicy
Saat mengakses sysprop, SELinux mengontrol aksesibilitas proses. Setelah Anda menentukan tingkat aksesibilitas yang diperlukan, tentukan konteks properti di bawah system/sepolicy
, bersama dengan aturan izinkan dan jangan pernah izinkan tambahan tentang proses apa saja yang boleh (dan tidak boleh) dibaca atau ditulis.
Pertama, tentukan konteks properti di file system/sepolicy/public/property.te
. Jika properti bersifat internal sistem, tentukan properti tersebut di file system/sepolicy/private/property.te
. Gunakan salah satu makro system_[accessibility]_prop([context])
yang menyediakan aksesibilitas yang diperlukan properti sistem Anda. Ini adalah contoh untuk file system/sepolicy/public/property.te
:
system_public_prop(audio_foo_prop)
system_vendor_config_prop(audio_bar_prop)
Contoh untuk menambahkan file system/sepolicy/private/property.te
:
system_internal_prop(audio_baz_prop)
Kedua, memberikan akses baca dan (atau) tulis ke konteks properti. Gunakan makro set_prop
dan get_prop
untuk memberikan akses, baik dalam file system/sepolicy/public/{domain}.te
atau system/sepolicy/private/{domain}.te
. Gunakan private
bila memungkinkan; public
hanya cocok jika makro set_prop
atau get_prop
memengaruhi domain apa pun di luar domain inti.
Contoh, dalam file system/sepolicy/private/audio.te
:
set_prop(audio, audio_foo_prop)
set_prop(audio, audio_bar_prop)
Contoh, di file system/sepolicy/public/domain.te
:
get_prop(domain, audio_bar_prop)
Ketiga, tambahkan beberapa aturan neverallow untuk mengurangi aksesibilitas yang dicakup oleh makro. Misalnya, asumsikan Anda telah menggunakan system_restricted_prop
karena properti sistem Anda harus dibaca oleh proses vendor. Jika akses baca tidak diperlukan oleh semua proses vendor, dan hanya diperlukan oleh serangkaian proses tertentu (seperti vendor_init
), larang proses vendor yang tidak memerlukan akses baca.
Gunakan sintaks berikut untuk membatasi akses tulis dan baca:
Untuk membatasi akses tulis:
neverallow [domain] [context]:property_service set;
Untuk membatasi akses baca:
neverallow [domain] [context]:file no_rw_file_perms;
Tempatkan aturan neverallow di file system/sepolicy/private/{domain}.te
jika aturan neverallow terikat pada domain tertentu. Untuk aturan neverallow yang lebih luas, gunakan domain umum seperti berikut jika diperlukan:
-
system/sepolicy/private/property.te
-
system/sepolicy/private/coredomain.te
-
system/sepolicy/private/domain.te
Di file system/sepolicy/private/audio.te
, tempatkan yang berikut ini:
neverallow {
domain -init -audio
} {audio_foo_prop audio_bar_prop}:property_service set;
Di file system/sepolicy/private/property.te
, tempatkan yang berikut ini:
neverallow {
domain -coredomain -vendor_init
} audio_prop:file no_rw_file_perms;
Perhatikan bahwa {domain -coredomain}
menangkap semua proses vendor. Jadi {domain -coredomain -vendor_init}
berarti “semua proses vendor kecuali vendor_init
.”
Terakhir, kaitkan properti sistem dengan konteks properti. Hal ini memastikan bahwa akses yang diberikan dan aturan neverallow yang diterapkan pada konteks properti diterapkan pada properti sebenarnya. Untuk melakukannya, tambahkan entri ke file property_contexts
, file yang menjelaskan pemetaan antara properti sistem dan konteks properti. Dalam file ini, Anda dapat menentukan properti tunggal, atau awalan untuk properti yang akan dipetakan ke dalam konteks.
Ini adalah sintaks untuk memetakan satu properti:
[property_name] u:object_r:[context_name]:s0 exact [type]
Ini adalah sintaks untuk memetakan awalan:
[property_name_prefix] u:object_r:[context_name]:s0 prefix [type]
Anda juga dapat menentukan jenis properti, yang dapat berupa salah satu dari berikut ini:
-
bool
-
int
-
uint
-
double
-
enum [list of possible values...]
-
string
(Gunakanstring
untuk properti daftar.)
Pastikan bahwa setiap entri memiliki tipe yang ditentukan bila memungkinkan, karena type
diterapkan saat menyetel property
. Contoh berikut menunjukkan cara menulis pemetaan:
# 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
Jika entri eksak dan entri awalan bertentangan, entri eksak akan diutamakan. Untuk contoh selengkapnya, lihat system/sepolicy/private/property_contexts
.
Langkah 4: Menentukan persyaratan stabilitas
Stabilitas adalah aspek lain dari properti sistem, dan ini berbeda dari aksesibilitas. Stabilitas adalah mengenai apakah suatu properti sistem dapat diubah (misalnya diganti namanya, atau bahkan dihapus) di masa mendatang. Hal ini sangat penting karena OS Android menjadi modular. Dengan Treble, sistem, vendor, dan partisi produk dapat diperbarui secara independen satu sama lain. Dengan Mainline, beberapa bagian OS dimodulasi sebagai modul yang dapat diperbarui (dalam APEX atau APK).
Jika properti sistem digunakan di seluruh perangkat lunak yang dapat diupdate, misalnya di seluruh partisi sistem dan vendor, properti tersebut harus stabil. Namun, jika hanya digunakan dalam, misalnya, modul Mainline tertentu, Anda dapat mengubah nama, jenis, atau konteks propertinya, dan bahkan menghapusnya.
Ajukan pertanyaan berikut untuk menentukan stabilitas properti sistem:
- Apakah properti sistem ini dimaksudkan untuk dikonfigurasi oleh mitra (atau dikonfigurasi secara berbeda per perangkat)? Jika ya, itu harus stabil.
- Apakah properti sistem yang ditentukan AOSP ini dimaksudkan untuk ditulis atau dibaca dari kode (bukan proses) yang ada di partisi non-sistem seperti
vendor.img
atauproduct.img
? Jika ya, itu harus stabil. - Apakah properti sistem ini diakses di seluruh modul Mainline atau di seluruh modul Mainline dan bagian platform yang tidak dapat diperbarui? Jika ya, itu harus stabil.
Untuk properti sistem yang stabil, definisikan secara formal masing-masing sebagai API dan gunakan API tersebut untuk mengakses properti sistem, seperti yang dijelaskan pada Langkah 6 .
Langkah 5: Mengatur properti pada waktu pembuatan
Tetapkan properti pada waktu pembuatan dengan variabel makefile. Secara teknis, nilainya dimasukkan ke {partition}/build.prop
. Kemudian init
membaca {partition}/build.prop
untuk menyetel properti. Ada dua kumpulan variabel seperti itu: PRODUCT_{PARTITION}_PROPERTIES
dan TARGET_{PARTITION}_PROP
.
PRODUCT_{PARTITION}_PROPERTIES
berisi daftar nilai properti. Sintaksnya adalah {prop}={value}
atau {prop}?={value}
.
{prop}={value}
adalah penetapan normal yang memastikan bahwa {prop}
disetel ke {value}
; hanya satu penugasan seperti itu yang dimungkinkan untuk setiap properti.
{prop}?={value}
adalah tugas opsional; {prop}
disetel ke {value}
hanya jika tidak ada penetapan {prop}={value}
. Jika ada beberapa tugas opsional, yang pertama menang.
# 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
berisi daftar file, yang langsung dikirim ke {partition}/build.prop
. Setiap file berisi daftar pasangan {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
Untuk detail selengkapnya, lihat build/make/core/sysprop.mk
.
Langkah 6: Akses properti saat runtime
Tentu saja, properti dapat dibaca dan ditulis saat runtime.
Init skrip
File skrip init (biasanya file *.rc) dapat membaca properti dengan ${prop}
atau ${prop:-default}
, dapat mengatur tindakan yang berjalan setiap kali properti menjadi nilai tertentu, dan dapat menulis properti menggunakan setprop
memerintah.
# 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}
perintah shell getprop dan setprop
Anda dapat menggunakan perintah shell getprop
atau setprop
untuk membaca atau menulis properti. Untuk lebih jelasnya, aktifkan getprop --help
atau setprop --help
.
$ adb shell getprop ro.vndk.version
$
$ adb shell setprop security.perf_harden 0
Sysprop sebagai API untuk C++/Java/Rust
Dengan sysprop sebagai API, Anda dapat menentukan properti sistem dan menggunakan API yang dibuat secara otomatis yang konkret dan diketik. Menetapkan scope
dengan Public
juga membuat API yang dihasilkan tersedia untuk modul lintas batas, dan memastikan stabilitas API. Berikut ini contoh file .sysprop
, modul Android.bp
, dan kode C++, Java, dan Rust yang menggunakannya.
# 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);
Untuk informasi selengkapnya, lihat Menerapkan Properti Sistem sebagai API .
Fungsi dan metode properti tingkat rendah C/C++, Java dan Rust
Jika memungkinkan, gunakan Sysprop sebagai API meskipun fungsi C/C++ atau Rust tingkat rendah atau metode Java tingkat rendah tersedia untuk Anda.
libc
, libbase
, dan libcutils
menawarkan fungsi properti sistem C++. libc
memiliki API yang mendasarinya, sedangkan fungsi libbase
dan libcutils
adalah pembungkus. Jika memungkinkan, gunakan fungsi sysprop libbase
; ini yang paling nyaman, dan biner host dapat menggunakan fungsi libbase
. Untuk detail selengkapnya, lihat sys/system_properties.h
( libc
), android-base/properties.h
( libbase
), dan cutils/properties.h
( libcutils
).
Kelas android.os.SystemProperties
menawarkan metode properti sistem Java.
Modul rustutils::system_properties
menawarkan fungsi dan tipe properti sistem Rust.
Lampiran: Menambahkan properti khusus vendor
Mitra (termasuk Karyawan Google yang bekerja dalam konteks pengembangan Pixel) ingin menentukan properti sistem khusus perangkat keras (atau khusus perangkat). Properti khusus vendor adalah properti milik mitra yang unik untuk perangkat keras atau perangkatnya sendiri, bukan untuk platform. Karena ini bergantung pada perangkat keras atau perangkat, maka ini dimaksudkan untuk digunakan dalam partisi /vendor
atau /odm
.
Sejak Project Treble, properti platform dan properti vendor telah dipisahkan sepenuhnya agar tidak saling bertentangan. Berikut ini penjelasan cara mendefinisikan properti vendor, dan memberitahukan properti vendor mana yang harus selalu digunakan.
Namespace pada nama properti dan konteks
Semua properti vendor harus dimulai dengan salah satu awalan berikut untuk mencegah tabrakan antara properti tersebut dan properti partisi lain.
-
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.
Perhatikan bahwa ro.hardware.
diperbolehkan sebagai awalan, tetapi hanya untuk kompatibilitas. Jangan gunakan untuk properti normal.
Semua contoh berikut menggunakan salah satu awalan yang tercantum sebelumnya:
-
vendor.display.primary_red
-
persist.vendor.faceauth.use_disk_cache
-
ro.odm.hardware.platform
Semua konteks properti vendor harus dimulai dengan vendor_
. Ini juga untuk kompatibilitas. Berikut ini adalah contohnya:
-
vendor_radio_prop
. -
vendor_faceauth_prop
. -
vendor_usb_prop
.
Vendor bertanggung jawab untuk memberi nama dan memelihara properti, jadi ikuti format yang disarankan pada Langkah 2 , selain persyaratan ruang nama vendor.
Aturan SEPolicy dan property_contexts khusus vendor
Properti vendor dapat ditentukan oleh makro vendor_internal_prop
. Letakkan aturan khusus vendor yang Anda tetapkan di direktori BOARD_VENDOR_SEPOLICY_DIRS
. Misalnya, Anda mendefinisikan properti vendor faceauth di coral.
Di file BoardConfig.mk
(atau yang disertakan BoardConfig.mk
), masukkan yang berikut ini:
BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy
Di file device/google/coral-sepolicy/private/property.te
, masukkan yang berikut:
vendor_internal_prop(vendor_faceauth_prop)
Di file device/google/coral-sepolicy/private/property_contexts
, masukkan yang berikut:
vendor.faceauth.trace u:object_r:vendor_faceauth_prop:s0 exact bool
Keterbatasan properti vendor
Karena partisi sistem dan produk tidak dapat bergantung pada vendor, jangan pernah izinkan properti vendor diakses dari partisi system
, system-ext
, atau product
.
Lampiran: Mengganti nama properti yang ada
Jika Anda harus menghentikan penggunaan properti dan pindah ke properti baru, gunakan Sysprop sebagai API untuk mengganti nama properti yang ada. Hal ini menjaga kompatibilitas dengan menentukan nama lama dan nama properti baru. Secara khusus, Anda dapat mengatur nama lama berdasarkan bidang legacy_prop_name
di file .sysprop
. API yang dihasilkan mencoba membaca prop_name
, dan menggunakan legacy_prop_name
jika prop_name
tidak ada.
Misalnya, langkah-langkah berikut mengganti nama awesome_feature_foo_enabled
menjadi foo.awesome_feature.enabled
.
Dalam file foo.sysprop
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"
}
Dalam kode 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);
Perhatikan peringatan berikut:
Pertama, Anda tidak dapat mengubah jenis sysprop. Misalnya, Anda tidak dapat membuat prop
int
menjadi propstring
. Anda hanya dapat mengubah nama.Kedua, hanya API baca yang kembali ke nama lama. API tulis tidak mundur. Jika sysprop dapat ditulisi, Anda tidak dapat mengganti namanya.