Auf dieser Seite finden Sie eine kanonische Methode zum Hinzufügen oder Definieren von Systemeigenschaften in Android sowie Richtlinien für das Refactoring 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, wählen Sie einen Namen für die Eigenschaft aus und ordnen Sie sie einem SELinux-Eigenschaftskontext zu. 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. 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-Groß-/Kleinschreibung:
[{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 nicht beschreibbar sein muss
zu erhalten. ** 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 streng die Systemeigenschaften, die entweder ro oder persist enthalten.
Eigenschaften.
Mit dem Begriff group werden verwandte Properties zusammengefasst. 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.
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 mehrere subgroup haben.
Viele Gruppennamen wurden bereits definiert. Überprü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
|
| Telefonie | 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 eine Systemeigenschaft innerhalb einer Gruppe.typeist ein optionales Element, das den Typ oder die Absicht der Systemeigenschaft verdeutlicht. Anstatt Sysprop beispielsweise so zu benennen,audio.awesome_feature_enabledoder nuraudio.awesome_feature, benennen Sie ihn um inaudio.awesome_feature.enabled, um den Typ und Intent 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 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: 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 Eigenschaften ermöglicht eine feinere Granularität und aussagekräftigere Namen. Ähnlich wie bei den Attributnamen wird in AOSP das folgende Format empfohlen:
{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 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 erscheinen, z. B.
sys,systemoderdefault. - Begriffe, mit denen die Barrierefreiheit direkt codiert wird, z. B.
exported,apponly,ro,public,private
Verwenden Sie Namen wie vold_config_prop anstelle von 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 | 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 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.
| Art der Barrierefreiheit | Bedeutung |
|---|---|
system_internal_prop |
Attribute, die nur in /system verwendet werden |
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 umfassenden Zugriff hat zu App-Fehlern und Sicherheitslücken geführt. Berücksichtigen Sie bei der Definition 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?
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. 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 für Prozesse.
Definieren Sie zuerst den Attributkontext in der Datei system/sepolicy/public/property.te. Wenn das Attribut systemintern ist, definieren Sie es in der
system/sepolicy/private/property.te-Datei. 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 Property-Kontext. Verwenden Sie Makros vom Typ set_prop und get_prop, um Zugriff zu gewähren, entweder in der Datei system/sepolicy/public/{domain}.te oder system/sepolicy/private/{domain}.te. 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 system/sepolicy/public/domain.te-Datei:
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 beschränken Sie den Lesezugriff:
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. 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 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.“
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 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:
boolintuintdoubleenum [list of possible values...]string(Verwenden Siestringfür Listeneigenschaften.)
Jedem Eintrag sollte nach Möglichkeit ein eigener Typ zugewiesen werden, da type
erzwungen, wenn property festgelegt wird. 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
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 werden kann (z. B. umbenannt oder sogar entfernt). 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 eine Systemeigenschaft für alle aktualisierbaren Softwarekomponenten verwendet werden soll, z. B. für System- und Anbieterpartitionen, muss sie stabil sein. Wenn sie jedoch nur in einem bestimmten Mainline-Modul verwendet wird, können Sie ihren Namen, Typ oder Property-Kontext ändern und sie 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)? Wenn ja, muss sie 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 greifen Sie über die API auf die Systemeigenschaft zu, wie in Schritt 6 erläutert.
Schritt 5: Eigenschaften bei 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 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 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. 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 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 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.
Funktionen und Methoden für Eigenschaften auf niedriger Ebene in C/C++, Java und Rust
Nach Möglichkeit Sysprop als API verwenden, auch wenn C/C++- oder Rust-Funktionen auf niedriger Ebene funktionieren oder Low-Level-Java-Methoden stehen Ihnen zur Verfügung.
libc, libbase und libcutils bieten C++-Systemeigenschaftsfunktionen. libc
verfügt über die zugrunde liegende API, während die Funktionen libbase und libcutils
Wrapper. 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
Details, siehe 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 Modul rustutils::system_properties bietet Funktionen für Rust-Systemeigenschaften
und Typen.
Anhang: Anbieterspezifische Attribute hinzufügen
Partner (einschließlich Google-Mitarbeiter, die im Rahmen der Pixel-Entwicklung arbeiten) möchten hardwarespezifische (oder gerätespezifische) Systemeigenschaften definieren.
Anbieterspezifische Eigenschaften sind Eigenschaften des Partners,
die eigene Hardware oder
ein Gerät nutzen, nicht die Plattform. Da sie hardware- oder geräteabhängig sind, sind sie für die Verwendung in den Partitionen /vendor oder /odm vorgesehen.
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 dient auch der Kompatibilität. 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. 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 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 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ä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 verwerfen und in eine neue verschieben 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. Insbesondere können Sie
Legen Sie den Legacy-Namen in der Datei .sysprop im Feld legacy_prop_name fest. Die generierte API versucht, prop_name zu lesen, und verwendet legacy_prop_name, wenn prop_name nicht vorhanden ist.
In 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 können Sie den Typ der Sysprop nicht ändern. Zum Beispiel können Sie nicht ein
int-Objekt in einstring-Objekt. Sie können nur den Namen ändern.Zweitens: Nur die Lese-API greift auf den alten Namen zurück. Die Write API kann keine Fallbacks. Wenn Sysprop beschreibbar ist, können Sie sie nicht umbenennen.