Systemeigenschaften hinzufügen

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 als audio.awesome_feature_enabled “ oder nur audio.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 ( , ) verwendet Die 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 Sie string 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 “ oder product.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 eine string 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.