Konfigurationsübersicht

AOSP bietet die folgenden Optionen zum Speichern von Konfigurationsinformationen auf einem Gerät:

  • Systemattribute
  • Gerätekonfiguration für den frühen Start
  • Eigenschaften der Hardwareabstraktionsschicht (HAL)
  • XML-Dateien für die Systemkonfiguration
  • Ressourcen-Overlays (statisch und Laufzeit)

Systemattribute

Systemattribute sind Schlüssel/Wert-Paare vom Typ „String“, die im globalen build.prop-Dictionary gespeichert sind. Systemeigenschaften sind systemweite Ressourcen, die einfach zu verwenden sind und einen geringen Leistungs-Overhead haben. Wenn Sie Systemattribute verwenden, ist keine Interprocess Communication (IPC) erforderlich, auch wenn ein Systemattribut von mehreren Prozessen gemeinsam genutzt wird. Systemeigenschaften ähneln jedoch globalen Variablen und können bei Missbrauch schädlich sein. Der Missbrauch von Systemeigenschaften kann zu Problemen wie Sicherheitslücken und dazu führen, dass Apps für Nutzer nicht mehr zugänglich sind. Bevor Sie Systemattribute zum Speichern von Konfigurationsinformationen verwenden, sollten Sie die anderen Konfigurationsoptionen in Betracht ziehen.

Weitere Informationen zu Systemeigenschaften finden Sie unter Systemeigenschaften hinzufügen.

Gerätekonfiguration für den frühen Start

In Android 17 und höher bietet der init_dev_config-Dienst Unterstützung für die Gerätekonfiguration und die Initialisierung von Systemeigenschaften. Dieser dynamische Architekturmechanismus wird automatisch in der frühen Startphase ausgeführt.

Wenn ein einzelnes System- oder Anbieterimage mehrere Hardwarevarianten unterstützen muss, können Konfigurationswerte nicht immer zur Build-Zeit fest codiert werden. Der init_dev_config-Dienst wird während der early-init-Phase direkt vor apexd-bootstrap ausgeführt. So können Anbieter den Hardwarestatus prüfen (z. B. anhand von Bootloader-Argumenten, frühzeitig eingebundenen Partitionen oder Hardwarekonfigurationstabellen) und Systemattribute dynamisch initialisieren, bevor abhängige Dienste und Bibliotheken initialisiert werden.

Dienstintegration und ‑lebenszyklus

Der Dienst init_dev_config ist standardmäßig im System init.rc definiert und wird synchron während early-init vor apexd-bootstrap ausgeführt. Integratoren müssen keinen neuen init-Dienst deklarieren.

Stattdessen wird die Pfaderweiterung für den ausführbaren Pfad des vorhandenen Dienstes verwendet, wodurch die Systemdienstdeklaration von der Anbieterbinärdatei entkoppelt wird. Integratoren geben den Pfad zu ihrer Anbieter-Binärdatei mit dem Attribut ro.vendor.init_dev_config.path an und konfigurieren sie mit den erforderlichen SELinux-Labels und ‑Berechtigungen.

Implementierungsanforderungen für Anbieter

So binden Sie init_dev_config ein:

  1. Konfigurieren Sie den Pfad des Anbieter-Binärprogramms zur Build-Zeit mit PRODUCT_VENDOR_PROPERTIES. Der angegebene Binärpfad muss ein gültiger Pfad zu einer im System installierten Binärdatei sein:

    PRODUCT_VENDOR_PROPERTIES += \
    ro.vendor.init_dev_config.path=/vendor/bin/init_dev_config

    Wenn diese Eigenschaft nicht festgelegt ist, wird die Dienstausführung mit init übersprungen und der Startvorgang wird normal fortgesetzt.

  2. Da der Dienst vor apexd-bootstrap ausgeführt wird, sind die vollständigen von APEX bereitgestellten Bionic-Bibliotheken noch nicht verfügbar. Legen Sie in Android.bp bootstrap: true fest:

    rust_binary {
    name: "init_dev_config",
    vendor: true,
    srcs: ["src/main.rs"],
    rustlibs: [
        "librustutils",
    ],
    bootstrap: true,
}

  3. Schreiben Sie die Dienstlogik, um die Hardwarevariante zu erkennen und die entsprechenden Systemeigenschaften festzulegen:

    use rustutils::system_properties;

fn main() {
    let hw_sku = read_hardware_sku();

    // Dynamically initialize vendor-specific properties:
    let display_type = match hw_sku {
        1 => "oled",
        _ => "lcd",
    };
    system_properties::write("vendor.display.panel_type", display_type)
        .expect("Failed to set vendor display property");
}

  4. Kennzeichnen Sie das Anbieter-Binärprogramm mit init_dev_config_exec:

     /vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0

  5. Erteilen Sie die Domainberechtigung init_dev_config, um die erforderlichen Attributtypen festzulegen:

     set_prop(init_dev_config, vendor_my_sku_prop)

Informationen zur Verwendung von init_dev_config für die APEX-Aktivierung und ‑Deaktivierung finden Sie unter Vendor-APEX-Auswahl beim Booten.

HAL-Attribute

Wenn die Source of Truth für eine Konfiguration eine Hardwarekomponente auf einem Gerät ist, muss das HAL für die Hardware die Informationen für diese Komponente bereitstellen. Definieren Sie eine neue HAL-Methode in der vorhandenen HAL, um auf die Konfiguration zuzugreifen. Weitere Informationen zum Entwickeln eines HAL finden Sie unter AIDL für HALs.

XML-Dateien für die Systemkonfiguration

Wenn die Konfigurationsdaten statisch, aber kompliziert (strukturiert) sind, sollten Sie XML oder andere ähnliche Formate für die Konfigurationsdaten verwenden. Achten Sie darauf, dass das Dateischema stabil bleibt. Für XML-Dateien können Sie xsd_config verwenden, um das Schema stabil zu halten und einen automatisch generierten XML-Parser zu nutzen.

Ressourcen-Overlay

Mit Ressourcen-Overlays können Sie ein Produkt anpassen. Es gibt zwei Arten von Ressourcen-Overlays:

  • Standard-Ressourcen-Overlay, das zum Anpassen eines Produkts zur Build-Zeit verwendet wird. Informationen zu Standard-Ressourcen-Overlays finden Sie unter Build mit Ressourcen-Overlays anpassen.

  • Mit Runtime Resource Overlay (RRO) werden die Ressourcenwerte eines Zielpakets zur Laufzeit geändert. Eine auf dem Systemimage installierte App kann beispielsweise ihr Verhalten basierend auf dem Wert einer Ressource ändern. Anstatt den Ressourcenwert zur Build-Zeit fest zu codieren, kann ein RRO, das auf einer anderen Partition installiert ist, die Werte der App-Ressourcen zur Laufzeit ändern. Weitere Informationen zu RROs finden Sie unter Den Wert der Ressourcen einer App zur Laufzeit ändern.