Systemeigenschaften hinzufügen

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 nur audio.awesome_feature, benennen Sie ihn um in audio.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 oder default.
  • 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.

Entscheidungsbaum zur Bestimmung des Zugriffsumfangs

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 Sie string 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 oder product.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 ein string-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.