Sistem özellikleri ekleyin

Bu sayfada, sistem özelliklerini eklemek veya tanımlamak için standart bir yöntem sunulmaktadır. . Aksini gerektiren önemli bir uyumluluk sorununuz yoksa yeniden yapılandırırken yönergeleri kullandığınızdan emin olun.

1. adım: Sistem mülkünü 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 hesap oluşturabilirsiniz. Mülke erişirken bu ad kullanılır; mülk bağlam, SELinux açısından erişilebilirliği kontrol etmek için kullanılır. Adlardan herhangi biri olabilir dizesidir ancak AOSP, bunları netleştirmek 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 "" (atlandı), ro (yalnızca bir kez ayarlanan mülkler için) veya persist (yeniden başlatmalarda devam eden mülkler 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 öğesini salt okunur (diğer bir deyişle, yalnızca init tarafından yazılabilir) yap.

persist öğesini yalnızca değerin kullanılması gerektiğinden emin olduğunuzda kullanın ve sistem özelliklerini kullanmanın tek seçeneğiniz olduğunu unutmayın.

Google, ro veya persist içeren sistem özelliklerini sıkı bir şekilde inceler. özellikler.

group terimi, ilgili mülkleri toplamak için kullanılır. Bu amacı audio veya telephony ile benzer bir alt sistem adı olmalıdı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ü adını kullanmak 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ış. Kontrol edin system/sepolicy/private/property_contexts dosyası ve mevcut grup adlarını kullanın kullanmaya başlayabilirsiniz. Aşağıdaki tabloda, sık kullanılan grup adlarına örnekler verilmiştir.

Alan	Grup (ve alt grup)
bluetooth ile ilgili	bluetooth
çekirdek cmdline'daki 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 gruptaki 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'u audio.awesome_feature_enabled veya yalnızca audio.awesome_feature olarak adlandırmak yerine, sistem mülkünün türünü ve amacını yansıtacak şekilde audio.awesome_feature.enabled olarak 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 Sistemin dinamik durumunu temsil etmeyen; temsil eder önceden yapılandırılmış değer (örneğin, salt okunur özellik).
• List: Değeri liste olan bir sistem mülküyse kullanın.
• Timeoutmillis: ms biriminde bir zaman aşımı değeri için 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 hassas ayrıntı ve kullanabilirsiniz. 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 Bunlar, bir tedarikçi firma tarafından sağlanan ve vendor_init, özellikleri belirtirken vold_status_prop veya yalnızca vold_prop Bu değişiklik, vold adlı kullanıcının mevcut durumunu açığa çıkaracak.

Mülk bağlamına ad verirken 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 belirsiz görünen terimler
• Erişilebilirliği doğrudan kodlayan terimler: exported, apponly, ro, public, private gibi.

vold_config_prop yerine 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	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 UTF-8 dizesi
numaralandırma	değerler, boşluk içermeyen herhangi bir geçerli UTF-8 dizesi olabilir
Yukarıdakilerin listesi	Ayırıcı olarak virgül (,) kullanılıyor [1, 2, 3] tam sayı listesi 1,2,3 olarak depolanır

Dahili olarak tüm özellikler dize olarak depolanır. Türü, bunu bir property_contexts dosyası olarak belirtir. 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 tutun. Geçmişte, geniş kapsamlı erişim, uygulamaların bozulmasına ve güvenlik açıklarına yol açmıştır. Dikkatlice şu soruları sorabilirsiniz:

• 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 verme ağacını kullanın.

Şekil 1. Sistem özelliklerine erişim kapsamını belirlemek için karar ağacı

3. Adım: system/sepolicy dosyasına ekleyin

Sysprop'a erişirken SELinux, 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 neleri okumasına (veya yazmamasına) izin verildiğiyle ilgili ek izin ver ve asla izin verme kurallarını tanımlayın.

Öncelikle tesis bağlamını system/sepolicy/public/property.te sayfasında tanımlayın dosyası olarak kaydedebilirsiniz. Mülk sistem içindeyse system/sepolicy/private/property.te dosyasında tanımlayın. Şunlardan birini kullanın: system_[accessibility]_prop([context]) makroları erişilebilirlik gereksinimleri. Bu örnek tablodaki system/sepolicy/public/property.te dosyası:

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. set_prop hesabını kullan ve get_prop makroları arasında yer alır. system/sepolicy/public/{domain}.te veya system/sepolicy/private/{domain}.te dosyası olarak kaydedebilirsiniz. Mümkün olduğunda private kullanın; public, yalnızca set_prop veya get_prop makrosu, çekirdek alan dışındaki tüm alanları etkiler.

Ö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, makro tarafından kapsamlı olarak ayarlanır. Örneğin, daha önce Sistem özelliklerinizin satıcı tarafından okunması gerektiğinden system_restricted_prop daha fazla bilgi edineceksiniz. Okuma erişimi tüm tedarikçi firma işlemleri için gerekli değilse ve belirli bir grup işlem (vendor_init gibi) tarafından gerekiyorsa, okuma erişimine ihtiyaç duymayan tedarikçi işlemleri içindir.

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;

Aşağıdaki durumlarda system/sepolicy/private/{domain}.te dosyasına "hiçbir zaman izin verme" kurallarını yerleştirin "Neverallow" kuralı belirli bir alan adına bağlı. Daha geniş kapsamlı "izin verme" kuralları için uygun olduğunda aşağıdaki 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 ş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 ve uygulanan "izin verilmemesi" kurallarının geçerli olduğunu mülk bağlamları gerçek mülklere uygulanır. Bunu yapmak için property_contexts dosyası, sistem arasındaki eşlemeyi açıklayan bir dosya göz atabilirsiniz. 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:

• bool
• int
• uint
• double
• enum [list of possible values...]
• string (Liste özellikleri için string öğesini kullanın.)

property ayarlanırken type zorunlu olduğundan, mümkün olduğunda her girişin belirlenen 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ş önceliklendirme. Daha fazla örnek için system/sepolicy/private/property_contexts sayfasına bakın.

4. adım: Kararlılık gereksinimlerini belirleme

Kararlılık, sistem özelliklerinin başka bir yönüdür ve erişilebilirlik. Kararlılık, bir sistem özelliğinin tüm gereksinimleri karşılayan (örneğin yeniden adlandırılmış, hatta kaldırılan) için iyi bir fırsattır. Bu çünkü Android işletim sistemi modüler hale geliyor. Treble sayesinde sistem, tedarikçi firma 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 (APEX'lerde veya APK'larda) olarak modülerleştirilir.

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 yapılandırılması (veya cihaz başına farklı şekilde yapılandırılması) amaçlanıyor mu? Cevabınız evet ise sabit olması gerekir.
• AOSP tarafından tanımlanan bu sistem özelliği, üzerine yazılması veya okunması amaçlanıyor mu? vendor.img gibi sistem dışı bölümlerde bulunan kod (işlem değil) Hangisi, product.img? Cevabınız evet ise sabit olması gerekir.
• Bu sistem özelliğine Mainline modüllerinden veya bir Mainline üzerinden erişiliyor modülünü ve platformun güncelleştirilemeyen bölümünü nedir? Evetse istikrarlı olmalıdır.

Kararlı sistem özellikleri için her birini resmi bir şekilde API olarak tanımlayın ve API'yi kullanın aşağıdaki adımları izleyerek sistem özelliğine erişmek için 6. Adım:

Not: AOSP, kararlı olması gerekmese bile bir sistem özelliğini API olarak tanımlamanızı önerir. Bu, tüm sistemi açık bir şekilde numaralandırır. özelliklerini tek bir görünümde incelemenize olanak tanır ve kararsız bir sistem özelliğini kararlı bir sürüme geçirme. ( Kararlı ve kararsız sistem özelliği tanımlarını birbirlerinden ayırt etmek, 6. adımda açıklanmıştır.)

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, mülk değerlerinin listesini içerir. Söz dizimi {prop}={value} veya {prop}?={value}.

{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 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 şu kullanıcılara yayınlanan bir dosya listesi içerir {partition}/build.prop. 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 bkz. build/make/core/sysprop.mk.

Not: Tedarikçi firma bölümlerindeki ve odm bölümlerindeki build.prop, vendor_init bağlamında yazılır. Diğer bölümlerdeki build.prop ise init bağlamında yazılır.

6. adım: Çalışma zamanında mülklere erişme

Özellikler çalışma zamanında okunabilir ve yazılabilir.

İlklendirme 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}

Not: build.prop ile benzer şekilde, vendor ve odm bölümlerinin altındaki rc dosyaları vendor_init ile aynı bağlamı kullanarak okuma ve yazma.

getprop ve setprop kabuk komutları

Şunu okumak için getprop veya setprop kabuk komutlarını kullanabilirsiniz: ve özellikleri yazın. Daha fazla bilgi için getprop --help veya setprop --help.

$ 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 oluşturulan API'yi kullanabilirsiniz Bunlar somut ve yazılıdır. scope değerinin Public ile ayarlanması da gelir yaratır API'ler sınırlar arasındaki modüllerde kullanılabilir ve API kararlılığı sağlar. Buradan .sysprop dosyası, bir Android.bp modülü ve C++, Java ve Rust kodu örneği yardımcı olabilir.

# 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 uygun işlevlerdir ve ana makine ikili dosyaları libbase işlevlerini kullanabilir. Daha fazla ayrıntılar, 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ö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) kullanabilirsiniz. Tedarikçi firmaya özgü mülkler, iş ortağına ait olan ve kendi benzersiz özellikleridir. platforma değil, kendi donanımına veya cihazına bağlı olarak hareket 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 ve tedarikçi özellikleri korumak 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ı

E-posta teslim edilmesinin önlenmesi için tüm tedarikçi firma özellikleri, özellikleri arasında bir çakışmaya neden olabilir.

• 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ılmıştır:

• vendor.display.primary_red
• persist.vendor.faceauth.use_disk_cache
• ro.odm.hardware.platform

Tüm tedarikçi mülkü bağlamları vendor_ ile başlamalıdır. Bu, aynı zamanda uyumluluk. Aşağıda örnekler verilmiştir:

• vendor_radio_prop.
• vendor_faceauth_prop.
• vendor_usb_prop.

Mülklerin adlandırılması ve bakımı tedarikçinin sorumluluğundadır; bu nedenle ek olarak, 2. Adımda önerilen biçim satıcı ad alanı gereksinimleri.

Tedarikçi firmaya özel SEPolicy kuralları ve property_contexts

Tedarikçi firma özellikleri vendor_internal_prop makrosuyla tanımlanabilir. Kodu BOARD_VENDOR_SEPOLICY_DIRS dizininde tanımladığınız tedarikçi firmaya özel kurallar. Örneğin, coral'da bir tedarikçi faceauth özelliğini tanımladığınızı varsayalım.

BoardConfig.mk dosyasına (veya herhangi bir BoardConfig.mk içerdiğinde) takip etmek için:

BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy

device/google/coral-sepolicy/private/property.te dosyasına takip etmek için:

vendor_internal_prop(vendor_faceauth_prop)

device/google/coral-sepolicy/private/property_contexts dosyasına takip etmek için:

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çiye bağlı olamayacağından, tedarikçi mülklerine system, system-ext veya product bölümlerinden hiçbir zaman 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 API olarak Sysprop'u kullanın tıklayı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 uyarıları göz önünde bulundurun:

• Öncelikle, sysprop türünü değiştiremezsiniz. Örneğin, projenizin int aksesuarı string aksesuarına dönüştürüldü. 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. Sysprop yazılabilir bir sistemse yeniden adlandıramazsınız.