Sistem Özellikleri Ekle

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'u audio.awesome_feature_enabled veya yalnızca audio.awesome_feature olarak adlandırmak yerine, sistem özellik türünü ve amacını yansıtacak şekilde onu audio.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ır
Tamsayı 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.

Decision tree for determining the scope of access

Ş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çin string 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 veya product.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.