Sistem özellikleri ekleyin

Bu sayfada, sistem özelliklerini eklemek veya tanımlamak için standart bir yöntem sunulmaktadır. . Güçlü bir yeniden düzenleme işlemi olmadıkça, yeniden düzenleme yaparken uyumluluk sorunuyla karşılaşabilirsiniz.

1. Adım: Sistem özelliğini tanımlayın

Bir sistem özelliği eklediğinizde, mülk için bir ada karar verin ve SELinux özelliği bağlamıyla çalıştırın. 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}]

"" (hariç tutuldu), ro (yalnızca bir kez ayarlanan tesisler için) veya persist (yeniden başlatmalarda devam eden özellikler için) prefix.

Uyarılar

ro öğesini yalnızca prefix öğesinin yazılabilir olması için gerekli olmadığından emin olduğunuzda kullanın daha avantajlı bir konumda olursunuz. ** 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. Kullanma sys, system, dev, default veya config.

özel okuma veya yazma erişimine sahip olmasını sağlamanıza yardımcı olur. Örneğin, örneğin, vold işleminin yazma erişimine sahip olduğu sistem özellikleri için genellikle vold (işleme ilişkin alan adı türünün adı) olarak grup adı.

Gerekirse tesisleri daha fazla kategorilere ayırmak için subgroup özelliğini ekleyin. muğlak veya aşırı yüklü terimler için kullanılabilir. (Ayrıca daha fazla birden fazla subgroup).

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.

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ğıda, önceki regex'de name ve type kullanımı tanımlanmaktadır bakın.

[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]

  • name, bir grup içindeki bir sistem özelliğini tanımlar.

  • type, öğenin türünü veya amacını açıklayan isteğe bağlı bir öğedir. sistem özelliğini etkinleştirmelisiniz. Örneğin sysprop’u audio.awesome_feature_enabled veya yalnızca audio.awesome_feature, yeniden adlandır: audio.awesome_feature.enabled (sistem özelliği türünü ve amacını yansıtacak şekilde).

Türün ne olması gerektiğiyle ilgili belirli bir kural yoktur; bunlar kullanımdır öneriler:

  • enabled: Tür, işlevi çevirmek için kullanılan bir boole sistem özelliğiyse veya devre dışı bırakabilirsiniz.
  • 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 özelliğiyse kullanın.
  • Timeoutmillis: Birim cinsinden zaman aşımı değeri için bir sistem özelliğiyse kullanın. / ms.

Ö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, tesis adları için kullanılanlara benzer şekilde, şu biçimdedir:

{group}[_{subgroup}]*_prop

Terimler aşağıdaki şekilde tanımlanır:

group ve subgroup, önceki için tanımlananla aynı anlama sahiptir örnek normal ifade. Ö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.

Bir mülk bağlamına ad verirken genel kullanımı yansıtan adlar seçin. özellikler. Ö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.

vold_config_prop - exported_vold_prop gibi ad kullanımlarını tercih et, veya vold_vendor_writable_prop.

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ıyor
[1, 2, 3] tam sayı listesi 1,2,3 olarak depolanır

Dahili olarak tüm özellikler dize olarak depolanır. Türü, bu dosyayı property_contexts dosyası olarak belirtir. Daha fazla bilgi için bkz. 3. adımda property_contexts.

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 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?

Yukarıdaki soruları ve aşağıdaki karar ağacını projedeki riskleri belirlemede belirlemek için zaman çizelgesi oluşturur.

Erişim kapsamını belirlemek için karar ağacı

Ş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. Şu tarihten sonra: hangi düzeyde erişilebilirlik gerektiğini siz belirleyin, mülk bağlamlarını tanımlayın system/sepolicy altında, ek allow ve neverallow kurallarıyla birlikte izinli olduğu (ve olmadığı) ile ilgili daha fazla bilgi içerir.

Öncelikle tesis bağlamını system/sepolicy/public/property.te sayfasında tanımlayın dosyası olarak kaydedebilirsiniz. Özellik, system-internal ise bunu system/sepolicy/private/property.te dosyası yükleyin. Ş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, hem de okuma erişimine ihtiyacı olmayan tedarikçi firmanın gerçekleştirdiği işlemleri yapabilir.

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 olan yerlerde bunlar gibi genel alanlar:

  • 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. ODK {domain -coredomain -vendor_init}, "haricindeki tüm tedarikçi işlemleri anlamına gelir vendor_init."

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 özelliği veya bir bağlamda eşlenecek mülklerin ön ekini kullanabilirsiniz.

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, takip etmek için:

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

