Diese Seite bietet eine kanonische Methode zum Hinzufügen oder Definieren von Systemeigenschaften mit Richtlinien für die Refaktorierung vorhandener Systemeigenschaften. Achten Sie bei der Refaktorierung auf die Richtlinien, es sei denn, Sie haben eine Kompatibilitätsproblem, das etwas anderes vorgibt.
Schritt 1: Systemeigenschaft definieren
Wenn Sie eine Systemeigenschaft hinzufügen, geben Sie einen Namen für die Eigenschaft an und mit einem SELinux-Eigenschaftskontext. Wenn kein entsprechender Kontext vorhanden ist, erstellen Sie eine neue. Der Name wird beim Zugriff auf die Eigenschaft verwendet. die Property Kontext wird verwendet, um die Barrierefreiheit in Bezug auf SELinux zu steuern. Beliebige Namen String, aber AOSP empfiehlt, ein strukturiertes Format zu verwenden, um sie deutlich zu machen.
Property-Name
Verwenden Sie dieses Format mit snake_case-Groß-/Kleinschreibung:
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
Verwenden Sie entweder "" (ausgelassen), ro
(für nur einmal festgelegte Eigenschaften) oder persist
(für Attribute, die nach einem Neustart bestehen bleiben) für das Element prefix
.
Einschränkungen
Verwenden Sie ro
nur, wenn Sie sicher sind, dass prefix
nicht beschreibbar sein muss
zu erhalten. ** Geben Sie nicht das Präfix ro
an.** Verwenden Sie stattdessen sepolicy, um
macht prefix
schreibgeschützt, d. h., es kann nur von init
beschreibbar sein.
Verwenden Sie persist
nur, wenn Sie sicher sind, dass der Wert über
das Gerät neu startet und dass Sie
die Systemeigenschaften aufrufen können.
Google prüft streng die Systemeigenschaften, die entweder ro
oder persist
enthalten.
Eigenschaften.
Mit dem Begriff group
werden verwandte Properties zusammengefasst. Sie ist dazu gedacht,
ein Subsystemname sein, der audio
oder telephony
ähnelt. Nicht verwenden
mehrdeutige oder überlastete Begriffe wie sys
, system
, dev
, default
oder
config
In der Regel wird der Name des Domaintyps einer
Prozess mit exklusivem Lese- oder Schreibzugriff auf die Systemeigenschaften. Für
Für die Systemattribute, auf die der vold
-Prozess Schreibzugriff hat,
ist es üblich, vold
(den Namen des Domaintyps für den Prozess) als
Gruppenname.
Fügen Sie bei Bedarf subgroup
hinzu, um Properties weiter zu kategorisieren, aber vermeiden Sie
mehrdeutige oder überladene Begriffe zur Beschreibung dieses Elements. (Sie können auch
als ein subgroup
.)
Viele Gruppennamen wurden bereits definiert. Prüfen Sie die
system/sepolicy/private/property_contexts
-Datei und vorhandene Gruppennamen verwenden
anstatt neue zu erstellen. In der folgenden Tabelle finden Sie
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 definiert
Beispiel.
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
name
identifiziert ein Systemattribut innerhalb einer Gruppe.type
ist ein optionales Element, das den Typ oder Zweck der Systemeigenschaften. Anstatt Sysprop beispielsweise so zu benennen,audio.awesome_feature_enabled
oder nuraudio.awesome_feature
, benennen Sie ihn um inaudio.awesome_feature.enabled
, um den Typ und Intent der Systemeigenschaft widerzuspiegeln.
Es gibt keine spezifische Regel für den Typ. Das sind Nutzungsdaten Empfehlungen:
enabled
: wird verwendet, wenn der Typ eine boolesche Systemeigenschaft ist, die zum eine Funktion ein- oder ausschalten.config
: Verwenden Sie diese Option, wenn klargestellt werden soll, dass das Systemattribut keinen dynamischen Zustand des Systems darstellt; steht er für eine vorkonfigurierter 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 Einheiten handelt. von ms.
Beispiele:
persist.radio.multisim.config
drm.service.enabled
Property-Kontext
Das neue SELinux-Eigenschaftskontextschema ermöglicht eine detailliertere beschreibenden Namen. Ähnlich wie bei Property-Namen empfiehlt AOSP, im folgenden Format:
{group}[_{subgroup}]*_prop
Die Begriffe sind wie folgt definiert:
group
und subgroup
haben die oben definierte Bedeutung.
Beispiel für einen regulären Ausdruck: vold_config_prop
bedeutet beispielsweise
Eigenschaften, bei denen es sich um Konfigurationen eines Anbieters handelt, die vom
vendor_init
, während vold_status_prop
oder nur vold_prop
für Unterkünfte steht
mit denen der aktuelle Status von vold
angezeigt wird.
Wählen Sie beim Benennen eines Property-Kontexts die Namen aus, die die allgemeine Verwendung von die Eigenschaften. Vermeiden Sie insbesondere die folgenden Arten von Begriffen:
- Begriffe, die zu allgemein und mehrdeutig erscheinen, z. B.
sys
,system
oderdefault
. - Begriffe, mit denen die Barrierefreiheit direkt codiert wird, z. B.
exported
,apponly
,ro
,public
,private
Ich bevorzuge Namen wie vold_config_prop
zu 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 (, ) verwendet.Die 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
und geben es als property_contexts
-Datei an. 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 umfassenden Zugriff hat zu App-Fehlern und Sicherheitslücken geführt. Erwägen Sie sollten Sie die folgenden Fragen stellen:
- Muss diese Systemeigenschaft beibehalten werden? (wenn 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 als Tools für einen geeigneten Umfang für den Zugriff festlegen.
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. Nachher
Sie bestimmen, welches Maß an Zugänglichkeit erforderlich ist, und definieren Property-Kontexte.
unter system/sepolicy
, zusammen mit den zusätzlichen allow- und neverallow-Regeln
über die Lese- und
Schreibberechtigungen der Prozesse.
Definieren Sie zuerst den Attributkontext in system/sepolicy/public/property.te
-Datei. Wenn das Attribut systemintern ist, definieren Sie es in der
system/sepolicy/private/property.te
-Datei. Verwenden Sie eines der folgenden Formate:
die system_[accessibility]_prop([context])
-Makros, die die
Zugänglichkeit Ihrer Systemeigenschaft erforderlich ist. Dies ist 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 Attributkontext. set_prop
verwenden
und get_prop
, um Zugriff zu gewähren, entweder im
system/sepolicy/public/{domain}.te
oder system/sepolicy/private/{domain}.te
-Datei. Verwende nach Möglichkeit private
. public
ist nur geeignet, wenn das
Das set_prop
- oder get_prop
-Makro wirkt sich auf Domains außerhalb der Kerndomain aus.
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 „Niezulassen“-Regeln hinzufügen, um die Zugänglichkeit
durch das Makro bestimmt wird. Nehmen wir beispielsweise an, Sie haben
system_restricted_prop
, da Ihre Systemeigenschaften vom Anbieter gelesen werden müssen
Prozesse. Wenn der Lesezugriff nicht für alle Anbieterprozesse erforderlich ist
nur für bestimmte Prozesse (z. B. vendor_init
) erforderlich sind, dürfen nicht
der Anbieterprozesse,
die keinen Lesezugriff 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
ist die nieallow-Regel an eine bestimmte Domain gebunden. Für allgemeinere „Niezulassen“-Regeln verwenden Sie
allgemeine Domains wie diese erhalten:
system/sepolicy/private/property.te
system/sepolicy/private/coredomain.te
system/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. Also
{domain -coredomain -vendor_init}
bedeutet „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,
Property-Kontexte werden auf tatsächliche Properties angewendet. Fügen Sie dazu einen Eintrag zu
Die Datei property_contexts
, eine Datei, die die Zuordnung zwischen den
Property- und Property-Kontexte. In dieser Datei können Sie entweder einen einzelnen
Property oder ein Präfix für Properties, 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]
Sie können optional den Typ der Property angeben. Dabei kann es sich um einen der folgenden Typen handeln: Folgendes:
bool
int
uint
double
enum [list of possible values...]
string
(Verwenden Siestring
für Listeneigenschaften.)
Jedem Eintrag sollte nach Möglichkeit ein eigener Typ zugewiesen werden, da type
erzwungen beim Festlegen von property
. Das folgende Beispiel zeigt, wie ein
Zuordnung:
# 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
Wenn ein exakter Eintrag mit einem Präfixeintrag in Konflikt steht, wird der exakte Eintrag
Vorrang. Weitere Beispiele finden Sie unter system/sepolicy/private/property_contexts
.
Schritt 4: Stabilitätsanforderungen festlegen
Stabilität ist ein weiterer Aspekt der Systemeigenschaften. Sie unterscheidet sich Barrierefreiheit. Bei der Stabilität geht es darum, ob eine Systemeigenschaft in Zukunft geändert (z. B. umbenannt oder sogar entfernt). Dies ist Das ist besonders wichtig, da das Android-Betriebssystem modular wird. Bei Treble, dem System, Anbieter- und Produktpartitionen unabhängig voneinander aktualisiert werden können. Mit Einige Teile des Betriebssystems sind als aktualisierbare Module in APEXes modularisiert. oder APKs).
Wenn ein Systemattribut für die Verwendung in aktualisierbaren Softwarekomponenten vorgesehen ist, z. B. in allen System- und Anbieterpartitionen, muss sie stabil sein. Wenn es jedoch verwendet wird, z. B. innerhalb eines bestimmten Mainline-Moduls, können Sie seinen Namen, Typ-, Eigenschaftskontexte 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 je nach Gerät)? Wenn ja, muss sie stabil sein.
- Ist diese AOSP-definierte Systemeigenschaft zum Schreiben oder Lesen gedacht
Code (kein Prozess), der in nicht systemeigenen Partitionen wie
vendor.img
oderproduct.img
? Wenn ja, muss sie stabil sein. - Wird über Mainline-Module oder eine Mainline hinweg auf diese Systemeigenschaft zugegriffen und dem nicht aktualisierbaren Teil der Plattform? Wenn ja, muss sie stabil sein.
Definieren Sie für die stabilen Systemeigenschaften jedes Element formell als API und verwenden Sie die API. um auf die Systemeigenschaft zuzugreifen, wie unter Schritt 6:
Schritt 5: Eigenschaften bei der Erstellung festlegen
Legen Sie Eigenschaften zur Erstellungszeit mithilfe von Makefile-Variablen fest. Technisch gesehen sind die Werte
sind in {partition}/build.prop
integriert. Dann liest init
{partition}/build.prop
, um die Eigenschaften festzulegen. Es gibt zwei Arten solcher
Variablen: PRODUCT_{PARTITION}_PROPERTIES
und TARGET_{PARTITION}_PROP
.
PRODUCT_{PARTITION}_PROPERTIES
enthält eine Liste mit Attributwerten. Die Syntax
ist {prop}={value}
oder {prop}?={value}
.
{prop}={value}
ist eine normale Zuweisung, mit der sichergestellt wird, dass {prop}
auf
{value}
; pro Property ist nur eine solche Zuweisung möglich.
{prop}?={value}
ist eine optionale Aufgabe. {prop}
wird nur dann auf {value}
gesetzt, wenn
Es gibt keine {prop}={value}
-Aufgaben. Wenn mehrere optionale Zuweisungen
existieren, gewinnt der erste.
# 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
. 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
Initialisierungsdateien (in der Regel *.rc-Dateien) können Eigenschaften von ${prop}
oder
Mit ${prop:-default}
kann eine Aktion festgelegt werden, die ausgeführt wird, wenn eine Eigenschaft zu einer
Wert und kann 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 zu lesen oder
schreiben wir die Eigenschaften. Rufen Sie für weitere Details getprop --help
auf oder
setprop --help
.
$ 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 auch generierte
APIs, die Modulen über Grenzen hinweg zur Verfügung stehen, und die API-Stabilität gewährleisten. Hier ist ein
Beispiel für eine .sysprop
-Datei, ein Android.bp
-Modul und C++, Java- und Rust-Code
wenn Sie sie verwenden.
# 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 C/C++- oder Rust-Funktionen auf niedriger Ebene verwendet werden. oder Low-Level-Java-Methoden stehen Ihnen zur Verfügung.
libc
, libbase
und libcutils
bieten C++-Systemattributfunktionen. libc
verfügt über die zugrunde liegende API, während die Funktionen libbase
und libcutils
Wrapper. Verwenden Sie nach Möglichkeit die Sysprop-Funktionen libbase
. das sind die
und Host-Binärdateien können die libbase
-Funktionen verwenden. Weitere Informationen
Details, siehe 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 für Rust-Systemeigenschaften
und Typen.
Anhang: Anbieterspezifische Attribute hinzufügen
Partner (einschließlich Google-Mitarbeiter, die an der Pixel-Entwicklung beteiligt sind) wünschen sich
um hardwarespezifische (oder gerätespezifische) Systemeigenschaften zu definieren.
Anbieterspezifische Eigenschaften sind Eigenschaften des Partners,
die eigene Hardware oder ein Gerät
haben, nicht die Plattform. Da es sich um Hardware oder
abhängig ist, sind sie für die Verwendung in den Partitionen /vendor
oder /odm
vorgesehen.
Seit Project Treble sind die Plattformeigenschaften und die Anbietereigenschaften teilen, um Konflikte zu vermeiden. Im Folgenden wird beschrieben, wie Sie Definition der Anbietereigenschaften und gibt an, welche Anbietereigenschaften immer verwendet werden müssen.
Namespace für Attribut- und Kontextnamen
Alle Anbietereigenschaften müssen mit einem der folgenden Präfixe beginnen, um zu verhindern, und den Eigenschaften anderer Partitionen.
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_red
persist.vendor.faceauth.use_disk_cache
ro.odm.hardware.platform
Alle Kontexte von Anbietereigenschaften müssen mit vendor_
beginnen. Dies gilt auch für
Kompatibilität. Hier einige Beispiele:
vendor_radio_prop
.vendor_faceauth_prop
.vendor_usb_prop
.
Es liegt in der Verantwortung des Anbieters, die Eigenschaften zu benennen und zu verwalten. des in Schritt 2 vorgeschlagenen Formats, Anforderungen für Anbieter-Namespaces.
Anbieterspezifische SEPolicy-Regeln und property_contexts
Anbietereigenschaften können mit dem Makro vendor_internal_prop
definiert werden. Setzen Sie die
anbieterspezifischen Regeln, die Sie im Verzeichnis BOARD_VENDOR_SEPOLICY_DIRS
definieren.
Angenommen, Sie definieren die Faceauth-Eigenschaft des Anbieters in Coral.
Fügen Sie in der Datei BoardConfig.mk
(oder in einem beliebigen BoardConfig.mk
-Include) den Parameter
Folgendes:
BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy
Fügen Sie in der Datei device/google/coral-sepolicy/private/property.te
den Parameter
Folgendes:
vendor_internal_prop(vendor_faceauth_prop)
Fügen Sie in der Datei device/google/coral-sepolicy/private/property_contexts
den Parameter
Folgendes:
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,
Zulassen, dass auf die Anbietereigenschaften über system
, system-ext
oder
product
Partitionen.
Anhang: Vorhandene Attribute umbenennen
Wenn Sie eine Property verwerfen und in eine neue verschieben müssen, verwenden Sie Sysprop als APIs
um Ihre vorhandenen Properties umzubenennen. Dies wahrt die Abwärtskompatibilität,
indem Sie sowohl den alten Namen als auch den neuen Eigenschaftsnamen angeben. Insbesondere können Sie
Legen Sie den Legacy-Namen in der Datei .sysprop
im Feld legacy_prop_name
fest. Die
Die generierte API versucht, prop_name
zu lesen, und verwendet legacy_prop_name
, wenn
prop_name
ist nicht vorhanden.
Beispielsweise wird awesome_feature_foo_enabled
durch die folgenden Schritte umbenannt.
an foo.awesome_feature.enabled
.
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. Zum Beispiel können Sie nicht ein
int
-Objekt in einstring
-Objekt. Sie können nur den Namen ändern.Zweitens greift nur die Read API auf den alten Namen zurück. Die Write API kann keine Fallbacks. Wenn Sysprop beschreibbar ist, können Sie sie nicht umbenennen.