Auf dieser Seite finden Sie eine kanonische Methode zum Hinzufügen oder Definieren von Systemeigenschaften in Android mit Richtlinien für die Refaktorierung vorhandener Systemeigenschaften. Achten Sie darauf, die Richtlinien beim Refactoring zu verwenden, es sei denn, es liegt ein schwerwiegendes Kompatibilitätsproblem vor, das etwas anderes erfordert.
Schritt 1: Systemeigenschaft definieren
Wenn Sie eine Systemeigenschaft hinzufügen, wählen Sie einen Namen für die Eigenschaft aus und ordnen Sie sie einem SELinux-Eigenschaftskontext zu. Wenn kein geeigneter Kontext vorhanden ist, erstellen Sie einen neuen. Der Name wird beim Zugriff auf die Property verwendet. Der Property-Kontext wird verwendet, um die Zugänglichkeit im Hinblick auf SELinux zu steuern. Namen können beliebige Strings sein. AOSP empfiehlt jedoch, ein strukturiertes Format zu verwenden, um für Klarheit zu sorgen.
Property-Name
Verwenden Sie dieses Format mit snake_case-Schreibung:
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
Verwenden Sie für das Element prefix entweder „"" (ausgelassen), ro (für Eigenschaften, die nur einmal festgelegt werden) oder persist (für Eigenschaften, die nach einem Neustart erhalten bleiben).
Einschränkungen
Verwenden Sie ro nur, wenn Sie sicher sind, dass prefix in Zukunft nicht beschreibbar sein muss. ** Geben Sie nicht das Präfix ro an.** Verwenden Sie stattdessen sepolicy, um prefix schreibgeschützt zu machen, d. h. nur von init beschreibbar.
Verwenden Sie persist nur, wenn Sie sicher sind, dass der Wert nach einem Neustart erhalten bleiben muss und die Verwendung der Systemeigenschaften Ihre einzige Option ist.
Google prüft die Systemeigenschaften, die entweder ro- oder persist-Attribute haben, streng.
Der Begriff group wird verwendet, um ähnliche Properties zusammenzufassen. Es sollte ein Subnetzname sein, der in der Verwendung mit audio oder telephony vergleichbar ist. Verwenden Sie keine mehrdeutigen oder überladenen Begriffe wie sys, system, dev, default oder config.
Es ist üblich, den Namen des Domaintyps eines Prozesses zu verwenden, der exklusiven Lese- oder Schreibzugriff auf die Systemeigenschaften hat. Für die Systemattribute, auf die der Prozess vold Schreibzugriff hat, wird beispielsweise vold (der Name des Domaintyps für den Prozess) als Gruppenname verwendet.
Fügen Sie bei Bedarf subgroup hinzu, um Unterkünfte weiter zu kategorisieren. Vermeiden Sie jedoch mehrdeutige oder überladene Begriffe, um dieses Element zu beschreiben. Sie können auch mehrere subgroup haben.
Viele Gruppennamen wurden bereits definiert. Prüfen Sie die Datei system/sepolicy/private/property_contexts und verwenden Sie nach Möglichkeit vorhandene Gruppennamen, anstatt neue zu erstellen. Die folgende Tabelle enthält Beispiele für häufig verwendete Gruppennamen.
| Domain | Gruppe (und Untergruppe) |
|---|---|
| Bluetooth | bluetooth |
| sysprops aus der Kernel-Befehlszeile | boot |
| Sysprops, die einen Build identifizieren | build
|
| Telefoniebezogen | telephony |
| Audio | audio |
| Grafiken | graphics |
| vold | vold |
Im Folgenden wird die Verwendung von name und type im vorherigen Regex-Beispiel definiert.
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
nameidentifiziert eine Systemeigenschaft innerhalb einer Gruppe.typeist ein optionales Element, das den Typ oder die Absicht der Systemeigenschaft verdeutlicht. Benennen Sie einen Sysprop beispielsweise nicht alsaudio.awesome_feature_enabledoder nuraudio.awesome_featureum, sondern inaudio.awesome_feature.enabled, um den Typ und Intent des Systemattributs widerzuspiegeln.
Es gibt keine bestimmte Regel, was der Typ sein muss. Hier sind einige Empfehlungen:
enabled: Verwenden Sie diesen Wert, wenn der Typ eine boolesche Systemeigenschaft ist, mit der eine Funktion aktiviert oder deaktiviert wird.config: Verwenden Sie diesen Wert, wenn Sie verdeutlichen möchten, dass die Systemeigenschaft keinen dynamischen Status des Systems darstellt, sondern einen vorkonfigurierten Wert (z. B. ein schreibgeschütztes Element).List: Wird verwendet, wenn es sich um eine Systemeigenschaft handelt, deren Wert eine Liste ist.Timeoutmillis: Verwenden Sie diesen Wert, wenn es sich um eine Systemeigenschaft für einen Zeitüberschreitungswert in Millisekunden handelt.
Beispiele:
persist.radio.multisim.configdrm.service.enabled
Hotelkontext
Das neue SELinux-Attributkontextschema ermöglicht eine detailliertere und aussagekräftigere Bezeichnung. Ähnlich wie bei Eigenschaftsnamen wird in AOSP das folgende Format empfohlen:
{group}[_{subgroup}]*_prop
Die Begriffe sind so definiert:
group und subgroup haben dieselbe Bedeutung wie für den vorherigen Beispiel-Regex definiert. Beispielsweise steht vold_config_prop für Eigenschaften, die Konfigurationen eines Anbieters sind und von vendor_init festgelegt werden sollen, während vold_status_prop oder nur vold_prop für Eigenschaften steht, die den aktuellen Status von vold anzeigen sollen.
Wählen Sie beim Benennen eines Attributkontexts die Namen aus, die der allgemeinen Verwendung der Attribute entsprechen. Vermeiden Sie insbesondere die folgenden Arten von Begriffen:
- Begriffe, die zu allgemein und mehrdeutig erscheinen, z. B.
sys,systemoderdefault. - Begriffe, mit denen Bedienungshilfen direkt codiert werden, z. B.
exported,apponly,ro,publicoderprivate.
Verwenden Sie Namen wie vold_config_prop anstelle von exported_vold_prop oder vold_vendor_writable_prop.
Eingeben
Ein Property-Typ kann einer der folgenden in der Tabelle aufgeführten Typen sein.
| Eingeben | Definition |
|---|---|
| Boolesch | true oder 1 für „wahr“, false oder 0 für „falsch“ |
| Ganzzahl | Vorzeichenbehaftete 64-Bit-Ganzzahl |
| Vorzeichenlose Ganzzahl | 64-Bit-Ganzzahl ohne Vorzeichen |
| Double | Gleitkommazahl mit doppelter Genauigkeit |
| String | beliebiger gültiger UTF-8-String |
| Aufzählung | Werte können beliebige gültige UTF-8-Strings ohne Leerzeichen sein. |
| Liste der oben genannten | Als Trennzeichen wird ein Komma (,) verwendetDie Ganzzahlliste [1, 2, 3] wird als 1,2,3 gespeichert |
Intern werden alle Properties als Strings gespeichert. Sie können den Typ erzwingen, indem Sie ihn als property_contexts-Datei angeben. Weitere Informationen finden Sie unter property_contexts in Schritt 3.
Schritt 2: Erforderliche Bedienungshilfenebenen ermitteln
Es gibt vier Hilfsmakros, mit denen eine Property definiert wird.
| Art der Barrierefreiheit | Bedeutung |
|---|---|
system_internal_prop |
Nur in /system verwendete Properties |
system_restricted_prop |
Eigenschaften, die außerhalb von /system gelesen, aber nicht geschrieben werden |
system_vendor_config_prop |
Eigenschaften, die außerhalb von /system gelesen und nur von vendor_init geschrieben werden |
system_public_prop |
Attribute, die außerhalb von /system gelesen und geschrieben werden |
Beschränken Sie den Zugriff auf Systemeigenschaften so weit wie möglich. In der Vergangenheit hat ein breiter Zugriff zu App-Störungen und Sicherheitslücken geführt. Berücksichtigen Sie beim Festlegen des Umfangs die folgenden Fragen:
- Muss diese Systemeigenschaft beibehalten werden? (Falls ja, warum?)
- Welcher Prozess sollte Lesezugriff auf diese Property haben?
- Welcher Prozess sollte Schreibzugriff auf diese Property haben?
Verwenden Sie die vorherigen Fragen und den folgenden Entscheidungsbaum, um den geeigneten Zugriffsbereich zu bestimmen.
Abbildung 1: Entscheidungsbaum zum Festlegen des Zugriffsbereichs auf Systemeigenschaften
Schritt 3: Zu „system/sepolicy“ hinzufügen
Beim Zugriff auf sysprop steuert SELinux die Zugriffsrechte von Prozessen. Nachdem Sie festgelegt haben, welche Zugriffsebene erforderlich ist, definieren Sie unter system/sepolicy Property-Kontexte sowie zusätzliche allow- und neverallow-Regeln, die festlegen, was die Prozesse lesen oder schreiben dürfen.
Definieren Sie zuerst den Attributkontext in der Datei system/sepolicy/public/property.te. Wenn das Attribut systemintern ist, definieren Sie es in der Datei system/sepolicy/private/property.te. Verwenden Sie eines der system_[accessibility]_prop([context])-Makros, das die für Ihre Systemeigenschaft erforderliche Barrierefreiheit bietet. Hier ein Beispiel für die system/sepolicy/public/property.te-Datei:
system_public_prop(audio_foo_prop)
system_vendor_config_prop(audio_bar_prop)
Beispiel zum Hinzufügen in die Datei system/sepolicy/private/property.te:
system_internal_prop(audio_baz_prop)
Zweitens: Gewähren Sie Lese- und/oder Schreibzugriff auf den Property-Kontext. Verwenden Sie die Makros set_prop und get_prop, um Zugriff in der Datei system/sepolicy/public/{domain}.te oder system/sepolicy/private/{domain}.te zu gewähren. Verwende nach Möglichkeit private. public ist nur geeignet, wenn das set_prop- oder get_prop-Makro Domains außerhalb der Kerndomain betrifft.
Beispiel in der system/sepolicy/private/audio.te-Datei:
set_prop(audio, audio_foo_prop)
set_prop(audio, audio_bar_prop)
Beispiel in der system/sepolicy/public/domain.te-Datei:
get_prop(domain, audio_bar_prop)
Drittens: Fügen Sie einige „neverallow“-Regeln hinzu, um die Zugriffsrechte für den Bereich des Makros weiter einzuschränken. Angenommen, Sie haben system_restricted_prop verwendet, da Ihre Systemattribute von Anbieterprozessen gelesen werden müssen. Wenn der Lesezugriff nicht für alle Anbieterprozesse, sondern nur für eine bestimmte Gruppe von Prozessen (z. B. vendor_init) erforderlich ist, untersagen Sie Anbieterprozesse, die den Lesezugriff nicht benötigen.
Verwenden Sie die folgende Syntax, um den Schreib- und Lesezugriff einzuschränken:
So beschränken Sie den Schreibzugriff:
neverallow [domain] [context]:property_service set;
So beschränken Sie den Lesezugriff:
neverallow [domain] [context]:file no_rw_file_perms;
Platzieren Sie Neverallow-Regeln in der Datei system/sepolicy/private/{domain}.te, wenn die Neverallow-Regel an eine bestimmte Domain gebunden ist. Verwenden Sie für allgemeinere Regeln vom Typ „Nie zulassen“ nach Bedarf allgemeine Domains wie die folgenden:
system/sepolicy/private/property.tesystem/sepolicy/private/coredomain.tesystem/sepolicy/private/domain.te
Fügen Sie in der Datei system/sepolicy/private/audio.te Folgendes ein:
neverallow {
domain -init -audio
} {audio_foo_prop audio_bar_prop}:property_service set;
Fügen Sie in der Datei system/sepolicy/private/property.te Folgendes ein:
neverallow {
domain -coredomain -vendor_init
} audio_prop:file no_rw_file_perms;
Hinweis: {domain -coredomain} erfasst alle Anbieterprozesse. {domain -coredomain -vendor_init} bedeutet also „alle Anbieterprozesse außer
vendor_init“.
Zum Schluss verknüpfen Sie eine Systemeigenschaft mit dem Attributkontext. Dadurch wird sichergestellt, dass der gewährte Zugriff und die „Neverallow“-Regeln, die auf Attributkontexte angewendet werden, auf tatsächliche Properties angewendet werden. Fügen Sie dazu der Datei property_contexts einen Eintrag hinzu. Diese Datei beschreibt die Zuordnung zwischen Systemeigenschaften und Property-Kontexten. In dieser Datei können Sie entweder eine einzelne Property oder ein Präfix für Properties angeben, die einem Kontext zugeordnet werden sollen.
So ordnen Sie eine einzelne Property zu:
[property_name] u:object_r:[context_name]:s0 exact [type]
So ordnen Sie ein Präfix zu:
[property_name_prefix] u:object_r:[context_name]:s0 prefix [type]
Optional können Sie den Typ der Property angeben. Möglich sind folgende Typen:
boolintuintdoubleenum [list of possible values...]string(Verwenden Siestringfür Listeneigenschaften.)
Achten Sie darauf, dass jeder Eintrag nach Möglichkeit den richtigen Typ hat, da type beim Festlegen von property erzwungen wird. Im folgenden Beispiel wird gezeigt, wie eine Zuordnung geschrieben wird:
# 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
Bei einem Konflikt zwischen einem genauen Eintrag und einem Präfixeintrag hat der genaue Eintrag Vorrang. Weitere Beispiele finden Sie unter system/sepolicy/private/property_contexts.
Schritt 4: Stabilitätsanforderungen ermitteln
Die Stabilität ist ein weiterer Aspekt der Systemeigenschaften und unterscheidet sich von der Barrierefreiheit. Stabilität bezieht sich darauf, ob eine Systemeigenschaft in Zukunft geändert (z. B. umbenannt oder sogar entfernt) werden kann. Das ist besonders wichtig, da Android modular wird. Mit Treble können die System-, Anbieter- und Produktpartitionen unabhängig voneinander aktualisiert werden. Bei Mainline sind einige Teile des Betriebssystems als aktualisierbare Module (in APEXes oder APKs) modularisiert.
Wenn eine Systemeigenschaft für alle aktualisierbaren Softwarekomponenten verwendet werden soll, z. B. für System- und Anbieterpartitionen, muss sie stabil sein. Wenn es jedoch nur in einem bestimmten Mainline-Modul verwendet wird, können Sie den Namen, den Typ oder die Property-Kontexte ändern und es sogar entfernen.
Stellen Sie die folgenden Fragen, um die Stabilität einer Systemeigenschaft zu ermitteln:
- Soll diese Systemeigenschaft von Partnern konfiguriert werden (oder für jedes Gerät unterschiedlich konfiguriert werden)? Falls ja, muss es stabil sein.
- Soll diese von AOSP definierte Systemeigenschaft in Code (nicht in Prozesse) geschrieben oder daraus gelesen werden, der sich in nicht systeminternen Partitionen wie
vendor.imgoderproduct.imgbefindet? Falls ja, muss es stabil sein. - Wird auf diese Systemeigenschaft über Mainline-Module oder über ein Mainline-Modul und den nicht aktualisierbaren Teil der Plattform zugegriffen? Falls ja, muss es stabil sein.
Definieren Sie die stabilen Systemeigenschaften als API und verwenden Sie die API, um auf die Systemeigenschaft zuzugreifen, wie in Schritt 6 erläutert.
Schritt 5: Eigenschaften zum Zeitpunkt der Erstellung festlegen
Legen Sie Eigenschaften zum Buildzeitpunkt mit Makefile-Variablen fest. Technisch gesehen sind die Werte in {partition}/build.prop integriert. Anschließend liest init {partition}/build.prop, um die Eigenschaften festzulegen. Es gibt zwei solcher Variablen: PRODUCT_{PARTITION}_PROPERTIES und TARGET_{PARTITION}_PROP.
PRODUCT_{PARTITION}_PROPERTIES enthält eine Liste von Property-Werten. Die Syntax lautet {prop}={value} oder {prop}?={value}.
{prop}={value} ist eine normale Zuweisung, die dafür sorgt, dass {prop} auf {value} festgelegt ist. Pro Property ist nur eine solche Zuweisung möglich.
{prop}?={value} ist eine optionale Zuweisung. {prop} wird nur auf {value} gesetzt, wenn es keine {prop}={value}-Zuweisungen gibt. Wenn mehrere optionale Zuweisungen vorhanden sind, wird die erste ausgewählt.
# 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 enthält eine Liste von Dateien, die direkt an {partition}/build.prop ausgegeben wird. Jede Datei enthält eine Liste von {prop}={value}-Paaren.
# 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
Weitere Informationen finden Sie unter build/make/core/sysprop.mk.
Schritt 6: Zur Laufzeit auf Properties zugreifen
Eigenschaften können zur Laufzeit gelesen und geschrieben werden.
Init-Scripts
Init-Skriptdateien (in der Regel *.rc-Dateien) können ein Attribut von ${prop} oder ${prop:-default} lesen, eine Aktion festlegen, die ausgeführt wird, wenn ein Attribut zu einem bestimmten Wert wird, und die Attribute mit dem Befehl setprop schreiben.
# 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}
Shell-Befehle „getprop“ und „setprop“
Sie können die Shell-Befehle getprop oder setprop verwenden, um die Eigenschaften zu lesen oder zu schreiben. Rufen Sie für weitere Details getprop --help oder setprop --help auf.
$ adb shell getprop ro.vndk.version
$
$ adb shell setprop security.perf_harden 0
Sysprop als API für C++/Java/Rust
Mit sysprop als API können Sie Systemeigenschaften definieren und automatisch generierte APIs verwenden, die konkret und typisiert sind. Wenn Sie scope auf Public festlegen, sind generierte APIs auch für Module über Grenzen hinweg verfügbar. Außerdem wird so die API-Stabilität gewährleistet. Hier ist ein Beispiel für eine .sysprop-Datei, ein Android.bp-Modul und C++, Java- und Rust-Code, in dem sie verwendet werden.
# 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);
Weitere Informationen finden Sie unter Systemeigenschaften als APIs implementieren.
Low-Level-Eigenschaftsfunktionen und ‑methoden in C/C++, Java und Rust
Verwenden Sie nach Möglichkeit Sysprop als API, auch wenn Ihnen C/C++- oder Rust-Funktionen auf niedriger Ebene oder Java-Methoden auf niedriger Ebene zur Verfügung stehen.
libc, libbase und libcutils bieten C++-Systemeigenschaftsfunktionen. libc hat die zugrunde liegende API, während die Funktionen libbase und libcutils Wrapper sind. Verwenden Sie nach Möglichkeit die libbase-Sysprop-Funktionen. Sie sind am praktischsten und Host-Binärdateien können die libbase-Funktionen verwenden. Weitere Informationen finden Sie unter sys/system_properties.h (libc), android-base/properties.h (libbase) und cutils/properties.h (libcutils).
Die Klasse android.os.SystemProperties bietet Methoden für Java-Systemeigenschaften.
Das rustutils::system_properties-Modul bietet Funktionen und Typen für Rust-Systemeigenschaften.
Anhang: Anbieterspezifische Properties hinzufügen
Partner (einschließlich Google-Mitarbeiter, die im Rahmen der Pixel-Entwicklung arbeiten) möchten hardwarespezifische (oder gerätespezifische) Systemeigenschaften definieren.
Anbieterspezifische Properties sind Partner-Properties, die nur für die eigene Hardware oder das eigene Gerät und nicht für die Plattform gelten. Da sie hardware- oder geräteabhängig sind, sollten sie in den Partitionen /vendor oder /odm verwendet werden.
Seit Project Treble wurden die Plattformeigenschaften und die Anbietereigenschaften vollständig getrennt, um Konflikte zu vermeiden. Im Folgenden wird beschrieben, wie Anbietereigenschaften definiert werden und welche Anbietereigenschaften immer verwendet werden müssen.
Namespace in Property- und Kontextnamen
Alle Anbietereigenschaften müssen mit einem der folgenden Präfixe beginnen, um Kollisionen zwischen ihnen und den Eigenschaften anderer Partitionen zu vermeiden.
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.
Hinweis: ro.hardware. ist als Präfix zulässig, aber nur aus Kompatibilitätsgründen.
Verwenden Sie sie nicht für normale Properties.
In den folgenden Beispielen wird jeweils eines der oben aufgeführten Präfixe verwendet:
vendor.display.primary_redpersist.vendor.faceauth.use_disk_cachero.odm.hardware.platform
Alle Kontexte für Anbietereigenschaften müssen mit vendor_ beginnen. Dies gilt auch aus Kompatibilitätsgründen. Beispiele:
vendor_radio_prop.vendor_faceauth_prop.vendor_usb_prop.
Die Benennung und Pflege von Properties liegt in der Verantwortung des Anbieters. Beachten Sie daher zusätzlich zu den Anforderungen an Anbieter-Namespaces das in Schritt 2 vorgeschlagene Format.
Anbieterspezifische SEPolicy-Regeln und property_contexts
Anbietereigenschaften können mit dem Makro vendor_internal_prop definiert werden. Lege die von dir definierten anbieterspezifischen Regeln in das Verzeichnis BOARD_VENDOR_SEPOLICY_DIRS.
Angenommen, Sie definieren in Coral eine Anbietereigenschaft für die Gesichtsauthentifizierung.
Fügen Sie in der BoardConfig.mk-Datei (oder in allen BoardConfig.mk-Includes) Folgendes ein:
BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy
Fügen Sie in der Datei device/google/coral-sepolicy/private/property.te Folgendes ein:
vendor_internal_prop(vendor_faceauth_prop)
Fügen Sie in der Datei device/google/coral-sepolicy/private/property_contexts Folgendes ein:
vendor.faceauth.trace u:object_r:vendor_faceauth_prop:s0 exact bool
Einschränkungen von Anbieter-Properties
Da die System- und Produktpartitionen nicht vom Anbieter abhängig sein dürfen, dürfen die Anbietereigenschaften niemals über die Partitionen system, system-ext oder product zugänglich sein.
Anhang: Vorhandene Properties umbenennen
Wenn Sie eine Property einstellen und zu einer neuen Property wechseln müssen, verwenden Sie Sysprop als APIs, um Ihre vorhandenen Properties umzubenennen. So wird die Abwärtskompatibilität aufrechterhalten, da sowohl der alte als auch der neue Name der Property angegeben wird. Sie können den bisherigen Namen im Feld legacy_prop_name in der Datei .sysprop festlegen. Die generierte API versucht, prop_name zu lesen, und verwendet legacy_prop_name, wenn prop_name nicht vorhanden ist.
Mit den folgenden Schritten wird beispielsweise awesome_feature_foo_enabled in foo.awesome_feature.enabled umbenannt.
In der foo.sysprop-Datei
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"
}
Im C++-Code
// 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);
Beachten Sie die folgenden Einschränkungen:
Erstens können Sie den Typ der Sysprop nicht ändern. Sie können ein
int-Attribut beispielsweise nicht in einstring-Attribut umwandeln, sondern lediglich den Namen ändern.Zweitens: Nur die Lese-API greift auf den alten Namen zurück. Die Write API greift nicht zurück. Wenn die Sysprop beschreibbar ist, können Sie sie nicht umbenennen.