Diese Seite bietet eine kanonische Methode zum Hinzufügen oder Definieren von Systemeigenschaften in Android sowie Richtlinien für die Umgestaltung vorhandener Systemeigenschaften. Stellen Sie sicher, dass Sie bei der Umgestaltung die Richtlinien verwenden, es sei denn, Sie haben ein schwerwiegendes Kompatibilitätsproblem, das etwas anderes vorschreibt.
Schritt 1: Definieren der Systemeigenschaft
Wenn Sie eine Systemeigenschaft hinzufügen, legen Sie einen Namen für die Eigenschaft fest und verknüpfen Sie sie mit einem SELinux-Eigenschaftskontext. Wenn kein geeigneter vorhandener Kontext vorhanden ist, erstellen Sie einen neuen. Der Name wird beim Zugriff auf die Eigenschaft verwendet; Der Eigenschaftskontext wird verwendet, um die Zugänglichkeit in Bezug auf SELinux zu steuern. Namen können beliebige Zeichenfolgen sein, AOSP empfiehlt jedoch, ein strukturiertes Format zu verwenden, um sie klarer zu machen.
Name des Anwesens
Verwenden Sie dieses Format mit der Groß-/Kleinschreibung „snake_case“:
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
Verwenden Sie für das prefix
entweder „“ (weggelassen), ro
(für Eigenschaften, die nur einmal festgelegt werden) oder persist
(für Eigenschaften, die über Neustarts hinweg bestehen bleiben).
Vorbehalte
Verwenden Sie ro
nur, wenn Sie sicher sind, dass Sie kein prefix
mehr benötigen, um in Zukunft beschreibbar zu sein. ** Geben Sie nicht das Präfix ro
an.** Verlassen Sie sich stattdessen auf „sepolicy“, um prefix
schreibgeschützt zu machen (mit anderen Worten, nur von init
beschreibbar).
Verwenden Sie persist
nur, wenn Sie sicher sind, dass der Wert über Neustarts hinweg beibehalten werden muss und dass die Verwendung der Systemeigenschaften Ihre einzige Option ist. (Einzelheiten finden Sie im Abschnitt „Vorbereitung“ .)
Google überprüft streng die Systemeigenschaften, die entweder ro
oder persist
Eigenschaften haben.
Der Begriff group
wird verwendet, um zusammengehörige Eigenschaften zusammenzufassen. Es soll ein Subsystemname sein, der in seiner Verwendung audio
oder telephony
ähnelt. Verwenden Sie keine mehrdeutigen oder überladenen Begriffe wie sys
, system
, dev
, default
oder config
.
Es ist üblich, den Namen des Domänentyps eines Prozesses zu verwenden, der exklusiven Lese- oder Schreibzugriff auf die Systemeigenschaften hat. Beispielsweise ist es für die Systemeigenschaften, auf die der vold
Prozess Schreibzugriff hat, üblich, vold
(den Namen des Domänentyps für den Prozess) als Gruppennamen zu verwenden.
Fügen Sie bei Bedarf subgroup
hinzu, um Eigenschaften weiter zu kategorisieren. Vermeiden Sie jedoch mehrdeutige oder überladene Begriffe zur Beschreibung dieses Elements. (Sie können auch mehr als eine subgroup
haben.)
Viele Gruppennamen sind bereits definiert. Überprü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 der Kernel-Cmdline | boot |
Sysprops, die einen Build identifizieren | build |
Telefonie bezogen | telephony |
audiobezogen | audio |
grafikbezogen | graphics |
vold bezogen | vold |
Im Folgenden wird die Verwendung von name
und type
im vorherigen Regex-Beispiel definiert.
[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]
name
identifiziert eine Systemeigenschaft innerhalb einer Gruppe.type
ist ein optionales Element, das den Typ oder die Absicht der Systemeigenschaft verdeutlicht. Anstatt beispielsweise ein Sysprop alsaudio.awesome_feature_enabled
“ oder nuraudio.awesome_feature
zu benennen, benennen Sie es in „audio.awesome_feature.enabled
“ um, um den Typ und die Absicht der Systemeigenschaft widerzuspiegeln.
Es gibt keine spezifische Regel, um welchen Typ es sich handeln muss. Dies sind Anwendungsempfehlungen:
-
enabled
: Verwenden Sie diese Option, wenn es sich bei dem Typ um eine boolesche Systemeigenschaft handelt, die zum Aktivieren oder Deaktivieren einer Funktion verwendet wird. -
config
: Verwenden Sie diese Option, wenn klargestellt werden soll, dass die Systemeigenschaft keinen dynamischen Zustand des Systems darstellt. Es stellt einen vorkonfigurierten Wert dar (z. B. ein schreibgeschütztes Ding). -
List
: Verwenden Sie diese Option, wenn es sich um eine Systemeigenschaft handelt, deren Wert eine Liste ist. -
Timeoutmillis
: Verwenden Sie diese Option, wenn es sich um eine Systemeigenschaft für einen Timeout-Wert in Einheiten von ms handelt.
Beispiele:
-
persist.radio.multisim.config
-
drm.service.enabled
Immobilienkontext
Das neue SELinux-Eigenschaftskontextschema ermöglicht eine feinere Granularität und aussagekräftigere Namen. Ähnlich wie bei Eigenschaftsnamen empfiehlt AOSP das folgende Format:
{group}[_{subgroup}]*_prop
Die Begriffe sind wie folgt definiert:
group
und subgroup
haben dieselbe Bedeutung wie für die vorherige Beispiel-Regex definiert. Beispielsweise bezeichnet vold_config_prop
Eigenschaften, die Konfigurationen eines Anbieters sind und von vendor_init
festgelegt werden sollen, während vold_status_prop
oder einfach nur vold_prop
Eigenschaften bezeichnet, die den aktuellen Status von vold
offenlegen sollen.
Wählen Sie beim Benennen eines Eigenschaftskontexts Namen aus, die die allgemeine Verwendung der Eigenschaften widerspiegeln. Vermeiden Sie insbesondere die folgenden Arten von Begriffen:
- Begriffe, die zu allgemein und mehrdeutig erscheinen, wie etwa
sys
,system
,default
. - Begriffe, die die Barrierefreiheit direkt kodieren: wie
exported
,apponly
,ro
,public
,private
.
Bevorzugen Sie Namensverwendungen wie vold_config_prop
gegenüber exported_vold_prop
oder vold_vendor_writable_prop
usw.
Typ
Ein Eigenschaftstyp kann einer der folgenden sein, wie in der Tabelle aufgeführt.
Typ | Definition |
---|---|
Boolescher Wert | true oder 1 für wahr, false oder 0 für falsch |
Ganze Zahl | vorzeichenbehaftete 64-Bit-Ganzzahl |
Ganzzahl ohne Vorzeichen | vorzeichenlose 64-Bit-Ganzzahl |
Doppelt | Gleitkomma mit doppelter Genauigkeit |
Zeichenfolge | jede gültige UTF-8-Zeichenfolge |
Aufzählung | Werte können jede gültige UTF-8-Zeichenfolge ohne Leerzeichen sein |
Liste von oben | Als Trennzeichen wird ein Komma ( , ) verwendetDie Ganzzahlliste [1, 2, 3] wird als 1,2,3 gespeichert |
Intern werden alle Eigenschaften 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: Bestimmen der erforderlichen Barrierefreiheitsstufen
Es gibt vier Hilfsmakros, die eine Eigenschaft definieren.
Barrierefreiheitstyp | Bedeutung |
---|---|
system_internal_prop | Eigenschaften, 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 /system gelesen und nur von vendor_init geschrieben werden |
system_public_prop | Eigenschaften, die außerhalb /system gelesen und geschrieben werden |
Begrenzen Sie den Zugriff auf Systemeigenschaften so eng wie möglich. In der Vergangenheit hat ein breiter Zugriff zu App-Abstürzen und Sicherheitslücken geführt. Berücksichtigen Sie bei der Festlegung des Umfangs die folgenden Fragen:
- Muss diese Systemeigenschaft beibehalten werden? (Wenn ja warum?)
- Welcher Prozess sollte Lesezugriff auf diese Eigenschaft haben?
- Welcher Prozess soll Schreibzugriff auf diese Eigenschaft haben?
Nutzen Sie die vorstehenden Fragen und den folgenden Entscheidungsbaum als Hilfsmittel zur Bestimmung eines geeigneten Zugriffsbereichs.
Abbildung 1. Entscheidungsbaum zur Bestimmung des Zugriffsbereichs auf Systemeigenschaften
Schritt 3: Hinzufügen zu system/sepolicy
Beim Zugriff auf sysprop steuert SELinux die Zugänglichkeit von Prozessen. Nachdem Sie ermittelt haben, welche Zugriffsebene erforderlich ist, definieren Sie Eigenschaftskontexte unter system/sepolicy
sowie zusätzliche Allow- und Neverallow- Regeln darüber, was die Prozesse lesen oder schreiben dürfen (und was nicht).
Definieren Sie zunächst den Eigenschaftskontext in der Datei system/sepolicy/public/property.te
. Wenn die Eigenschaft systemintern ist, definieren Sie sie in der Datei system/sepolicy/private/property.te
. Verwenden Sie eines der system_[accessibility]_prop([context])
-Makros, das die für Ihre Systemeigenschaft erforderliche Zugänglichkeit bereitstellt. Dies ist 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 der Datei system/sepolicy/private/property.te
:
system_internal_prop(audio_baz_prop)
Zweitens gewähren Sie Lese- und (oder) Schreibzugriff auf den Eigenschaftskontext. Verwenden Sie die Makros 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
. Verwenden Sie nach Möglichkeit private
; public
ist nur geeignet, wenn das Makro set_prop
oder get_prop
Auswirkungen auf Domänen außerhalb der Kerndomäne hat.
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 fügen Sie einige Neverallow-Regeln hinzu, um die durch das Makro festgelegte Zugänglichkeit weiter zu reduzieren. Angenommen, Sie haben system_restricted_prop
verwendet, da Ihre Systemeigenschaften von Anbieterprozessen gelesen werden müssen. Wenn der Lesezugriff nicht für alle Anbieterprozesse erforderlich ist, sondern nur für eine bestimmte Gruppe von Prozessen (z. B. vendor_init
“), verbieten Sie die Anbieterprozesse, die den Lesezugriff nicht benötigen.
Verwenden Sie die folgende Syntax, um den Schreib- und Lesezugriff einzuschränken:
Um den Schreibzugriff einzuschränken:
neverallow [domain] [context]:property_service set;
Um den Lesezugriff einzuschränken:
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 Domäne gebunden ist. Für umfassendere Neverallow-Regeln verwenden Sie gegebenenfalls allgemeine Domänen wie diese:
-
system/sepolicy/private/property.te
-
system/sepolicy/private/coredomain.te
-
system/sepolicy/private/domain.te
Platzieren Sie in der Datei system/sepolicy/private/audio.te
Folgendes:
neverallow {
domain -init -audio
} {audio_foo_prop audio_bar_prop}:property_service set;
Platzieren Sie in der Datei system/sepolicy/private/property.te
Folgendes:
neverallow {
domain -coredomain -vendor_init
} audio_prop:file no_rw_file_perms;
Beachten Sie, dass {domain -coredomain}
alle Anbieterprozesse erfasst. {domain -coredomain -vendor_init}
bedeutet also „alle Anbieterprozesse außer vendor_init
“.
Verknüpfen Sie abschließend eine Systemeigenschaft mit dem Eigenschaftenkontext. Dadurch wird sichergestellt, dass der gewährte Zugriff und die Neverallow-Regeln, die auf Eigenschaftskontexte angewendet werden, auch auf tatsächliche Eigenschaften angewendet werden. Fügen Sie dazu einen Eintrag zur Datei property_contexts
hinzu, einer Datei, die die Zuordnung zwischen Systemeigenschaften und Eigenschaftskontexten beschreibt. In dieser Datei können Sie entweder eine einzelne Eigenschaft oder ein Präfix für Eigenschaften angeben, die einem Kontext zugeordnet werden sollen.
Dies ist die Syntax zum Zuordnen einer einzelnen Eigenschaft:
[property_name] u:object_r:[context_name]:s0 exact [type]
Dies ist die Syntax zum Zuordnen eines Präfixes:
[property_name_prefix] u:object_r:[context_name]:s0 prefix [type]
Sie können optional den Typ der Eigenschaft angeben, der einer der folgenden sein kann:
-
bool
-
int
-
uint
-
double
-
enum [list of possible values...]
-
string
(Verwenden Siestring
für Listeneigenschaften.)
Stellen Sie sicher, dass jeder Eintrag nach Möglichkeit seinen zugewiesenen Typ hat, da type
beim Festlegen property
erzwungen wird. Das folgende Beispiel zeigt, wie man ein Mapping schreibt:
# 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 genauer Eintrag und ein Präfix-Eintrag in Konflikt geraten, hat der genaue Eintrag Vorrang. Weitere Beispiele finden Sie unter system/sepolicy/private/property_contexts
.
Schritt 4: Stabilitätsanforderungen ermitteln
Stabilität ist ein weiterer Aspekt der Systemeigenschaften und unterscheidet sich von der Zugänglichkeit. Bei der Stabilität geht es darum, ob eine Systemeigenschaft in Zukunft geändert (z. B. umbenannt oder sogar entfernt) werden kann. Dies ist besonders wichtig, da das Android-Betriebssystem modular wird. Mit Treble können die System-, Hersteller- und Produktpartitionen unabhängig voneinander aktualisiert werden. Bei Mainline werden einige Teile des Betriebssystems als aktualisierbare Module modularisiert (in APEXes oder APKs).
Wenn eine Systemeigenschaft über aktualisierbare Softwareteile hinweg verwendet werden soll, beispielsweise über System- und Herstellerpartitionen hinweg, muss sie stabil sein. Wenn es jedoch beispielsweise nur innerhalb eines bestimmten Mainline-Moduls verwendet wird, können Sie seinen Namen, Typ oder Eigenschaftskontext ändern und es sogar entfernen.
Stellen Sie die folgenden Fragen, um die Stabilität einer Systemeigenschaft zu bestimmen:
- Soll diese Systemeigenschaft von Partnern konfiguriert werden (oder pro Gerät unterschiedlich konfiguriert werden)? Wenn ja, muss es stabil sein.
- Soll diese AOSP-definierte Systemeigenschaft in Code (nicht Prozess) geschrieben oder aus diesem gelesen werden, der in Nicht-Systempartitionen wie
vendor.img
“ oderproduct.img
vorhanden ist? Wenn ja, muss es stabil sein. - Wird auf diese Systemeigenschaft über alle Mainline-Module oder über ein Mainline-Modul und den nicht aktualisierbaren Teil der Plattform zugegriffen? Wenn ja, muss es stabil sein.
Definieren Sie für die stabilen Systemeigenschaften jede formal als API und verwenden Sie die API, um auf die Systemeigenschaft zuzugreifen, wie in Schritt 6 erläutert.
Schritt 5: Eigenschaften zur Erstellungszeit festlegen
Legen Sie Eigenschaften zur Erstellungszeit mit Makefile-Variablen fest. Technisch gesehen werden die Werte in {partition}/build.prop
gebacken. Dann liest init
{partition}/build.prop
um die Eigenschaften festzulegen. Es gibt zwei Sätze solcher Variablen: PRODUCT_{PARTITION}_PROPERTIES
und TARGET_{PARTITION}_PROP
.
PRODUCT_{PARTITION}_PROPERTIES
enthält eine Liste von Eigenschaftswerten. Die Syntax lautet {prop}={value}
oder {prop}?={value}
.
{prop}={value}
ist eine normale Zuweisung, die sicherstellt, dass {prop}
auf {value}
gesetzt ist; Pro einzelnem Objekt ist nur eine solche Zuordnung möglich.
{prop}?={value}
ist eine optionale Zuweisung; {prop}
wird nur dann auf {value}
gesetzt, wenn keine {prop}={value}
-Zuweisungen vorhanden sind. Wenn mehrere optionale Aufgaben vorhanden sind, gewinnt die 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
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 Einzelheiten finden Sie unter build/make/core/sysprop.mk
.
Schritt 6: Zur Laufzeit auf Eigenschaften zugreifen
Natürlich können Eigenschaften zur Laufzeit gelesen und geschrieben werden.
Init-Skripte
Init-Skriptdateien (normalerweise *.rc-Dateien) können eine Eigenschaft mit ${prop}
oder ${prop:-default}
lesen, eine Aktion festlegen, die immer dann ausgeführt wird, wenn eine Eigenschaft einen bestimmten Wert annimmt, und die Eigenschaften mit setprop
schreiben Befehl.
# 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}
getprop- und setprop-Shell-Befehle
Sie können die Shell-Befehle getprop
bzw. setprop
verwenden, um die Eigenschaften zu lesen oder zu schreiben. Für weitere Details rufen Sie 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. Durch das Festlegen scope
mit Public
werden generierte APIs auch über Grenzen hinweg für Module verfügbar gemacht und die API-Stabilität sichergestellt. Hier ist ein Beispiel einer .sysprop
Datei, eines Android.bp
Moduls und 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 .
Eigenschaftenfunktionen und -methoden auf niedriger Ebene 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++-Systemeigenschaftenfunktionen. libc
verfügt über die zugrunde liegende API, während die Funktionen libbase
und libcutils
Wrapper sind. Wenn möglich, verwenden Sie die libbase
Sysprop-Funktionen. Sie sind am bequemsten und Host-Binärdateien können die libbase
Funktionen verwenden. Weitere Einzelheiten finden Sie unter sys/system_properties.h
( libc
), android-base/properties.h
( libbase
) und cutils/properties.h
( libcutils
).
Die Klasse android.os.SystemProperties
bietet Java-Systemeigenschaftenmethoden.
Das Modul rustutils::system_properties
bietet Funktionen und Typen von Rust-Systemeigenschaften.
Anhang: Hinzufügen herstellerspezifischer Eigenschaften
Partner (einschließlich Google-Mitarbeiter, die im Kontext der Pixel-Entwicklung arbeiten) möchten hardwarespezifische (oder gerätespezifische) Systemeigenschaften definieren. Anbieterspezifische Eigenschaften sind Partnereigenschaften, die nur für die eigene Hardware oder das eigene Gerät und nicht für die Plattform gelten. Da diese hardware- oder geräteabhängig sind, sollten sie innerhalb der /vendor
oder /odm
Partitionen verwendet werden.
Seit Project Treble sind die Plattformeigenschaften und die Anbietereigenschaften vollständig getrennt, um Konflikte zwischen ihnen zu vermeiden. Im Folgenden wird beschrieben, wie Sie Anbietereigenschaften definieren und welche Anbietereigenschaften immer verwendet werden müssen.
Namespace für Eigenschafts- und Kontextnamen
Alle Herstellereigenschaften müssen mit einem der folgenden Präfixe beginnen, um Kollisionen zwischen ihnen und den Eigenschaften anderer Partitionen zu verhindern.
-
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.
ist als Präfix zulässig, jedoch nur aus Kompatibilitätsgründen. Verwenden Sie es nicht für normale Immobilien.
Die folgenden Beispiele verwenden alle eines der oben aufgeführten Präfixe:
-
vendor.display.primary_red
-
persist.vendor.faceauth.use_disk_cache
-
ro.odm.hardware.platform
Alle Anbietereigenschaftskontexte müssen mit vendor_
beginnen. Dies dient auch der Kompatibilität. Beispiele hierfür sind:
-
vendor_radio_prop
. -
vendor_faceauth_prop
. -
vendor_usb_prop
.
Es liegt in der Verantwortung des Anbieters, Eigenschaften zu benennen und zu verwalten. Befolgen Sie daher zusätzlich zu den Anbieter-Namespace-Anforderungen das in Schritt 2 vorgeschlagene Format.
Herstellerspezifische SEPolicy-Regeln und Property_Contexts
Anbietereigenschaften können mit dem Makro vendor_internal_prop
definiert werden. Legen Sie die von Ihnen definierten herstellerspezifischen Regeln im Verzeichnis BOARD_VENDOR_SEPOLICY_DIRS
ab. Angenommen, Sie definieren eine Vendor-Faceauth-Eigenschaft in Coral.
Geben Sie in der Datei BoardConfig.mk
(oder in einem beliebigen BoardConfig.mk
Include) Folgendes ein:
BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy
Geben Sie in der Datei device/google/coral-sepolicy/private/property.te
Folgendes ein:
vendor_internal_prop(vendor_faceauth_prop)
Geben 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 der Anbietereigenschaften
Da die System- und Produktpartitionen nicht vom Anbieter abhängen können, erlauben Sie niemals den Zugriff auf die Anbietereigenschaften von den system
, system-ext
oder product
aus.
Anhang: Vorhandene Eigenschaften umbenennen
Wenn Sie eine Eigenschaft verwerfen und auf eine neue umstellen müssen, verwenden Sie Sysprop als APIs, um Ihre vorhandenen Eigenschaften umzubenennen. Dadurch wird die Abwärtskompatibilität gewahrt, indem sowohl der alte Name als auch der neue Eigenschaftsname angegeben werden. Insbesondere können Sie den Legacy-Namen über das Feld legacy_prop_name
in der .sysprop
Datei festlegen. Die generierte API versucht, prop_name
zu lesen und verwendet legacy_prop_name
, wenn prop_name
nicht vorhanden ist.
Die folgenden Schritte benennen beispielsweise awesome_feature_foo_enabled
in foo.awesome_feature.enabled
um.
In der foo.sysprop
Datei
module: "android.sysprop.foo"
owner: Platform
prop {
api_name: "is_awesome_feature_enabled"
type: Boolean
scope: Public
access: Readonly
prop_name: "foo.awesome_feature.enabled"
legacy_prop_name: "awesome_feature_foo_enabled"
}
Im C++-Code
// is_awesome_feature_enabled() reads "foo.awesome_feature.enabled".
// If it doesn't exist, reads "awesome_feature_foo_enabled" instead
using android::sysprop::foo;
bool enabled = foo::is_awesome_feature_enabled().value_or(false);
Beachten Sie die folgenden Einschränkungen:
Erstens können Sie den Typ des Sysprops nicht ändern. Beispielsweise können Sie eine
int
Requisite nicht in einestring
Requisite umwandeln. Sie können nur den Namen ändern.Zweitens greift nur die Lese-API auf den Legacy-Namen zurück. Die Schreib-API greift nicht zurück. Wenn das Sysprop beschreibbar ist, können Sie es nicht umbenennen.