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 ein Systemattribut hinzufügen, legen Sie einen Namen für das Attribut fest und verknüpfen es mit einem SELinux-Attributkontext. 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. 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 Systemeigenschaften, auf die der Prozess vold Schreibzugriff hat, wird beispielsweise häufig 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. In der folgenden Tabelle finden Sie 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
|
| Telefonie | telephony |
| Audio | 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 eine Systemeigenschaft innerhalb einer Gruppe.typeist ein optionales Element, das den Typ oder die Absicht der Systemeigenschaft verdeutlicht. Benennen Sie ein Systemattribut beispielsweise nichtaudio.awesome_feature_enabledoder einfachaudio.awesome_feature, sondernaudio.awesome_feature.enabled, um den Typ und die Absicht der Systemeigenschaft 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 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: Verwenden Sie diesen Wert, 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-Kontextschema für Properties ermöglicht eine feinere Granularität und aussagekräftigere Namen. Ähnlich wie bei Eigenschaftsnamen wird in AOSP das folgende Format empfohlen:
{group}[_{subgroup}]*_prop
Die Begriffe sind so 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 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 für einen Property-Kontext Namen aus, die die allgemeine Verwendung der Properties widerspiegeln. Vermeiden Sie insbesondere die folgenden Arten von Begriffen:
- Begriffe, die zu allgemein und mehrdeutig sind, z. B.
sys,system,default. - 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 | Vorzeichenlose 64-Bit-Ganzzahl |
| Double | Gleitkommazahl mit doppelter Genauigkeit |
| String | beliebiger gültiger UTF-8-String |
| enum | Werte können beliebige gültige UTF-8-Strings ohne Leerzeichen sein. |
| Liste der oben genannten | Als Trennzeichen wird ein Komma (,) verwendet.Die 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 Bedienungshilfen festlegen
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 |
Eigenschaften, 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 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, 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 für die system/sepolicy/private/property.te-Datei:
system_internal_prop(audio_baz_prop)
Zweitens: Gewähren Sie Lese- und (oder) Schreibzugriff auf den Attributkontext. Verwenden Sie set_prop- und get_prop-Makros, um den Zugriff entweder 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 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, weil Ihre Systemeigenschaften von Anbieterprozessen gelesen werden müssen. Wenn der Lesezugriff nicht für alle Anbieterprozesse erforderlich ist, sondern nur für bestimmte Prozesse (z. B. vendor_init), sperren Sie die Anbieterprozesse, für die der Lesezugriff nicht erforderlich ist.
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 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 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.“
Verknüpfen Sie abschließend eine Systemeigenschaft mit dem Property-Kontext. So wird sichergestellt, dass der gewährte Zugriff und die „neverallow“-Regeln, die auf Property-Kontexte angewendet werden, auf die tatsächlichen 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.
Dies ist die Syntax für die Zuordnung einer einzelnen Eigenschaft:
[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 nach Möglichkeit jedem Eintrag ein bestimmter Typ zugewiesen ist, da beim Festlegen von property type 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 das Android-Betriebssystem modular wird. Mit Treble können die System-, Anbieter- und 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 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 sich die folgenden Fragen, um die Stabilität einer Systemeigenschaft zu bestimmen:
- 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? Wenn ja, muss sie 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 zur Erstellungszeit mithilfe von 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 mit Attributwerten. 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 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 gesendet 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
In Init-Scriptdateien (normalerweise *.rc-Dateien) können Eigenschaften mit ${prop} oder ${prop:-default} gelesen, eine Aktion festgelegt werden, die ausgeführt wird, wenn eine Eigenschaft einen bestimmten Wert erhält, und die Eigenschaften mit dem Befehl setprop geschrieben werden.
# 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 mit Public festlegen, werden generierte APIs auch über Grenzen hinweg für Module verfügbar. Dies gewährleistet die API-Stabilität. 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 ist 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 findest du 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 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.
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 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. Hier einige 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 vendor_internal_prop-Makro 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 Attribute 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 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"
}
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. Du kannst beispielsweise kein
int-Objekt in einstring-Objekt umwandeln. Du kannst nur 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.