Omówienie konfiguracji

AOSP oferuje te opcje przechowywania informacji o konfiguracji na urządzeniu:

  • Właściwości systemowe
  • Konfiguracja urządzenia podczas wczesnego rozruchu
  • Właściwości warstwy abstrakcji sprzętowej (HAL)
  • Pliki XML konfiguracji systemu
  • Nakładki zasobów (statyczne i środowiska wykonawczego)

Właściwości systemowe

Właściwości systemu to pary klucz-wartość w formie ciągów znaków przechowywane w słowniku globalnym build.prop. Właściwości systemowe to zasoby obejmujące cały system, które są łatwe w użyciu i mają niewielki wpływ na wydajność. W przypadku korzystania z właściwości systemowych nie musisz używać komunikacji międzyprocesowej (IPC), nawet jeśli właściwość systemowa jest udostępniana w wielu procesach. Właściwości systemowe są jednak podobne do zmiennych globalnych i mogą być szkodliwe, jeśli są niewłaściwie używane. Niewłaściwe użycie właściwości systemowych może powodować problemy, takie jak luki w zabezpieczeniach i niedostępność aplikacji dla użytkowników. Zanim zaczniesz używać właściwości systemu do przechowywania informacji o konfiguracji, rozważ inne opcje konfiguracji.

Więcej informacji o właściwościach systemu znajdziesz w artykule Dodawanie właściwości systemu.

Konfiguracja urządzenia podczas wczesnego rozruchu

W Androidzie 17 i nowszym usługa init_dev_config zapewnia obsługę konfiguracji urządzenia i inicjowania właściwości systemu. Ten dynamiczny mechanizm architektury uruchamia się automatycznie na wczesnym etapie rozruchu.

Gdy pojedynczy obraz systemu lub dostawcy musi obsługiwać wiele wariantów sprzętowych, wartości konfiguracji nie zawsze można zakodować na stałe w czasie kompilacji. Usługa init_dev_config jest wykonywana w fazie early-init, tuż przed apexd-bootstrap, co umożliwia dostawcom sprawdzenie stanu sprzętu (np. na podstawie argumentów programu rozruchowego, wcześnie zamontowanych partycji lub tabel konfiguracji sprzętu) i dynamiczne zainicjowanie właściwości systemu przed zainicjowaniem usług i bibliotek zależnych.

Integracja usługi i jej cykl życia

Usługa init_dev_config jest domyślnie zdefiniowana w systemieinit.rc i wykonywana synchronicznie podczas early-init, przedapexd-bootstrap. Integratorzy nie muszą deklarować nowej usługi init.

Zamiast tego istniejąca usługa korzysta z rozszerzenia właściwości na ścieżce wykonywalnej, oddzielając deklarację usługi systemowej od pliku binarnego dostawcy. Integratorzy określają ścieżkę do pliku binarnego dostawcy za pomocą właściwości ro.vendor.init_dev_config.path i konfigurują ją za pomocą wymaganych etykiet i uprawnień SELinux.

Wymagania dotyczące implementacji przez dostawcę

Aby przeprowadzić integrację z init_dev_config:

  1. Skonfiguruj ścieżkę binarną dostawcy w czasie kompilacji za pomocą polecenia PRODUCT_VENDOR_PROPERTIES. Podana ścieżka binarna musi być prawidłową ścieżką do pliku binarnego zainstalowanego w systemie:

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

    Jeśli ta właściwość nie jest ustawiona, init pomija wykonanie usługi, a uruchamianie jest kontynuowane w normalny sposób.

  2. Ponieważ usługa działa przed apexd-bootstrap, pełne biblioteki bionic dostarczone przez APEX nie są jeszcze dostępne. W Android.bp ustaw bootstrap: true:

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

  3. Napisz logikę usługi, aby wykryć wariant sprzętu i ustawić odpowiednie właściwości systemu:

    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. Oznacz plik binarny dostawcy etykietą init_dev_config_exec:

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

  5. Przyznaj uprawnienie do domeny init_dev_config, aby ustawić wymagane typy usługi:

     set_prop(init_dev_config, vendor_my_sku_prop)

Informacje o używaniu init_dev_config do aktywacji i wyłączania APEX znajdziesz w artykule Wybór APEX dostawcy podczas uruchamiania.

Właściwości HAL

Jeśli źródłem informacji o konfiguracji jest komponent sprzętowy na urządzeniu, HAL sprzętu musi dostarczać informacje o tym komponencie. Zdefiniuj nową metodę HAL w dotychczasowej warstwie HAL, aby uzyskać dostęp do konfiguracji. Więcej informacji o tworzeniu HAL znajdziesz w artykule AIDL dla HAL.

Pliki XML konfiguracji systemu

Jeśli dane konfiguracyjne są statyczne, ale złożone (strukturalne), rozważ użycie formatu XML lub innego podobnego formatu. Upewnij się, że schemat pliku pozostaje stabilny. W przypadku plików XML możesz użyć elementu xsd_config, aby zachować stabilność schematu i korzystać z automatycznie generowanego parsera XML.

Nakładka zasobów

Możesz używać nakładek na zasoby, aby dostosowywać produkt. Istnieją 2 rodzaje nakładek na zasoby:

  • Standardowa nakładka zasobu używana do dostosowywania produktu w czasie kompilacji. Informacje o standardowych nakładkach zasobów znajdziesz w artykule Dostosowywanie kompilacji za pomocą nakładek zasobów.

  • Nakładka zasobów środowiska wykonawczego (RRO) służy do zmiany wartości zasobów pakietu docelowego w środowisku wykonawczym. Na przykład aplikacja zainstalowana w obrazie systemu może zmieniać swoje działanie w zależności od wartości zasobu. Zamiast zakodowywać wartość zasobu na stałe w czasie kompilacji, RRO zainstalowany na innej partycji może zmieniać wartości zasobów aplikacji w czasie działania. Więcej informacji o nakładkach zasobów środowiska wykonawczego znajdziesz w artykule Zmiana wartości zasobów aplikacji w czasie działania.