Tambahkan Properti Sistem

Halaman ini menyediakan metode kanonik untuk menambahkan atau mendefinisikan properti sistem di Android, dengan panduan untuk memfaktorkan ulang properti sistem yang ada. Pastikan Anda menggunakan pedoman saat melakukan refactor, kecuali jika Anda memiliki masalah kompatibilitas yang kuat yang menentukan sebaliknya.

Latar belakang

Properti sistem digunakan untuk berbagai tujuan karena mudah digunakan. Meskipun mirip dengan variabel global dalam bahasa pemrograman, tidak ada serangkaian persyaratan proses formal atau konvensi penamaan yang harus Anda ikuti saat membuatnya. Oleh karena itu, properti sistem mungkin sulit untuk dipahami dan dipelihara. Langkah-langkah di halaman ini menentukan properti sistem, dan menyediakan langkah-langkah untuk menambah dan memeliharanya.

Persiapan: Pertimbangkan alternatif

Tentukan apakah properti sistem benar-benar yang Anda inginkan, dan apakah itu satu-satunya pilihan Anda. Properti sistem adalah sumber daya seluruh sistem yang memberikan keuntungan tertentu. Mereka mudah digunakan dan properti non-dinamisnya memiliki overhead kinerja yang relatif rendah. Saat menggunakan properti sistem, Anda tidak perlu menggunakan komunikasi antarproses (IPC) bahkan jika properti sistem digunakan bersama di beberapa proses. Namun, mereka juga bisa berbahaya ketika disalahgunakan, mirip dengan variabel global. Penyalahgunaan properti sistem telah mengakibatkan masalah seperti aplikasi menjadi tidak dapat diakses oleh Pengguna, dan kerentanan keamanan diperkenalkan.

Pertimbangkan banyak alternatif untuk properti sistem yang mengikuti, untuk mengevaluasi apakah salah satunya dapat memberi Anda solusi yang Anda butuhkan.

Preferensi bersama

Untuk konfigurasi persisten yang bersifat lokal untuk aplikasi, gunakan antarmuka Shared Preferences , bukan properti sistem.

HAL

Ketika sumber kebenaran untuk konfigurasi berasal dari komponen perangkat keras pada perangkat, HAL harus memberikan informasi untuk komponen tersebut. Jangan konfigurasikan HAL untuk menulis properti sistem agar proses lain membacanya (atau sebaliknya). Sebagai gantinya, tentukan metode HAL baru untuk mengakses konfigurasi. Dengan kata lain, jangan gunakan properti sistem sebagai mekanisme komunikasi saluran samping untuk HAL.

Perhatikan bahwa Anda tidak memerlukan HAL baru untuk kasus penggunaan ini, karena itu adalah opsi yang mahal. Gunakan saran ini hanya jika Anda memiliki HAL yang ada untuk mengabstraksi komponen perangkat keras.

File konfigurasi

Jika data konfigurasi bersifat statis tetapi rumit (dengan kata lain, terstruktur), pertimbangkan untuk menggunakan XML atau format serupa lainnya untuk data konfigurasi. Pastikan skema file tetap stabil. Untuk file XML, Anda dapat menggunakan xsd_config untuk menjaga agar skema tetap stabil, dan untuk memanfaatkan parser XML yang dibuat secara otomatis.

layanan pengikat

Properti sistem sering digunakan untuk berbagi status dinamis subsistem dengan banyak proses. Status tersebut dapat diimplementasikan di dalam layanan pengikat (seperti bidang objek) dan proses lain dapat membaca (atau bahkan memodifikasi) status, menggunakan panggilan pengikat ke layanan. Ini adalah solusi yang lebih disukai, karena menjadikan status sebagai properti sistem dan memberikan akses langsung ke sana memerlukan proses yang mirip dengan yang ini:

1. Lakukan pemeriksaan kewarasan di negara bagian.
2. Lakukan postprocessing pada status untuk membuatnya dapat dikonsumsi.
3. Lakukan fungsi kontrol akses yang halus.
4. Jaga agar negara tetap terstruktur.

Menyelesaikan proses ini dengan sukses tidak mungkin, atau paling banter, sangat sulit ketika Anda menerapkan status sebagai properti sistem. Oleh karena itu gunakan opsi layanan pengikat ketika pembaca negara sudah memiliki akses ke layanan pengikat.

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 yang baru. Nama tersebut digunakan saat mengakses properti; konteks properti digunakan untuk mengontrol aksesibilitas dalam hal SELinux. Nama dapat berupa string apa pun, tetapi AOSP menyarankan Anda mengikuti format terstruktur untuk memperjelasnya.