Mümkün olduğunda her girişin kendi özel türüne sahip olduğundan emin olun. type property ayarlanırken zorunlu kılındı. Aşağıdaki örnekte, eşleme:

# 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 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ş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. Entegre Mainline, işletim sisteminin bazı bölümleri, güncellenebilir modüller olarak modülerleştirilmiştir (APEX'lerde APK'lar).

Bir sistem özelliği, örneğin güncellenebilir yazılımlarda kullanılmak üzere tüm sistem ve tedarikçi bölümlerinde kararlı olmalıdır. Ancak bu Örneğin belirli bir Mainline modülünde, adını değiştirebilirsiniz. veya özellik bağlamlarını kullanabilir, 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 yapılandırılması) nasıl değişiklik gösterebilir? 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? Cevabınız evet ise sabit olması gerekir.

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:

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 yerleşik olarak bulunur. Ardından init okuma yapar Özellikleri ayarlamak için {partition}/build.prop. İki tür veri vardır, değişkenler: PRODUCT_{PARTITION}_PROPERTIES ve TARGET_{PARTITION}_PROP.

PRODUCT_{PARTITION}_PROPERTIES, özellik değerlerinin listesini içerir. Söz dizimi {prop}={value} veya {prop}?={value}.

{prop}={value}, {prop} öğesinin geçerli olmasını sağlayan normal bir atamadır {value}; Tek bir mülk başına bu tür yalnızca bir atama yapılabilir.

{prop}?={value} isteğe bağlı bir ödevdir; {prop} yalnızca şu durumlarda {value} olarak ayarlanır: {prop}={value} ataması yok. 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.

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}, bir mülk belirebilir 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ı

Ş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ı. 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 alt düzey mülk işlevleri ve yöntemleri

Mümkün olduğunda, düşük seviye C/C++ veya Rust işlevlerine rağmen Sysprop'u API olarak kullanın veya alt düzey Java yöntemleri kullanabilirsiniz.

libc, libbase ve libcutils, C++ sistem özelliği işlevleri sunar. libc. temel API'ye sahiptir; libbase ve libcutils işlevleri ise sarmalayıcılar. Mümkünse libbase sysprop işlevlerini kullanın; onlar ve ana makine ikili programları 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 sunar ve türler.

Ek: Tedarikçi firmaya özgü özellikler ekleme

İş ortakları (Pixel geliştirme bağlamında çalışan Google çalışanları dahil) kullanabilirsiniz. Tedarikçi firmaya özgü mülkler, kendi iş ortaklarına ait olan ve platforma değil, kendi donanımına veya cihazına bağlı olarak hareket eder. Bunlar donanım veya cihaz olduğu için bağlı olarak, /vendor veya /odm bölümlerinde kullanılmaları gerekir.

Project Treble’dan bu yana platform ve tedarikçi özellikleri korumak için tamamen bölündü. Aşağıda, bu risklerin ve hangi tedarikçi firma özelliklerinin her zaman kullanılması gerektiğini söyler.

Ö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 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ılmıştı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 ayrıca şunlar için de geçerlidir: uyumluluk. Aşağıda bazı ö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 makrosu ile tanımlanabilir. Kodu BOARD_VENDOR_SEPOLICY_DIRS dizininde tanımladığınız tedarikçi firmaya özel kurallar. Örneğin, mercanda satıcı Faceauth özelliği 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 satıcıya bağlı olamayacağı için tedarikçi firma özelliklerine system, system-ext veya product bölüm.

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 şekilde geriye dönük uyumluluk korunarak hem eski adı hem de yeni mülk adını belirterek Daha ayrıntılı olarak belirtmek gerekirse, .sysprop dosyasındaki legacy_prop_name alanından eski adı ayarlayın. İlgili içeriği oluşturmak için kullanılan oluşturulan API prop_name verilerini okumaya çalışır ve aşağıdaki durumlarda legacy_prop_name değerini kullanır prop_name mevcut değil.

Örneğin, aşağıdaki adımlarda awesome_feature_foo_enabled yeniden adlandırılıyor Hedef: foo.awesome_feature.enabled.

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, 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 adın yerini alır. Write API, geri dönelim. Sysprop yazılabilir bir sistemse yeniden adlandıramazsınız.