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. Verwenden Sie bei der Refaktorierung die Richtlinien, sofern kein schwerwiegendes Kompatibilitätsproblem vorliegt, das etwas anderes vorsieht.
Schritt 1: Systemeigenschaft definieren
Wenn Sie ein Systemattribut hinzufügen, legen Sie einen Namen für das Attribut fest und verknüpfen es mit einem SELinux-Attributkontext. Wenn kein entsprechender Kontext vorhanden ist, erstellen Sie einen neuen. Der Name wird beim Zugriff auf das Attribut verwendet. Mit dem Attributkontext wird die Barrierefreiheit in Bezug auf SELinux gesteuert. Namen können beliebige Strings sein, AOSP empfiehlt jedoch, ein strukturiertes Format zu verwenden, um sie klar zu machen.
Property-Name
Verwenden Sie dieses Format mit snake_case-Groß-/Kleinschreibung:
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
Verwenden Sie für das Element prefix entweder „“ (ausgelassen), ro (für Attribute, die nur einmal festgelegt werden) oder persist (für Attribute, die nach einem Neustart bestehen 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 durch init beschreibbar.
Verwenden Sie persist nur, wenn Sie sicher sind, dass der Wert bei Neustarts beibehalten werden muss und dass die Verwendung der Systemeigenschaften die einzige Option ist.
Google überprüft strikt die Systemattribute mit den Attributen ro oder persist.
Mit dem Begriff group werden verwandte Properties zusammengefasst. Er sollte ein Subsystemname sein, der in etwa audio oder telephony verwendet. Verwenden Sie keine mehrdeutigen oder überlasteten Begriffe wie sys, system, dev, default oder config.
Üblicherweise wird der Name des Domaintyps eines Prozesses verwendet, der exklusiven Lese- oder Schreibzugriff auf die Systemattribute 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 Attribute weiter zu kategorisieren, aber vermeiden Sie mehrdeutige oder überlastete Begriffe zur Beschreibung dieses Elements. (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-bezogen | bluetooth |
| Sysprops aus Kernel-Cmdline | boot |
| Sysprops, die einen Build identifizieren | build
|
| Telefoniebezogen | telephony |
| Audiobezogen | audio |
| Grafiken | graphics |
| zu vold | vold |
Im Folgenden wird die Verwendung von name und type im vorherigen Regex-Beispiel definiert.
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
nameidentifiziert ein Systemattribut innerhalb einer Gruppe.typeist ein optionales Element, das den Typ oder Zweck des Systemattributs 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 spezielle Regel für den Typ. Dies sind Nutzungsempfehlungen:
enabled: wird verwendet, wenn der Typ eine boolesche Systemeigenschaft ist, mit der eine Funktion aktiviert oder deaktiviert wird.config: Verwenden Sie diese Option, wenn klargestellt werden soll, dass das Systemattribut keinen dynamischen Zustand des Systems darstellt. Es repräsentiert einen vorkonfigurierten Wert (z. B. ein schreibgeschütztes Ding).List: Wird verwendet, wenn es sich um eine Systemeigenschaft handelt, deren Wert eine Liste ist.Timeoutmillis: Wird verwendet, wenn es sich um ein Systemattribut für einen Zeitüberschreitungswert in ms handelt.
Beispiele:
persist.radio.multisim.configdrm.service.enabled
Property-Kontext
Das neue SELinux-Attributkontextschema ermöglicht eine detailliertere und aussagekräftigere Bezeichnung. Ähnlich wie bei Attributnamen empfiehlt AOSP das folgende Format:
{group}[_{subgroup}]*_prop
Die Begriffe sind wie folgt definiert:
group und subgroup haben die gleiche Bedeutung, wie sie für den vorherigen Beispiel-Regex definiert wurde. Beispielsweise steht vold_config_prop für Attribute, bei denen es sich um Konfigurationen eines Anbieters handelt, die von vendor_init festgelegt werden sollen, während vold_status_prop oder nur vold_prop für Attribute 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.
Bevorzugen Sie Namensverwendungen wie vold_config_prop in exported_vold_prop oder vold_vendor_writable_prop.
Typ
Ein Attributtyp kann einer der folgenden sein, wie in der Tabelle aufgeführt.
| Typ | 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 ein beliebiger gültiger UTF-8-String ohne Leerzeichen sein |
| Liste oben | Als Trennzeichen wird ein Komma (,) verwendetDie Ganzzahlliste [1, 2, 3] wird als 1,2,3 gespeichert |
Intern werden alle Eigenschaften als Zeichenfolgen 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 Bedienungshilfen festlegen
Es gibt vier Hilfsmakros, die eine Eigenschaft definieren.
| Bedienungshilfen-Typ | Bedeutung |
|---|---|
system_internal_prop |
Attribute, die nur in /system verwendet werden |
system_restricted_prop |
Attribute, die außerhalb von /system gelesen, aber nicht geschrieben werden |
system_vendor_config_prop |
Attribute, 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 genau wie möglich. In der Vergangenheit hat ein umfassender Zugriff zu App-Fehlern und Sicherheitslücken geführt. Berücksichtigen Sie beim Festlegen des Umfangs die folgenden Fragen:
- Muss diese Systemeigenschaft beibehalten werden? (wenn ja, warum?)
- Welcher Prozess sollte Lesezugriff auf diese Property haben?
- Welcher Prozess sollte Schreibzugriff auf diese Property haben?
Orientieren Sie sich an den vorherigen Fragen und dem folgenden Entscheidungsbaum, um den geeigneten Umfang für den Zugriff zu bestimmen.
Abbildung 1: Entscheidungsbaum zur Bestimmung des Umfangs des Zugriffs auf Systemeigenschaften
Schritt 3: Zu system/sepolicy hinzufügen
Beim Zugriff auf Sysprop steuert SELinux die Zugänglichkeit von Prozessen. Nachdem Sie festgelegt haben, welcher Grad an Zugriff erforderlich ist, definieren Sie Attributkontexte unter system/sepolicy sowie zusätzliche allow- und neverallow-Regeln darüber, welche Lese- oder Schreibberechtigungen die Prozesse haben.
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, mit denen die für Ihre Systemeigenschaft erforderliche Barrierefreiheit bereitgestellt wird. Hier ein Beispiel für die Datei system/sepolicy/public/property.te:
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 Attributkontext. 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 Datei system/sepolicy/private/audio.te:
set_prop(audio, audio_foo_prop)
set_prop(audio, audio_bar_prop)
Beispiel in der Datei system/sepolicy/public/domain.te:
get_prop(domain, audio_bar_prop)
Drittens sollten Sie einige „Neverallow“-Regeln hinzufügen, um die durch das Makro festgelegte Zugänglichkeit weiter zu reduzieren. 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 schränken Sie den Schreibzugriff ein:
neverallow [domain] [context]:property_service set;
So schränken Sie den Lesezugriff ein:
neverallow [domain] [context]:file no_rw_file_perms;
Fügen Sie der Datei system/sepolicy/private/{domain}.te nie-allow-Regeln hinzu, wenn die Regel an eine bestimmte Domain gebunden ist. Verwenden Sie bei allgemeineren „Niezulassen-Regeln“ nach Bedarf allgemeine Domains wie diese:
system/sepolicy/private/property.tesystem/sepolicy/private/coredomain.tesystem/sepolicy/private/domain.te
Fügen Sie Folgendes in die Datei system/sepolicy/private/audio.te ein:
neverallow {
domain -init -audio
} {audio_foo_prop audio_bar_prop}:property_service set;
Fügen Sie Folgendes in die Datei system/sepolicy/private/property.te ein:
neverallow {
domain -coredomain -vendor_init
} audio_prop:file no_rw_file_perms;
In {domain -coredomain} werden alle Anbieterprozesse erfasst. {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. Dazu fügen Sie der Datei property_contexts einen Eintrag hinzu. Diese Datei enthält eine Beschreibung der Zuordnung zwischen Systemattributen und Attributkontexten. In dieser Datei können Sie entweder ein einzelnes Attribut oder ein Präfix für Attribute angeben, die einem Kontext zugeordnet werden sollen.
Dies ist die Syntax für die Zuordnung einer einzelnen Eigenschaft:
[property_name] u:object_r:[context_name]:s0 exact [type]
Dies ist die Syntax für die Zuordnung eines Präfixes:
[property_name_prefix] u:object_r:[context_name]:s0 prefix [type]
Optional können Sie den Typ der Property angeben. Dabei kann es sich um einen der folgenden Typen handeln:
boolintuintdoubleenum [list of possible values...]string(Verwenden Siestringfür Listeneigenschaften.)
Jedem Eintrag sollte nach Möglichkeit ein eigener Typ zugewiesen werden, da beim Festlegen von property type erzwungen wird. Das folgende Beispiel zeigt, 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 Konflikten zwischen einem exakten Eintrag und einem Präfixeintrag hat der exakte Eintrag Vorrang. Weitere Beispiele finden Sie unter system/sepolicy/private/property_contexts.
Schritt 4: Stabilitätsanforderungen festlegen
Die Stabilität ist ein weiterer Aspekt der Systemeigenschaften und unterscheidet sich von der Barrierefreiheit. Bei der Stabilität geht es darum, ob eine Systemeigenschaft in Zukunft geändert (z. B. umbenannt oder sogar entfernt) werden kann. Das ist besonders wichtig, da das Android-Betriebssystem modular wird. Mit Treble können das System, der Anbieter und die Produktpartitionen unabhängig voneinander aktualisiert werden. Bei Mainline werden einige Teile des Betriebssystems als aktualisierbare Module (in APEXes oder APKs) modularisiert.
Wenn eine Systemeigenschaft für aktualisierbare Softwareelemente verwendet werden soll, z. B. über System- und Anbieterpartitionen, muss sie stabil sein. Wenn sie jedoch nur in einem bestimmten Mainline-Modul verwendet wird, können Sie den Namen, den Typ oder die Eigenschaftskontexte ändern und sogar entfernen.
Stellen Sie die folgenden Fragen, um die Stabilität einer Systemeigenschaft zu ermitteln:
- Ist diese Systemeigenschaft für die Konfiguration durch Partner vorgesehen (oder für jedes Gerät anders)? Wenn ja, muss sie stabil sein.
- Soll diese AOSP-definierte Systemeigenschaft in Code (nicht Prozess) geschrieben oder daraus gelesen werden, der in Nicht-Systempartitionen wie
vendor.imgoderproduct.imgvorhanden ist? Wenn ja, muss sie stabil sein. - Wird über Mainline-Module oder ein Mainline-Modul und den nicht aktualisierbaren Teil der Plattform auf diese Systemeigenschaft zugegriffen? Wenn ja, muss sie stabil sein.
Definieren Sie für die stabilen Systemeigenschaften jedes dieser Elemente formal als API und verwenden Sie die API, um auf die Systemeigenschaften zuzugreifen, wie in Schritt 6 erläutert.
Schritt 5: Eigenschaften bei der Erstellung festlegen
Legen Sie Eigenschaften zur Erstellungszeit mithilfe von Makefile-Variablen fest. Technisch gesehen sind die Werte in {partition}/build.prop eingebunden. init liest dann {partition}/build.prop, um die Attribute festzulegen. Es gibt zwei Sätze solcher Variablen: PRODUCT_{PARTITION}_PROPERTIES und TARGET_{PARTITION}_PROP.
PRODUCT_{PARTITION}_PROPERTIES enthält eine Liste mit Attributwerten. Die Syntax lautet {prop}={value} oder {prop}?={value}.
{prop}={value} ist eine normale Zuweisung, die sicherstellt, dass {prop} auf {value} gesetzt ist. Pro Attribut ist nur eine solche Zuweisung möglich.
{prop}?={value} ist eine optionale Zuweisung. {prop} wird nur auf {value} gesetzt, wenn keine {prop}={value}-Zuweisungen vorhanden sind. Wenn mehrere optionale Zuweisungen vorhanden sind, erhält die erste Zuweisungen.
# 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: Während der Laufzeit auf Attribute zugreifen
Attribute können während der Laufzeit gelesen und geschrieben werden.
Initialisierungsskripte
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 eine Eigenschaft 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 bzw. setprop verwenden, um die Attribute 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 eine automatisch generierte API verwenden, die konkret und typisiert sind. Wenn Sie scope mit Public festlegen, werden generierte APIs auch über Grenzen hinweg für Module verfügbar. Dadurch wird die API-Stabilität sichergestellt. Hier sehen Sie ein Beispiel für eine .sysprop-Datei, ein Android.bp-Modul sowie C++-, Java- und Rust-Code, der diese verwendet.
# 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-Attributfunktionen und -methoden für C/C++, Java und Rust
Verwenden Sie nach Möglichkeit Sysprop als API, auch wenn Ihnen Low-Level-C/C++- oder Rust-Funktionen oder Low-Level-Java-Methoden zur Verfügung stehen.
libc, libbase und libcutils bieten C++-Systemattributfunktionen. libc hat die zugrunde liegende API, während die Funktionen libbase und libcutils Wrapper sind. Verwenden Sie nach Möglichkeit die Sysprop-Funktionen libbase. Diese sind am praktischsten und Host-Binärdateien können die libbase-Funktionen verwenden. Weitere Informationen findest du unter sys/system_properties.h (libc), android-base/properties.h (libbase) und cutils/properties.h (libcutils).
Die android.os.SystemProperties-Klasse bietet Java-Systemattributmethoden.
Das Modul rustutils::system_properties bietet Funktionen und Typen von Rust-Systemeigenschaften.
Anhang: Anbieterspezifische Attribute hinzufügen
Partner (einschließlich Google-Mitarbeiter, die im Zusammenhang mit der Pixel-Entwicklung arbeiten) möchten hardwarespezifische (oder gerätespezifische) Systemeigenschaften definieren.
Anbieterspezifische Eigenschaften sind Partnereigenschaften, die für ihre eigene Hardware oder ihr eigenes Gerät und nicht für die Plattform spezifisch sind. Da diese hardware- oder geräteabhängig sind, sind sie für die Verwendung innerhalb der Partitionen /vendor oder /odm vorgesehen.
Seit Project Treble wurden die Plattform- und Anbietereigenschaften vollständig aufgeteilt, um Konflikte zu vermeiden. Im Folgenden wird beschrieben, wie Anbietereigenschaften definiert werden und welche Anbietereigenschaften immer verwendet werden müssen.
Namespace für Attribut- und Kontextnamen
Alle Anbieterattribute müssen mit einem der folgenden Präfixe beginnen, um einen Konflikt zwischen ihnen und den Attributen 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.
Beachten Sie, dass ro.hardware. als Präfix zulässig ist, aber nur aus Gründen der Kompatibilität.
Verwenden Sie es nicht für normale Properties.
In den folgenden Beispielen wird eines der oben aufgeführten Präfixe verwendet:
vendor.display.primary_redpersist.vendor.faceauth.use_disk_cachero.odm.hardware.platform
Alle Kontexte von Anbietereigenschaften müssen mit vendor_ beginnen. Dies gilt auch aus Kompatibilitätsgründen. Hier einige Beispiele:
vendor_radio_prop.vendor_faceauth_prop.vendor_usb_prop.
Der Anbieter ist für den Namen und die Verwaltung der Properties verantwortlich. 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. Legen Sie die von Ihnen definierten anbieterspezifischen Regeln im Verzeichnis BOARD_VENDOR_SEPOLICY_DIRS ab.
Angenommen, Sie definieren die Faceauth-Eigenschaft des Anbieters in Coral.
Fügen Sie Folgendes in die Datei BoardConfig.mk (oder in ein beliebiges BoardConfig.mk-Include) ein:
BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy
Geben Sie Folgendes in die Datei device/google/coral-sepolicy/private/property.te ein:
vendor_internal_prop(vendor_faceauth_prop)
Geben Sie Folgendes in die Datei device/google/coral-sepolicy/private/property_contexts ein:
vendor.faceauth.trace u:object_r:vendor_faceauth_prop:s0 exact bool
Einschränkungen der Anbietereigenschaften
Da die System- und Produktpartitionen nicht vom Anbieter abhängen können, sollten Sie niemals zulassen, dass über die Partitionen system, system-ext oder product auf die Anbietereigenschaften zugegriffen wird.
Anhang: Vorhandene Attribute umbenennen
Wenn Sie ein Attribut verwerfen und zu einem neuen verschieben müssen, können Sie Ihre vorhandenen Attribute mithilfe von Sysprop als APIs umbenennen. Dadurch bleibt die Abwärtskompatibilität erhalten, da sowohl der Legacy-Name als auch der neue Attributname angegeben werden. Insbesondere können Sie den Legacy-Namen über das 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 Datei foo.sysprop
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"
}
In 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 kann der Sysprop-Typ nicht geändert werden. Sie können ein
int-Attribut beispielsweise nicht in einstring-Attribut umwandeln, sondern nur den Namen ändern.Zweitens greift nur die Read API auf den alten Namen zurück. Die Write API greift nicht zurück. Wenn Sysprop beschreibbar ist, können Sie sie nicht umbenennen.