Nama properti

Gunakan format ini dengan casing snake_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 untuk dapat ditulis di masa mendatang. ** Jangan tentukan awalan ro .** Sebagai gantinya, andalkan sepolicy untuk membuat prefix hanya-baca (dengan kata lain, hanya dapat ditulis oleh init ).

Gunakan persist hanya jika Anda yakin bahwa nilainya harus dipertahankan di seluruh reboot, dan bahwa 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 untuk menjadi nama subsistem yang mirip dengan penggunaan audio atau telephony . Jangan gunakan istilah yang ambigu atau kelebihan beban seperti sys , system , dev , default , atau config .

Ini adalah praktik umum untuk menggunakan nama jenis domain dari proses yang memiliki akses baca atau tulis eksklusif ke properti sistem. Misalnya, untuk properti sistem tempat proses vold memiliki akses tulis, biasanya menggunakan vold (nama jenis domain untuk proses) sebagai nama grup.

Jika perlu, tambahkan subgroup untuk mengkategorikan properti lebih lanjut, tetapi 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.

Berikut ini mendefinisikan penggunaan name dan type dalam contoh regex sebelumnya.

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

• name mengidentifikasi properti sistem dalam grup.

• type adalah elemen opsional yang mengklarifikasi tipe atau maksud dari properti sistem. Misalnya, alih-alih memberi nama sysprop sebagai audio.awesome_feature_enabled atau hanya audio.awesome_feature , ganti namanya menjadi audio.awesome_feature.enabled untuk mencerminkan tipe dan maksud properti sistem.

Tidak ada aturan khusus tentang apa jenisnya; ini adalah rekomendasi penggunaan:

• enabled : Gunakan jika jenisnya adalah properti sistem boolean yang digunakan untuk mengaktifkan atau menonaktifkan fitur.
• config : Gunakan jika tujuannya adalah untuk mengklarifikasi bahwa properti sistem tidak mewakili keadaan dinamis sistem; itu mewakili nilai yang telah dikonfigurasikan sebelumnya (misalnya, hal hanya-baca).
• List : Gunakan jika itu adalah properti sistem yang nilainya adalah 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 baik dan nama yang lebih deskriptif. Mirip dengan apa 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 regex sampel 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 akan mengekspos status vold saat ini.

Saat menamai konteks properti, pilih nama yang mencerminkan penggunaan umum properti. 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.

Secara internal, semua properti disimpan sebagai string. Anda dapat menerapkan tipe tersebut 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.

Lingkup akses ke properti sistem sesempit mungkin. Di masa lalu, akses yang luas telah mengakibatkan kerusakan aplikasi dan kerentanan keamanan. Pertimbangkan pertanyaan-pertanyaan berikut saat pelingkupan:

• Apakah properti sistem ini perlu dipertahankan? (jika demikian, mengapa?)
• Proses mana 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 sesuai.

Gambar 1. Pohon keputusan untuk menentukan cakupan akses ke properti sistem

Langkah 3: Menambahkannya ke sistem/kebijakan

Saat mengakses sysprop, SELinux mengontrol aksesibilitas proses. Setelah Anda menentukan tingkat aksesibilitas yang diperlukan, tentukan konteks properti di bawah system/sepolicy , bersama dengan aturan allow dan neverallow tambahan tentang proses apa yang (dan tidak) diizinkan untuk membaca atau menulis.

Pertama, tentukan konteks properti di file system/sepolicy/public/property.te . Jika properti adalah sistem-internal, tentukan dalam file system/sepolicy/private/property.te . Gunakan salah satu system_[accessibility]_prop([context]) yang menyediakan aksesibilitas yang diperlukan dari 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, berikan 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, dalam file system/sepolicy/public/domain.te :

get_prop(domain, audio_bar_prop)

Ketiga, tambahkan beberapa aturan neverallow untuk lebih 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 ), melarang 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 ke domain tertentu. Untuk aturan neverallow yang lebih luas, gunakan domain umum seperti ini jika sesuai:

• 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. Ini memastikan bahwa akses yang diberikan dan aturan neverallow yang diterapkan ke konteks properti diterapkan ke 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 satu properti, 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 dapat secara opsional menentukan tipe properti, yang dapat berupa salah satu dari berikut ini:

• bool
• int
• uint
• double
• enum [list of possible values...]
• string (Gunakan string untuk properti daftar.)

Pastikan bahwa setiap entri memiliki tipe yang ditentukan jika 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

