Bu sayfada, Android'de sistem özellikleri eklemek veya tanımlamak için standart bir yöntem ve mevcut sistem özelliklerini yeniden düzenlemeyle ilgili yönergeler sunulmaktadı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
Sistem özelliği eklerken mülkün adına karar verin ve mülkü bir SELinux mülk bağlamıyla ilişkilendirin. Uygun bir mevcut bağlam yoksa yeni bir bağlam oluşturun. Ad, mülke erişirken kullanılır; mülk bağlamı ise SELinux açısından erişilebilirliği kontrol etmek için kullanılır. Adlar herhangi bir dize olabilir ancak AOSP, adların anlaşılır olması için yapılandırılmış bir biçim kullanmanızı önerir.
Mülk adı
Bu biçimi snake_case büyük/küçük harf kullanımıyla 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'ü yalnızca prefix'un gelecekte yazılabilir olması gerekmediğinden emin olduğunuzda kullanın. ** ro ön ekini belirtmeyin.** Bunun yerine, prefix'ü salt okunur (yani yalnızca init tarafından yazılabilir) hale getirmek için sepolicy'yi kullanın.
persist değerini yalnızca değerin yeniden başlatmalarda korunması gerektiğinden ve sistem özelliklerini kullanmanın tek seçeneğiniz olduğundan emin olduğunuzda kullanın.
Google, ro veya persist özelliklerine sahip sistem mülklerini titizlikle inceler.
group terimi, ilgili mülkleri toplamak için kullanılır. audio veya telephony ile benzer kullanımlara sahip bir alt sistem adı olarak tasarlanmıştır. sys, system, dev, default veya config gibi belirsiz veya aşırı yüklenmiş terimleri kullanmayın.
Sistem özelliklerine özel okuma veya yazma erişimi olan bir işlemin alan türünün adı kullanılması yaygın bir uygulamadır. Örneğin, vold sürecinin yazma erişimi olan sistem özellikleri için grup adı olarak vold (sürecin alan türünün adı) kullanılması yaygındır.
Gerekirse mülkleri daha da kategorize etmek için subgroup ekleyin ancak bu öğeyi tanımlamak için belirsiz veya aşırı yüklenmiş terimlerden kaçının. (Birden fazla subgroup de alabilirsiniz.)
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ına örnekler verilmiştir.
| Alan | Grup (ve alt grup) |
|---|---|
| bluetooth ile ilgili | bluetooth |
| Çekirdek komut satırından sysprops | boot |
| Bir derlemeyi tanımlayan sysprops | build
|
| telefonla ilgili | telephony |
| sesle ilgili | audio |
| grafikle ilgili | graphics |
| şiddetle ilgili | vold |
Aşağıda, önceki normal ifade örneğinde name ve type'un kullanımı açıklanmaktadı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 mülkünün 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. Aşağıda, kullanım önerileri verilmiştir:
enabled: Tür, bir özelliği etkinleştirmek veya devre dışı bırakmak için kullanılan 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 mülküyse kullanın.Timeoutmillis: ms birimleri cinsinden bir zaman aşımı değeri için sistem özelliğiyse kullanın.
Örnekler:
persist.radio.multisim.configdrm.service.enabled
Mülk bağlamı
Yeni SELinux mülk bağlamı şeması, daha ayrıntılı ayrıntılara ve daha açıklayıcı adlara olanak tanır. AOSP, mülk adlarında kullanılana 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 firmanın yapılandırmaları olan ve vendor_init tarafından ayarlanması amaçlanan mülkleri ifade ederken vold_status_prop veya yalnızca vold_prop, vold'in mevcut durumunu göstermek üzere kullanılan mülkleri ifade eder.
Mülk bağlamına ad verirken mülklerin genel kullanımını yansıtan adlar seçin. Özellikle aşağıdaki terim türlerinden kaçının:
sys,system,defaultgibi çok genel ve belirsiz 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 listelenenlerden biri olabilir.
| Tür | Tanım |
|---|---|
| Boole | Doğru için true veya 1, yanlış için false veya 0 |
| Tam sayı | 64 bitlik işaretli tam sayı |
| İmzalanmamış tam sayı | imzasız 64 bit tam sayı |
| Çift | çift hassasiyetli kayan nokta |
| Dize | geçerli herhangi bir UTF-8 dizesi |
| enum | 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ır[1, 2, 3] tamsayı listesi 1,2,3 olarak depolanır |
Dahili olarak tüm özellikler dize olarak depolanır. Türü property_contexts dosyası olarak belirterek zorunlu kılabilirsiniz. Daha fazla bilgi için 3. adımdaki 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'te 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şimin kapsamını mümkün olduğunca dar olacak şekilde ayarlayın. Geçmişte geniş erişim, uygulamanın bozulmasına ve güvenlik açıklarına neden olmuştur. Kapsam belirlerken aşağıdaki soruları göz önünde bulundurun:
- Bu sistem özelliğinin kalıcı olması gerekiyor mu? (Evet ise 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 verme ağacını kullanın.
Şekil 1. Sistem özelliklerine erişim kapsamını belirleme karar ağacı
3. Adım: system/sepolicy dosyasına ekleyin
SELinux, sysprop'a erişirken işlemlerin erişilebilirliğini kontrol eder. Gerekli erişim düzeyini belirledikten sonra, system/sepolicy altında mülk bağlamlarını ve işlemlerin okumaya veya yazmaya izin vermesi (veya vermemesi) hakkında ek izin ver ve izin verme kurallarını tanımlayın.
Öncelikle system/sepolicy/public/property.te dosyasında mülk bağlamını tanımlayın. Mülk sistem içindeyse 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ı örneği 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. system/sepolicy/public/{domain}.te veya system/sepolicy/private/{domain}.te dosyasında erişim izni vermek için 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 ana alan dışındaki alanları etkiliyorsa 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;
neverallow kuralı belirli bir alana bağlıysa neverallow kurallarını system/sepolicy/private/{domain}.te dosyasına yerleştirin. Daha geniş kapsamlı "izin verme" kuralları için uygun olduğunda aşağıdaki gibi genel alanlar kullanın:
system/sepolicy/private/property.tesystem/sepolicy/private/coredomain.tesystem/sepolicy/private/domain.te
system/sepolicy/private/audio.te dosyasına şunları ekleyin:
neverallow {
domain -init -audio
} {audio_foo_prop audio_bar_prop}:property_service set;
system/sepolicy/private/property.te dosyasına şunları ekleyin:
neverallow {
domain -coredomain -vendor_init
} audio_prop:file no_rw_file_perms;
{domain -coredomain}'ün tüm tedarikçi firma işlemlerini yakaladığını unutmayın. Dolayısıyla {domain -coredomain -vendor_init}, "vendor_init hariç tüm tedarikçi süreçleri" anlamına gelir.
Son olarak, bir sistem özelliğini mülk bağlamıyla ilişkilendirin. Bu sayede, verilen erişimin ve mülk bağlamlarına uygulanan "izin verme" kurallarının gerçek mülklere uygulanması sağlanır. Bunu yapmak için sistem mülkleri ile mülk bağlamları arasındaki eşlemeyi açıklayan property_contexts dosyasına bir giriş ekleyin. Bu dosyada, tek bir mülkü veya bir bağlamla eşlenecek mülkler için bir ön ek belirtebilirsiniz.
Tek bir mülkü eşlemeyle ilgili söz dizimi:
[property_name] u:object_r:[context_name]:s0 exact [type]
Ön ek eşleme söz dizimi şu şekildedir:
[property_name_prefix] u:object_r:[context_name]:s0 prefix [type]
İsteğe bağlı olarak mülkün türünü belirtebilirsiniz. Mülk türü aşağıdakilerden biri olabilir:
boolintuintdoubleenum [list of possible values...]string(Liste mülkleri içinstringkullanı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 giriş ve önek girişi çakıştığında tam giriş önceliklidir. Daha fazla örnek için system/sepolicy/private/property_contexts sayfasına bakın.
4. adım: Kararlılık gereksinimlerini belirleme
Sistem özelliklerinin bir diğer yönü de kararlılıktı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ümleri) kullanılacaksa kararlı olmalıdır. Ancak yalnızca belirli bir ana hat modülü içinde kullanılıyorsa adını, türünü veya mülk 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? Evetse istikrarlı olmalıdır.
- AOSP tarafından tanımlanan bu sistem özelliğinin,
vendor.imgveyaproduct.imggibi sistem dışı bölümlerdeki kodda (işlemde değil) yazılması veya okunması amaçlanıyor mu? Evetse istikrarlı olmalıdır. - Bu sistem mülküne Mainline modülleri arasında mı yoksa bir Mainline modülü ile platformun güncellenemeyen kısmı arasında mı erişiliyor? Evetse istikrarlı olmalıdır.
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: Özellikleri derleme zamanında ayarlayın
Makefile değişkenleriyle derleme zamanında özellikleri ayarlayın. Teknik olarak, değerler {partition}/build.prop içine yerleştirilmiştir. Ardından init, özellikleri ayarlamak için {partition}/build.prop değerini okur. Bu tür iki değişken grubu vardır: PRODUCT_{PARTITION}_PROPERTIES ve TARGET_{PARTITION}_PROP.
PRODUCT_{PARTITION}_PROPERTIES, özellik değerlerinin listesini içerir. Söz dizimi {prop}={value} veya {prop}?={value} şeklindedir.
{prop}={value}, {prop} değerinin {value} olarak ayarlanmasını sağlayan normal bir atamadır. Tek bir mülk için yalnızca bir tane böyle atama yapılabilir.
{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 ilk atama 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 adresine gönderilen dosyaların listesini içerir. Her dosya, {prop}={value} çiftlerinin 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 bilgi için build/make/core/sysprop.mk başlıklı makaleyi inceleyin.
6. adım: Çalışma zamanında mülklere erişme
Özellikler çalışma zamanında okunabilir ve yazılabilir.
Başlatma komut dosyaları
İlklendirme komut dosyası dosyaları (genellikle *.rc dosyaları), bir özelliği ${prop} veya ${prop:-default} ile okuyabilir, bir özellik belirli bir değere ulaştığında çalışan 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 kullanırken sistem özelliklerini tanımlayabilir ve somut ve türlendirilmiş otomatik olarak oluşturulmuş API'yi kullanabilirsiniz. scope değerini Public ile ayarlamak, oluşturulan API'lerin sınırlar arasında modüller tarafından kullanılmasını sağlar ve API kararlılığını sağlar. Aşağıda, bir .sysprop dosyası, Android.bp modülü ve bunları kullanan C++, Java ve Rust kodu örnekleri 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 düşük düzey mülk işlevleri ve yöntemleri
Mümkün olduğunda, düşük düzey C/C++ veya Rust işlevleri ya da düşük düzey Java yöntemleri kullanabilseniz bile API olarak Sysprop'u 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ılardı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) bölümlerine bakın.
android.os.SystemProperties sınıfı, Java sistem özelliği yöntemleri sunar.
rustutils::system_properties modülü, Rust sistem mülkü işlevleri ve türleri sunar.
Ek: Tedarikçiye özgü mülkler 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çiye özgü mülkler, iş ortağına ait olup platforma değil, kendi donanımlarına veya cihazlarına özgü olan mülkleri ifade eder. Donanıma veya cihaza bağlı olduklarından /vendor veya /odm bölümlerinde kullanılmaları amaçlanmıştır.
Project Treble'dan bu yana platform özellikleri ve tedarikçi özellikleri, çakışmalarını önlemek için tamamen ayrıldı. 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.
Mülk ve bağlam adlarında ad alanı
Tedarikçi firma mülklerinin, diğer bölümlerin mülkleriyle çakışmasını önlemek için aşağıdaki ön eklerden biriyle başlaması gerekir.
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 kullanılabilir ancak yalnızca uyumluluk için izin verilir.
Normal mülkler için kullanmayın.
Aşağıdaki örneklerin tümünde, yukarıda listelenen ön eklerden biri kullanılmaktadır:
vendor.display.primary_redpersist.vendor.faceauth.use_disk_cachero.odm.hardware.platform
Tüm tedarikçi mülkü bağlamları vendor_ ile başlamalıdır. Bu aynı zamanda uyumluluk
için de önemlidir. Aşağıda ö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çiye özgü SEPolicy kuralları ve property_contexts
Tedarikçi firma özellikleri vendor_internal_prop makrosuyla tanımlanabilir. Tanımladığınız tedarikçi firmaya özel kuralları BOARD_VENDOR_SEPOLICY_DIRS dizinine ekleyin.
Örneğin, coral'da bir tedarikçi firma faceauth özelliğini tanımladığınızı varsayalım.
BoardConfig.mk dosyasına (veya BoardConfig.mk dahil edilen herhangi bir dosyaya) şunları ekleyin:
BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy
device/google/coral-sepolicy/private/property.te dosyasına şunları 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ı olmadığından tedarikçi firma özelliklerine system, system-ext veya product bölümlerinden erişilmesine asla 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. Daha açık belirtmek gerekirse, eski adı .sysprop dosyasındaki legacy_prop_name alanına göre ayarlayabilirsiniz. Oluşturulan API, prop_name değerini okumaya çalışır ve prop_name mevcut değilse legacy_prop_name değerini kullanır.
Örneğin, aşağıdaki adımlarda awesome_feature_foo_enabled, foo.awesome_feature.enabled olarak yeniden adlandırılır.
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 noktalara dikkat edin:
Öncelikle, sysprop türünü değiştiremezsiniz. Örneğin, bir
intöğesinistringöğesine dönüştüremezsiniz. Yalnızca adı değiştirebilirsiniz.İkinci olarak, yalnızca okuma API'si eski ada geri döner. Yazma API'si yedek olarak kullanılmaz. Yazılabilir bir sysprop ise yeniden adlandıramazsınız.