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_enabled
veya yalnızcaaudio.awesome_feature
olarak adlandırmak yerine, sistem özelliği türünü ve amacını yansıtacak şekildeaudio.awesome_feature.enabled
olarak 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.config
drm.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
,default
gibi çok genel ve muğlak görünen terimler.- Erişilebilirliği doğrudan kodlayan terimler:
exported
,apponly
,ro
,public
,private
gibi.
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.te
system/sepolicy/private/coredomain.te
system/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:
bool
int
uint
double
enum [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.img
veyaproduct.img
gibi 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_red
persist.vendor.faceauth.use_disk_cache
ro.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
int
aksesuarınıstring
aksesuarı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.