Ketika entri yang tepat dan entri awalan bentrok, entri yang tepat akan didahulukan. Untuk contoh lainnya, 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 tentang apakah properti sistem dapat diubah atau tidak (misalnya diganti namanya, atau bahkan dihapus) di masa mendatang. 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 dari OS dimodulasi sebagai modul yang dapat diperbarui (dalam APEX atau APK).

Jika properti sistem digunakan di seluruh perangkat lunak yang dapat diperbarui, misalnya di seluruh sistem dan partisi vendor, properti itu 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 atau product.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 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, nilai dimasukkan ke {partition}/build.prop . Kemudian init membaca {partition}/build.prop untuk mengatur properti. Ada dua set variabel tersebut: PRODUCT_{PARTITION}_PROPERTIES dan TARGET_{PARTITION}_PROP .

PRODUCT_{PARTITION}_PROPERTIES berisi daftar nilai properti. Sintaksnya adalah {prop}={value} atau {prop}?={value} .

{prop}={value} adalah tugas normal yang memastikan bahwa {prop} disetel ke {value} ; hanya satu penugasan seperti itu yang dimungkinkan per satu 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 dipancarkan 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 lebih lanjut, 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}

getprop dan setprop perintah shell

Anda dapat menggunakan perintah shell getprop atau setprop , masing-masing, untuk membaca atau menulis properti. Untuk detail lebih lanjut, 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

Dengan sysprop sebagai API, Anda dapat menentukan properti sistem dan menggunakan API yang dibuat secara otomatis yang konkret dan diketik. Menyetel 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 , serta kode C++ dan Java 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",
}

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

Untuk informasi selengkapnya, lihat Menerapkan Properti Sistem sebagai API .

Fungsi dan metode properti tingkat rendah C/C++ dan Java

Gunakan Sysprop sebagai API, meskipun fungsi C/C++ tingkat rendah atau metode Java tingkat rendah tersedia untuk Anda. Lebih suka penggunaan Sysprop daripada mereka kapan pun Anda bisa.

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 libbase sysprop; mereka yang paling nyaman, dan binari 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.

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 perangkat mereka sendiri, bukan untuk platform. Karena ini bergantung pada perangkat keras atau perangkat, mereka dimaksudkan untuk digunakan di dalam partisi /vendor atau /odm .

Sejak Project Treble, properti platform dan properti vendor telah dipisah sepenuhnya agar tidak saling bertentangan. Berikut ini menjelaskan cara menentukan properti vendor, dan memberi tahu properti vendor mana yang harus selalu digunakan.

Namespace pada properti dan nama konteks

Semua properti vendor harus dimulai dengan salah satu dari awalan berikut untuk mencegah tabrakan antara mereka dan properti dari 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 menggunakannya untuk properti normal.

Semua contoh berikut menggunakan salah satu dari awalan yang terdaftar 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 di Langkah 2 , selain persyaratan ruang nama vendor.

Aturan SEPolicy dan property_contexts khusus vendor

Mirip dengan properti platform, properti vendor dapat ditentukan oleh salah satu makro berikut.

Letakkan aturan khusus vendor yang Anda tentukan di direktori BOARD_VENDOR_SEPOLICY_DIRS . Misalnya, Anda mendefinisikan properti faceauth vendor di coral.

Di file BoardConfig.mk (atau di semua BoardConfig.mk termasuk), masukkan yang berikut ini:

BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy

Di file device/google/coral-sepolicy/private/property.te , masukkan yang berikut ini:

vendor_internal_prop(vendor_faceauth_prop)

Di file device/google/coral-sepolicy/private/property_contexts , masukkan yang berikut ini:

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

Batasan properti vendor

Karena partisi sistem dan produk tidak dapat bergantung pada vendor, jangan pernah izinkan properti vendor diakses dari system , system-ext , atau partisi product .

Lampiran: Mengganti nama properti yang ada

Saat Anda harus menghentikan properti dan pindah ke properti baru, gunakan Sysprop sebagai API untuk mengganti nama properti yang sudah ada. Ini mempertahankan kompatibilitas mundur dengan menentukan nama lama dan nama properti baru. Secara khusus, Anda dapat mengatur nama warisan dengan 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 mengubah nama awesome_feature_foo_enabled menjadi foo.awesome_feature.enabled .

Dalam file foo.sysprop (dalam 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"
}

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 int prop menjadi string prop. Anda hanya dapat mengubah nama.

• Kedua, hanya API baca yang kembali ke nama lama. API tulis tidak mundur. Jika sysprop adalah yang dapat ditulis, Anda tidak dapat mengganti namanya.