Bu sayfa, Android'de sistem özelliklerini eklemek veya tanımlamak için standart bir yöntem sağlar ve mevcut sistem özelliklerini yeniden düzenlemeye yönelik yönergeler sunar. Aksini gerektiren güçlü bir uyumluluk sorununuz olmadığı sürece, yeniden düzenleme yaparken yönergeleri kullandığınızdan emin olun.
Adım 1: Sistem özelliğini tanımlama
Bir sistem özelliği eklediğinizde, özellik için bir ad belirleyin ve onu bir SELinux özellik bağlamıyla ilişkilendirin. Mevcut uygun bir bağlam yoksa yeni bir tane oluşturun. Bu ad, mülke erişilirken kullanılır; özellik bağlamı SELinux açısından erişilebilirliği kontrol etmek için kullanılır. Adlar herhangi bir dize olabilir ancak AOSP, bunları netleştirmek için yapılandırılmış bir format izlemenizi önerir.
Mülkiyet adı
Snake_case büyük/küçük harfle bu formatı kullanın:
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
Öğe prefix
için "" (atlanmış), ro
(yalnızca bir kez ayarlanan özellikler için) veya persist
(yeniden başlatmalarda kalıcı olan özellikler için) kullanın.
Uyarılar
ro
yalnızca gelecekte yazılabilir olmak için prefix
ihtiyacınız olmadığından emin olduğunuzda kullanın. ** ro
önekini belirtmeyin.** Bunun yerine, prefix
okunur (başka bir deyişle yalnızca init
tarafından yazılabilir) yapmak için sepolicy'ye güvenin.
persist
yalnızca değerin yeniden başlatmalarda kalıcı olması gerektiğinden ve sistem özelliklerini kullanmanın tek seçeneğiniz olduğundan emin olduğunuzda kullanın. (Ayrıntılar için Hazırlık bölümüne bakın.)
Google, ro
veya persist
özelliklerine sahip sistem özelliklerini sıkı bir şekilde inceler.
group
terimi ilgili özellikleri bir araya getirmek için kullanılır. Kullanım açısından audio
veya telephony
benzer bir alt sistem adı olması amaçlanmıştır. sys
, system
, dev
, default
veya config
gibi belirsiz veya aşırı yüklenmiş terimler kullanmayın .
Sistem özelliklerine özel okuma veya yazma erişimi olan bir işlemin etki alanı türünün adını kullanmak yaygın bir uygulamadır. Örneğin, vold
işleminin yazma erişimine sahip olduğu sistem özellikleri için, grup adı olarak vold
(işlemin etki alanı türünün adı) kullanılması yaygındır.
Gerekirse özellikleri daha fazla kategorize etmek için subgroup
ekleyin, ancak bu öğeyi tanımlamak için belirsiz veya aşırı yüklenmiş terimlerden kaçının. (Ayrıca birden fazla subgroup
da olabilir.)
Birçok grup adı zaten tanımlanmıştır. system/sepolicy/private/property_contexts
dosyasını kontrol edin ve mümkün olduğunda yeni grup adları oluşturmak yerine mevcut grup adlarını kullanın. Aşağıdaki tabloda sık kullanılan grup adlarının örnekleri verilmektedir.
İhtisas | Grup (ve alt grup) |
---|---|
bluetooth ile ilgili | bluetooth |
çekirdek cmdline'ından sysprops | boot |
bir yapıyı tanımlayan sysprop'lar | build |
telefonla ilgili | telephony |
ses ile ilgili | audio |
grafiklerle ilgili | graphics |
vold ile ilgili | vold |
Aşağıda önceki regex örneğinde name
ve type
kullanımı tanımlanmaktadır.
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
name
bir grup içindeki 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 özellik türünü ve amacını yansıtacak şekilde onuaudio.awesome_feature.enabled
olarak yeniden adlandırın.
Türün ne olması gerektiğine dair belirli bir kural yoktur; bunlar kullanım önerileridir:
-
enabled
: Tür, bir özelliği açmak veya kapatmak için kullanılan bir boole sistem özelliği ise kullanın. -
config
: Amaç, sistem özelliğinin sistemin dinamik bir durumunu temsil etmediğini açıklamaksa kullanın; önceden yapılandırılmış bir değeri temsil eder (örneğin, salt okunur bir şey). -
List
: Değeri liste olan bir sistem özelliği ise kullanın. -
Timeoutmillis
: MS cinsinden bir zaman aşımı değeri için bir sistem özelliği ise kullanın.
Örnekler:
-
persist.radio.multisim.config
-
drm.service.enabled
Mülkiyet İçeriği
Yeni SELinux özellik bağlam şeması, daha ayrıntılı ayrıntı düzeyine ve daha açıklayıcı adlara olanak tanır. Özellik adları için kullanılanlara benzer şekilde AOSP aşağıdaki formatı önerir:
{group}[_{subgroup}]*_prop
Terimler şu şekilde tanımlanır:
group
ve subgroup
önceki örnek normal ifade için tanımlananla aynı anlama sahiptir. Örneğin vold_config_prop
, bir satıcının konfigürasyonları olan ve vendor_init
tarafından ayarlanması amaçlanan özellikleri belirtirken, vold_status_prop
veya sadece vold_prop
, vold
mevcut durumunu ortaya çıkaracak özellikleri belirtir.
Bir özellik bağlamını adlandırırken, özelliklerin genel kullanımını yansıtan adları seçin. Özellikle aşağıdaki terim türlerinden kaçının:
-
sys
,system
,default
gibi çok genel ve belirsiz görünen terimler. - Erişilebilirliği doğrudan kodlayan terimler:
exported
,apponly
,ro
,public
,private
gibi.
vold_config_prop
gibi ad kullanımlarını exported_vold_prop
veya vold_vendor_writable_prop
vb. gibi ad kullanımlarını tercih edin.
Tip
Bir mülk türü, tabloda listelenen aşağıdakilerden biri olabilir.
Tip | Tanım |
---|---|
Boolean | true veya doğru için 1 , false için veya yanlış için 0 |
Tamsayı | imzalı 64 bit tamsayı |
İşaretsiz tam sayı | işaretsiz 64 bit tamsayı |
Çift | çift duyarlıklı kayan nokta |
Sicim | geçerli herhangi bir UTF-8 dizesi |
Sıralama | değerler boşluk içermeyen herhangi bir geçerli UTF-8 dizesi olabilir |
Yukarıdakilerin listesi | Sınırlayıcı olarak virgül ( , ) kullanılırTamsayı listesi [1, 2, 3] 1,2,3 olarak saklanır |
Dahili olarak tüm özellikler dizeler olarak saklanır. Türü bir property_contexts
dosyası olarak belirterek zorlayabilirsiniz. Daha fazla bilgi için 3. Adımdaki property_contexts
bakın.
2. Adım: Gerekli erişilebilirlik düzeylerini belirleme
Bir özelliği tanımlayan dört yardımcı makro vardır.
Erişilebilirlik türü | Anlam |
---|---|
system_internal_prop | Yalnızca /system kullanılan özellikler |
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şimi mümkün olduğunca dar bir şekilde kapsayın. Geçmişte geniş erişim, uygulamanın bozulmasına ve güvenlik açıklarına neden oluyordu. Kapsam belirlerken aşağıdaki soruları göz önünde bulundurun:
- Bu sistem özelliğinin sürdürülmesi gerekiyor mu? (Öyleyse neden?)
- Bu özelliğe hangi sürecin okuma erişimi olmalıdır?
- Bu özelliğe hangi sürecin yazma erişimi olmalıdır?
Uygun erişim kapsamını belirlemek için önceki soruları ve aşağıdaki karar ağacını araç olarak kullanın.
Şekil 1. Sistem özelliklerine erişim kapsamını belirlemek için karar ağacı
Adım 3: Sisteme/sepolicy'ye ekleme
Sysprop'a erişirken SELinux süreçlerin erişilebilirliğini kontrol eder. Hangi düzeyde erişilebilirliğin gerekli olduğunu belirledikten sonra, system/sepolicy
altında özellik bağlamlarını tanımlayın ve işlemlerin neleri okumasına veya yazmasına izin verildiğine (ve verilmediğine) ilişkin ek izin ver ve asla izin verme kurallarını tanımlayın.
Öncelikle system/sepolicy/public/property.te
dosyasında özellik içeriğini tanımlayın. Özellik sistem içi ise bunu system/sepolicy/private/property.te
dosyasında tanımlayın. Sistem mülkünüzün gerektirdiği erişilebilirliği sağlayan system_[accessibility]_prop([context])
makrolarından birini kullanın. Bu system/sepolicy/public/property.te
dosyası için bir örnektir:
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, özellik 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
makrosunun çekirdek alan dışındaki herhangi bir alanı etkilemesi durumunda uygundur.
Örnek, system/sepolicy/private/audio.te
dosyasında:
set_prop(audio, audio_foo_prop)
set_prop(audio, audio_bar_prop)
Örnek, system/sepolicy/public/domain.te
dosyasında:
get_prop(domain, audio_bar_prop)
Üçüncü olarak, makronun kapsadığı erişilebilirliği daha da azaltmak için bazı asla izin verme kuralları ekleyin. Örneğin, sistem özelliklerinizin satıcı işlemleri tarafından okunması gerektiğinden system_restricted_prop
kullandığınızı varsayalım. Okuma erişimi tüm satıcı işlemleri için gerekli değilse ve yalnızca belirli bir dizi işlem ( vendor_init
gibi) için gerekliyse, okuma erişimine ihtiyaç duymayan satıcı işlemlerini yasaklayın.
Yazma ve okuma erişimini kısıtlamak için aşağıdaki sözdizimini kullanın:
Yazma erişimini kısıtlamak için:
neverallow [domain] [context]:property_service set;
Okuma erişimini kısıtlamak için:
neverallow [domain] [context]:file no_rw_file_perms;
Neverallow kuralı belirli bir alana bağlıysa, Neverallow kurallarını system/sepolicy/private/{domain}.te
dosyasına yerleştirin. Daha geniş asla izin verme kuralları için, uygun olan yerlerde aşağıdakiler gibi genel alanları kullanın:
-
system/sepolicy/private/property.te
-
system/sepolicy/private/coredomain.te
-
system/sepolicy/private/domain.te
system/sepolicy/private/audio.te
dosyası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}
alanının tüm satıcı süreçlerini yakaladığını unutmayın. Yani {domain -coredomain -vendor_init}
" vendor_init
dışındaki tüm satıcı işlemleri" anlamına gelir.
Son olarak, bir sistem özelliğini özellik bağlamıyla ilişkilendirin. Bu, verilen erişimin ve mülk bağlamlarına uygulanan asla izin vermeme kurallarının gerçek mülklere uygulanmasını sağlar. Bunu yapmak için, sistem özellikleri ile özellik bağlamları arasındaki eşlemeyi açıklayan bir dosya olan property_contexts
dosyasına bir giriş ekleyin. Bu dosyada, tek bir özelliği veya bir bağlama eşlenecek özellikler için bir önek belirtebilirsiniz.
Bu, tek bir özelliği eşlemeye yönelik söz dizimidir:
[property_name] u:object_r:[context_name]:s0 exact [type]
Bir öneki eşlemek için kullanılan sözdizimi şöyledir:
[property_name_prefix] u:object_r:[context_name]:s0 prefix [type]
İsteğe bağlı olarak aşağıdakilerden biri olabilecek özelliğin türünü belirtebilirsiniz:
-
bool
-
int
-
uint
-
double
-
enum [list of possible values...]
-
string
(Liste özellikleri içinstring
kullanın.)
property
ayarlanırken tür zorunlu kılındığından, mümkün olduğunca her girişin kendi belirlenmiş type
sahip olduğundan emin olun. Aşağıdaki örnek bir eşlemenin nasıl yazılacağını gösterir:
# 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 önek girişi çakıştığında, tam giriş önceliklidir. Daha fazla örnek için bkz. system/sepolicy/private/property_contexts
.
Adım 4: Stabilite gereksinimlerinin belirlenmesi
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ılamayacağı) ile ilgilidir. Android işletim sistemi modüler hale geldiğinden bu özellikle önemlidir. Treble ile sistem, satıcı ve ürün bölümleri birbirinden bağımsız olarak güncellenebilir. Mainline ile işletim sisteminin bazı bölümleri güncellenebilir modüller halinde (APEX'lerde veya APK'larda) modüler hale getirilmiştir.
Bir sistem özelliği, örneğin sistem ve satıcı bölümleri gibi güncelleştirilebilir yazılım parçaları arasında kullanılacaksa kararlı olmalıdır. Ancak 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 onu 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 cihaz başına farklı şekilde yapılandırılması) amaçlanıyor? Eğer öyleyse, kararlı olması gerekir.
- Bu AOSP tanımlı sistem özelliğinin,
vendor.img
veyaproduct.img
gibi sistem dışı bölümlerde bulunan koda (işlem değil) yazılması veya koddan okunması mı amaçlanıyor? Eğer öyleyse, kararlı olması gerekir. - Bu sistem özelliğine Mainline modülleri üzerinden mi yoksa bir Mainline modülü ve platformun güncellenemeyen kısmı üzerinden mi erişiliyor? Eğer öyleyse, kararlı olması gerekir.
Kararlı sistem özellikleri için, her birini resmi olarak bir API olarak tanımlayın ve 6. Adımda açıklandığı gibi sistem özelliğine erişmek için API'yi kullanın.
5. Adım: Derleme sırasında özellikleri ayarlama
Özellikleri derleme sırasında makefile değişkenleriyle ayarlayın. Teknik olarak değerler {partition}/build.prop
olarak işlenir. Daha sonra init
özellikleri ayarlamak için {partition}/build.prop
okur. Bu tür değişkenlerin iki kümesi vardır: PRODUCT_{PARTITION}_PROPERTIES
ve TARGET_{PARTITION}_PROP
.
PRODUCT_{PARTITION}_PROPERTIES
özellik değerlerinin bir listesini içerir. Sözdizimi {prop}={value}
veya {prop}?={value}
şeklindedir.
{prop}={value}
{prop}
öğesinin {value}
olarak ayarlanmasını sağlayan normal bir atamadır; tek bir mülk için bu türden yalnızca bir atama mümkündür.
{prop}?={value}
isteğe bağlı bir atamadır; {prop}
yalnızca herhangi bir {prop}={value}
ataması olmadığında {value}
} olarak ayarlanır. Birden fazla isteğe bağlı atama mevcutsa 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
gönderilen dosyaların bir listesini içerir. Her dosya, {prop}={value}
çiftlerinin bir listesini içerir.
# example.prop
ro.cp_system_other_odex=0
ro.adb.secure=0
ro.control_privapp_permissions=disable
# emits example.prop to system/build.prop
TARGET_SYSTEM_PROP += example.prop
Daha fazla ayrıntı için build/make/core/sysprop.mk
bakın.
6. Adım: Çalışma zamanında özelliklere erişin
Tabii ki, özellikler çalışma zamanında okunabilir ve yazılabilir.
Komut dosyalarını başlat
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ışacak bir eylem ayarlayabilir ve setprop
kullanarak özellikleri yazabilir emretmek.
# 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
çağırın.
$ adb shell getprop ro.vndk.version
$
$ adb shell setprop security.perf_harden 0
C++/Java/Rust için API olarak Sysprop
API olarak sysprop ile sistem özelliklerini tanımlayabilir ve otomatik olarak oluşturulan, somut ve yazılı API'yi kullanabilirsiniz. scope
Public
ile ayarlanması, oluşturulan API'lerin sınırlar ötesindeki modüller tarafından da kullanılabilir olmasını sağlar ve API istikrarını sağlar. Burada bir .sysprop
dosyası, bir Android.bp
modülü ve bunları kullanan C++, Java ve Rust kodunun bir örneği bulunmaktadır.
# 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 bkz. Sistem Özelliklerini API'ler Olarak Uygulama .
C/C++, Java ve Rust düşük düzeyli özellik işlevleri ve yöntemleri
Mümkün olduğunda, düşük seviyeli C/C++ veya Rust işlevleri veya düşük seviyeli Java yöntemleri kullanımınıza açık olsa bile Sysprop'u API olarak kullanın.
libc
, libbase
ve libcutils
C++ sistem özelliği işlevlerini sunar. libc
temel API'ye sahipken, libbase
ve libcutils
işlevleri sarmalayıcılardır. Mümkünse libbase
sysprop işlevlerini kullanın; bunlar en kullanışlı olanlardır ve ana bilgisayar ikili dosyaları libbase
işlevlerini kullanabilir. Daha fazla ayrıntı için bkz sys/system_properties.h
( libc
), android-base/properties.h
( libbase
) ve cutils/properties.h
( libcutils
).
android.os.SystemProperties
sınıfı, Java sistem özelliği yöntemlerini sunar.
rustutils::system_properties
modülü, Rust sistem özelliği işlevlerini ve türlerini sunar.
Ek: Satıcıya özgü özellikler ekleme
İş ortakları (Pixel geliştirme bağlamında çalışan Google çalışanları dahil) donanıma özel (veya cihaza özel) sistem özelliklerini tanımlamak istiyor. Satıcıya özel mülkler, platforma değil, kendi donanımlarına veya cihazlarına özel olan, iş ortaklarının sahip olduğu mülklerdir. Bunlar donanıma veya cihaza bağlı olduğundan, /vendor
veya /odm
bölümleri içinde kullanılmaları amaçlanmıştır.
Project Treble'dan bu yana platform özellikleri ve satıcı özellikleri, çakışmalarını önlemek için tamamen bölünmüş durumda. Aşağıda satıcı özelliklerinin nasıl tanımlanacağı açıklanmakta ve hangi satıcı özelliklerinin her zaman kullanılması gerektiği anlatılmaktadır.
Özellik ve bağlam adlarındaki ad alanı
Tüm satıcı özellikleri, diğer bölümlerin özellikleriyle çakışmayı önlemek için aşağıdaki öneklerden biriyle başlamalıdır.
-
ctl.odm.
-
ctl.vendor.
-
ctl.start$odm.
-
ctl.start$vendor.
-
ctl.stop$odm.
-
ctl.stop$vendor.
-
init.svc.odm.
-
init.svc.vendor.
-
ro.odm.
-
ro.vendor.
-
odm.
-
persist.odm.
-
persist.vendor.
-
vendor.
ro.hardware.
önek olarak kullanılmasına izin verilir, ancak yalnızca uyumluluk amacıyla. Normal özellikler için kullanmayın.
Aşağıdaki örneklerin tümü, yukarıda listelenen öneklerden birini kullanır:
-
vendor.display.primary_red
-
persist.vendor.faceauth.use_disk_cache
-
ro.odm.hardware.platform
Tüm satıcı özelliği bağlamları vendor_
ile başlamalıdır. Bu aynı zamanda uyumluluk içindir. Aşağıdakiler örneklerdir:
-
vendor_radio_prop
. -
vendor_faceauth_prop
. -
vendor_usb_prop
.
Özellikleri adlandırmak ve sürdürmek satıcının sorumluluğunda olduğundan, satıcı ad alanı gereksinimlerine ek olarak 2. Adımda önerilen formatı izleyin.
Satıcıya özel SEPolicy kuralları ve property_contexts
Satıcı özellikleri vendor_internal_prop
makrosu ile tanımlanabilir. Tanımladığınız satıcıya özel kuralları BOARD_VENDOR_SEPOLICY_DIRS
dizinine koyun. Örneğin, mercanda bir satıcı faceauth özelliği tanımladığınızı varsayalım.
BoardConfig.mk
dosyasına (veya BoardConfig.mk
içerdiği herhangi bir dosyaya) aşağıdakileri ekleyin:
BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy
device/google/coral-sepolicy/private/property.te
dosyasına aşağıdakileri koyun:
vendor_internal_prop(vendor_faceauth_prop)
device/google/coral-sepolicy/private/property_contexts
dosyasına aşağıdakini koyun:
vendor.faceauth.trace u:object_r:vendor_faceauth_prop:s0 exact bool
Satıcı özelliklerinin sınırlamaları
Sistem ve ürün bölümleri satıcıya bağlı olamayacağından, satıcı özelliklerine hiçbir zaman system
, system-ext
veya product
bölümlerinden erişilmesine izin vermeyin.
Ek: Mevcut özellikleri yeniden adlandırma
Bir özelliği kullanımdan kaldırmanız ve yeni bir özelliğe taşımanız gerektiğinde, mevcut özelliklerinizi yeniden adlandırmak için Sysprop'u API olarak kullanın. Bu, hem eski adı hem de yeni özellik adını belirterek geriye dönük uyumluluğu korur. Özellikle, eski adı .sysprop
dosyasındaki legacy_prop_name
alanına göre ayarlayabilirsiniz. Oluşturulan API, prop_name
okumaya çalışır ve prop_name
mevcut değilse, legacy_prop_name
kullanır.
Örneğin, aşağıdaki adımlarda awesome_feature_foo_enabled
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ılara dikkat edin:
Öncelikle sysprop'un türünü değiştiremezsiniz. Örneğin,
int
prop'ıstring
prop'a dönüştüremezsiniz. Yalnızca adı değiştirebilirsiniz.İkincisi, yalnızca okuma API'si eski isme geri döner. Yazma API'si geri çekilmez. Sysprop yazılabilir bir şeyse, onu yeniden adlandıramazsınız.