Bu sayfada, mevcut sistem özelliklerini yeniden düzenlemeye yönelik yönergelerle birlikte Android'de sistem özelliklerini eklemek veya tanımlamak için standart bir yöntem sağlanmaktadır. Aksi belirtilmediği sürece, yeniden düzenleme yaparken bu yönergeleri kullandığınızdan emin olun.
1. Adım: Sistem özelliğini tanımlayın
Bir sistem özelliği eklediğinizde, özellik için bir ada karar verin ve bunu bir SELinux özelliği bağlamıyla ilişkilendirin. Uygun bir bağlam yoksa yeni bir bağlam oluşturun. Bu ad, mülke erişim sırasında kullanılır. Özellik bağlamı ise SELinux açısından erişilebilirliği kontrol etmek için kullanılır. Adlar herhangi bir dize olabilir ancak AOSP, net olması için yapılandırılmış bir biçim kullanmanızı önerir.
Mülk adı
snake_case büyük/küçük harf durumu ile şu biçimi kullanın:
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
prefix öğesi için "" (hariç), ro (yalnızca bir kez ayarlanan özellikler için) veya persist (yeniden başlatmalarda devam eden özellikler için) kullanın.
Uyarılar
ro öğesini yalnızca gelecekte prefix öğesinin yazılabilir olması gerekmediğinden emin olduğunuzda kullanın. ** ro ön ekini belirtmeyin.** Bunun yerine, prefix ürününün salt okunur (diğer bir deyişle, yalnızca init tarafından yazılabilir) olması için sepolicy'den yararlanın.
persist değerini yalnızca değerin yeniden başlatma işlemleri sırasında devam etmesi gerektiğinden ve tek seçeneğinizin sistem özelliklerini kullanmak olduğundan eminseniz kullanın.
Google, ro veya persist özelliklerine sahip sistem özelliklerini ayrıntılı bir şekilde inceler.
group terimi, ilgili mülkleri toplamak için kullanılır. Bu değerin, audio veya telephony ile benzer kullanımlara sahip bir alt sistem adı olması amaçlanmıştır. sys, system, dev, default veya config gibi belirsiz veya aşırı yüklenen terimler kullanmayın.
Sistem özelliklerine özel okuma veya yazma erişimi olan bir işlemin alan adı türünün kullanılması yaygın bir uygulamadır. Örneğin, vold işleminin yazma erişimine sahip olduğu sistem özelliklerinde grup adı olarak genellikle vold (işleme ilişkin alan türünün adı) kullanılır.
Gerekirse özellikleri daha fazla kategorilere ayırmak için subgroup ekleyin ancak bu öğeyi açıklayan muğlak veya aşırı yüklenmiş terimlerden kaçının. (Birden fazla subgroup
özelliğiniz de olabilir.)
Birçok grup adı zaten tanımlanmış. system/sepolicy/private/property_contexts dosyasını kontrol edin ve yeni adlar oluşturmak yerine, mümkün olduğunda mevcut grup adlarını kullanın. Aşağıdaki tabloda sık kullanılan grup adlarının örnekleri verilmiştir.
| Alan | Grup (ve alt grup) |
|---|---|
| bluetooth ile ilgili | bluetooth |
| çekirdek cmdline'daki sysprops | boot |
| bir derlemeyi tanımlayan sysprops | build
|
| telefon ile ilgili | telephony |
| ses hakkında | audio |
| grafikle ilgili | graphics |
| vold ile ilgili | vold |
Aşağıdaki, önceki regex örneğinde name ve type kullanımı tanımlanmaktadır.
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
name, bir grup içindeki bir sistem özelliğini tanımlar.type, sistem özelliğinin türünü veya amacını açıklayan isteğe bağlı bir öğedir. Örneğin, bir sysprop'uaudio.awesome_feature_enabledveya yalnızcaaudio.awesome_featureolarak adlandırmak yerine, sistem özelliği türünü ve amacını yansıtacak şekildeaudio.awesome_feature.enabledolarak yeniden adlandırın.
Türün ne olması gerektiğiyle ilgili belirli bir kural yoktur. Kullanım önerileri şunlardır:
enabled: Tür, bir özelliği açmak veya kapatmak için kullanılan bir boole sistem özelliğiyse kullanın.config: Amaç, sistem özelliğinin dinamik bir durumu temsil etmediğini netleştirmekse kullanın; önceden yapılandırılmış bir değeri (örneğin, salt okunur bir şeyi) temsil eder.List: Değeri liste olan bir sistem özelliğiyse kullanın.Timeoutmillis: ms cinsinden bir zaman aşımı değeri için bir sistem özelliğiyse kullanın.
Örnekler:
persist.radio.multisim.configdrm.service.enabled
Mülk bağlamı
Yeni SELinux özelliği bağlam şeması, daha ayrıntılı ayrıntı ve daha açıklayıcı adlar sağlar. AOSP, tesis 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ımlananla aynı anlama sahiptir. Örneğin vold_config_prop, bir tedarikçi firmaya ait yapılandırmalar olan ve vendor_init tarafından ayarlanması amaçlanan özellikleri belirtirken vold_status_prop veya yalnızca vold_prop, vold öğesinin mevcut durumunu gösterecek olan mülkleri belirtir.
Bir mülk bağlamını adlandırırken mülklerin genel kullanımını yansıtan adlar seçin. Özellikle aşağıdaki terim türlerini kullanmaktan kaçının:
sys,system,defaultgibi çok genel ve muğlak görünen terimler.- Erişilebilirliği doğrudan kodlayan terimler:
exported,apponly,ro,public,privategibi.
vold_config_prop - exported_vold_prop veya vold_vendor_writable_prop gibi ad kullanımlarını tercih edin.
Tür
Mülk türü, tabloda listelenen aşağıdakilerden biri olabilir.
| Tür | Tanım |
|---|---|
| Boole | True için true veya 1, yanlış için false veya 0 |
| Tam sayı | imzalı 64 bit tam sayı |
| İmzasız tam sayı | imzasız 64 bit tam sayı |
| Çift | çift duyarlıklı kayan nokta |
| Dize | geçerli herhangi bir UTF-8 dizesi |
| numaralandırma | değerleri, boşluk içermeyen herhangi bir geçerli UTF-8 dizesi olabilir |
| Yukarıdakilerin listesi | Ayırıcı olarak virgül (,) kullanılır[1, 2, 3] tam sayı listesi 1,2,3 olarak depolanır |
Dahili olarak tüm özellikler dize olarak depolanır. Türü, bir property_contexts dosyası olarak belirterek zorunlu kılabilirsiniz. Daha fazla bilgi için 3. Adım'daki property_contexts bölümüne bakın.
2. adım: Gerekli erişilebilirlik düzeylerini belirleyin
Bir mülkü tanımlayan dört yardımcı makro vardır.
| Erişilebilirlik türü | Anlamı |
|---|---|
system_internal_prop |
Yalnızca /system bölgesinde kullanılan tesisler |
system_restricted_prop |
/system dışında okunan ancak yazılmayan özellikler |
system_vendor_config_prop |
/system dışında okunan ve yalnızca vendor_init tarafından yazılan özellikler |
system_public_prop |
/system dışında okunan ve yazılan özellikler |
Sistem özelliklerine erişimin kapsamını mümkün olduğunca dar tutun. Geçmişte, geniş kapsamlı erişim, uygulamaların bozulmasına ve güvenlik açıklarına neden oluyordu. Kapsam oluştururken aşağıdaki soruları göz önünde bulundurun:
- Bu sistem özelliğinin kalıcı olması gerekiyor mu? (varsa, neden?)
- Bu mülke hangi işlemin okuma erişimi olmalıdır?
- Bu mülke hangi işlemin yazma erişimi olmalıdır?
Erişim için uygun bir kapsam belirlemek amacıyla önceki soruları ve aşağıdaki karar ağacını kullanın.
Şekil 1. Sistem özelliklerine erişim kapsamını belirlemek için karar ağacı
3. Adım: Sisteme/sepolicy'e ekleyin
Sysprop'a erişirken SELinux, işlemlerin erişilebilirliğini kontrol eder. Hangi erişilebilirlik düzeyinin gerekli olduğunu belirledikten sonra system/sepolicy altında mülk bağlamlarını ve süreçlerin ne okumasına veya yazmasına izin verildiğine ya da nelere izin verilmediğine ilişkin ek izin ver ve hiçbir zaman kurallarını tanımlayın.
Öncelikle, özellik bağlamını system/sepolicy/public/property.te dosyasında tanımlayın. Özellik, system-internal ise system/sepolicy/private/property.te dosyasında tanımlayın. Sistem mülkünüz için gereken erişilebilirliği sağlayansystem_[accessibility]_prop([context]) makrolardan 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. Erişim izni vermek için system/sepolicy/public/{domain}.te veya system/sepolicy/private/{domain}.te dosyasında set_prop ve get_prop makrolarını kullanın. Mümkün olduğunda private kullanın. public yalnızca set_prop veya get_prop makrosu çekirdek alan dışındaki alanları etkilemesi durumunda 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ü olarak, makronun kapsamındaki erişilebilirliği daha fazla azaltmak için bazı "izin ver" 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 tedarikçi firma işlemleri için gerekli değilse ve yalnızca belirli bir işlem grubu (vendor_init gibi) için gerekiyorsa okuma erişimine ihtiyaç duymayan tedarikçi firma 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;
Hiçbir zaman kuralı belirli bir alan adına bağlıysa system/sepolicy/private/{domain}.te dosyasına "hiçbir zaman izin verme" kuralları yerleştirin. Daha geniş kapsamlı "izin verme" kuralları için uygun olan her yerde aşağıdakiler gibi genel alan adları kullanın:
system/sepolicy/private/property.tesystem/sepolicy/private/coredomain.tesystem/sepolicy/private/domain.te
system/sepolicy/private/audio.te dosyasına aşağıdakileri yerleştirin:
neverallow {
domain -init -audio
} {audio_foo_prop audio_bar_prop}:property_service set;
system/sepolicy/private/property.te dosyasına aşağıdakileri yerleştirin:
neverallow {
domain -coredomain -vendor_init
} audio_prop:file no_rw_file_perms;
{domain -coredomain} değerinin tüm tedarikçi firma işlemlerini yakaladığını unutmayın. Yani {domain -coredomain -vendor_init}, "vendor_init haricindeki tüm tedarikçi firma işlemleri anlamına gelir.
Son olarak, bir sistem özelliğini mülk bağlamıyla ilişkilendirin. Bu, verilen erişim ve mülk bağlamlarına uygulanan "izin verme" kurallarının gerçek mülklere uygulanmasını sağlar. Bunu yapmak için property_contexts dosyasına bir giriş ekleyin. Bu dosya, sistem özellikleri ile özellik bağlamları arasındaki eşlemeyi açıklayan bir dosyadır. Bu dosyada tek bir mülk veya bir bağlama eşlenecek mülkler için bir önek belirtebilirsiniz.
Tek bir mülkü eşlemek için kullanılan söz dizimi şöyledir:
[property_name] u:object_r:[context_name]:s0 exact [type]
Ön eki eşlemek için kullanılan söz dizimi şöyledir:
[property_name_prefix] u:object_r:[context_name]:s0 prefix [type]
İsteğe bağlı olarak mülkün türünü belirtebilirsiniz. Bu tür aşağıdakilerden biri olabilir:
boolintuintdoubleenum [list of possible values...]string(Liste özellikleri içinstringöğesini kullanın.)
property ayarlanırken type zorunlu kılındığından her girişin mümkün olduğunda atanmış türüne sahip olduğundan emin olun. Aşağıdaki örnekte 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 bir giriş ile bir ön ek girişi çakıştığında tam giriş öncelikli olur. Daha fazla örnek için system/sepolicy/private/property_contexts bölümüne bakın.
4. adım: Kararlılık gereksinimlerini belirleme
Kararlılık, sistem özelliklerinin başka bir 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 kaldırılmayacağı) ile ilgilidir. Android işletim sistemi modüler hale geldiğinden bu özellikle önemlidir. Treble ile sistem, tedarikçi 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 halinde modüler hale getirilir (APEX veya APK'larda).
Bir sistem özelliği, güncellenebilir yazılım parçalarında (ör. sistem ve tedarikçi bölümlerinde) kullanılıyorsa kararlı olmalıdır. Bununla birlikte, ö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 ve hatta kaldırabilirsiniz.
Bir sistem özelliğinin kararlılığını belirlemek için aşağıdaki soruları sorun:
- Bu sistem özelliğinin iş ortakları tarafından mı yapılandırılması (veya her cihaz için farklı bir şekilde mi yapılandırılması) mı amaçlanıyor? Cevabınız evet ise sabit olması gerekir.
- AOSP tarafından tanımlanan bu sistem özelliği,
vendor.imgveyaproduct.imggibi sistem dışı bölümlerde bulunan koda (işleme değil) yazılması veya koddan okunması amaçlanıyor mu? Cevabınız evet ise sabit olması gerekir. - Bu sistem özelliğine Mainline modüllerinden veya bir Ana satır içi modülünden ve platformun güncellenemeyen bölümünden erişiliyor mu? Cevabınız evet ise sabit olması gerekir.
Kararlı sistem özellikleri için her birini resmi bir şekilde API olarak tanımlayın ve 6. Adım'da açıklandığı gibi API'yi kullanarak sistem özelliğine erişin.
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 öğesinde yerleşik olarak bulunur. Ardından init, özellikleri ayarlamak için {partition}/build.prop değerini okur. PRODUCT_{PARTITION}_PROPERTIES ve TARGET_{PARTITION}_PROP olmak üzere iki değişken grubu vardır.
PRODUCT_{PARTITION}_PROPERTIES, özellik değerlerinin listesini içerir. Söz dizimi {prop}={value} veya {prop}?={value} şeklindedir.
{prop}={value}, {prop} öğesinin {value} olarak ayarlanmasını sağlayan normal bir atamadır; tek bir mülk başına bu tür yalnızca bir atama mümkün olur.
{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
ilki kazanır.
# 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 öğesine gönderilen bir dosya listesi içerir. Her dosyada {prop}={value} çiftinden oluşan bir liste bulunur.
# 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 fazla bilgi için build/make/core/sysprop.mk sayfasını inceleyin.
6. Adım: Çalışma zamanında mülklere erişin
Özellikler çalışma zamanında okunabilir ve yazılabilir.
Başlatma komut dosyaları
Init komut dosyaları (genellikle *.rc dosyaları) bir özelliği ${prop} veya ${prop:-default} ile okuyabilir, bir özellik belirli bir değere dönüştüğünde çalıştırılacak 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 ayrıntı için getprop --help veya setprop --help yöntemini ç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'u kullandığınızda sistem özelliklerini tanımlayabilir, somut ve yazılı otomatik olarak oluşturulan API'yi kullanabilirsiniz. scope öğesinin Public ile ayarlanması, oluşturulan API'leri sınırlar arasındaki modüllerde de kullanılabilir hale getirir ve API kararlılığı sağlar. Burada .sysprop dosyası, Android.bp modülü, C++, Java ve Rust kodu kullanımlarına ilişkin 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 alt düzey mülk işlevleri ve yöntemleri
Mümkün olduğunda, alt düzey C/C++ veya Rust işlevleri ya da alt düzey Java yöntemleri mevcut olsa da Sysprop'u API olarak kullanın.
libc, libbase ve libcutils, C++ sistem özelliği işlevleri sunar. libc temel API'ye sahiptir, libbase ve libcutils işlevleri ise sarmalayıcıdır. Mümkünse libbase sysprop işlevlerini kullanın. Bunlar en uygundur ve ana makine ikili programları libbase işlevlerini kullanabilir. Daha fazla bilgi için sys/system_properties.h (libc), android-base/properties.h
(libbase) ve cutils/properties.h (libcutils) sayfalarını 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çi firmaya özgü özellikler ekleme
İş ortakları (Pixel geliştirme bağlamında çalışan Google çalışanları dahil) donanıma (veya cihaza özgü) sistem özelliklerini tanımlamak ister.
Tedarikçi firmaya özel mülkler, platforma değil, kendi donanımlarına veya cihazlarına özgü, iş ortağına ait mülklerdir. 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 bu yana, platform ve tedarikçi özellikleri çakışmaması için tamamen bölündü. Aşağıda tedarikçi firma özelliklerinin nasıl tanımlanacağı ve hangi tedarikçi firma özelliklerinin her zaman kullanılması gerektiği açıklanmaktadır.
Özellik ve bağlam adlarındaki ad alanı
Diğer bölümlerin özellikleri ile bunların arasında çakışma olmasını önlemek için tüm tedarikçi firma özellikleri, aşağıdaki ön eklerden 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 yalnızca uyumluluk amacıyla kullanılabilir.
Normal mülkler için kullanmayın.
Aşağıdaki örneklerin tümünde, yukarıda listelenen ön eklerden biri kullanılır:
vendor.display.primary_redpersist.vendor.faceauth.use_disk_cachero.odm.hardware.platform
Tüm tedarikçi firma özelliği bağlamları vendor_ ile başlamalıdır. Bu aynı zamanda uyumluluk
için de önemlidir. Aşağıda bazı örnekler verilmiştir:
vendor_radio_prop.vendor_faceauth_prop.vendor_usb_prop.
Mülkleri adlandırmak ve sürdürmek tedarikçinin sorumluluğundadır. Bu nedenle, tedarikçi ad alanı gereksinimlerine ek olarak 2. Adım'da önerilen biçimi uygulayın.
Tedarikçi firmaya özel SEPolicy kuralları ve property_contexts
Tedarikçi firma özellikleri, vendor_internal_prop makrosu ile tanımlanabilir. Tanımladığınız tedarikçi firmaya özel kuralları BOARD_VENDOR_SEPOLICY_DIRS dizinine ekleyin.
Örneğin, mercanda satıcı Faceauth özelliği tanımladığınızı varsayalım.
BoardConfig.mk dosyasına (veya herhangi bir BoardConfig.mk içerir) aşağıdakileri ekleyin:
BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy
device/google/coral-sepolicy/private/property.te dosyasına şunu ekleyin:
vendor_internal_prop(vendor_faceauth_prop)
device/google/coral-sepolicy/private/property_contexts dosyasına şunu ekleyin:
vendor.faceauth.trace u:object_r:vendor_faceauth_prop:s0 exact bool
Tedarikçi firma özelliklerinin sınırlamaları
Sistem ve ürün bölümleri tedarikçi firmaya bağlı olamayacağından tedarikçi firma özelliklerine hiçbir zaman system, system-ext veya product bölümlerinden erişilmesine izin vermeyin.
Ek: Mevcut mülkleri yeniden adlandırma
Bir mülkü kullanımdan kaldırıp yenisine taşımanız gerektiğinde mevcut mülklerinizi yeniden adlandırmak için API olarak Sysprop'u kullanın. Bu, hem eski adı hem de yeni mülk adını belirterek geriye dönük uyumluluğu korur. Özellikle, eski adı .sysprop dosyasındaki legacy_prop_name alanından ayarlayabilirsiniz. Oluşturulan API prop_name değerini okumaya çalışır ve prop_name yoksa legacy_prop_name değerini kullanır.
Örneğin, aşağıdaki adımlarda awesome_feature_foo_enabled alanını foo.awesome_feature.enabled olarak yeniden adlandırın.
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ı göz önünde bulundurun:
Öncelikle, sysprop'un türünü değiştiremezsiniz. Örneğin bir
intaksesuarınıstringaksesuarına dönüştüremezsiniz. Yalnızca adını değiştirebilirsiniz.İkinci olarak, yalnızca okuma API'si eski adın yerini alır. Write API geri dönmez. Sysprop yazılabilir bir sistemse yeniden adlandıramazsınız.