À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l'écosystème, nous publierons le code source sur AOSP au deuxième et au quatrième trimestre. Pour créer et contribuer dans AOSP, utilisez android-latest-release. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP. Pour en savoir plus, consultez Modifications apportées à AOSP.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Présentation de la configuration

AOSP propose les options suivantes pour stocker les informations de configuration sur un appareil :

Propriétés système
Configuration de l'appareil au démarrage
Propriétés de la couche d'abstraction matérielle (HAL)
Fichiers XML de configuration du système
Superpositions de ressources (statiques et d'exécution)

Propriétés système

Les propriétés système sont des paires clé/valeur de type chaîne stockées dans le dictionnaire global build.prop. Les propriétés système sont des ressources à l'échelle du système qui sont faciles à utiliser et qui ont une faible surcharge de performances. Lorsque vous utilisez des propriétés système, vous n'avez pas besoin d'utiliser la communication inter-processus (IPC), même si une propriété système est partagée entre plusieurs processus. Toutefois, les propriétés système sont semblables aux variables globales et peuvent être dangereuses en cas d'utilisation abusive. L'utilisation abusive des propriétés système peut entraîner des problèmes tels que des failles de sécurité et des applications devenant inaccessibles aux utilisateurs. Avant d'utiliser les propriétés système pour stocker des informations de configuration, examinez les autres options de configuration.

Pour en savoir plus sur les propriétés système, consultez Ajouter des propriétés système.

Configuration de l'appareil au démarrage

Dans Android 17 et versions ultérieures, le service init_dev_config permet la configuration des appareils et l'initialisation des propriétés système. Ce mécanisme d'architecture dynamique s'exécute automatiquement au début du démarrage.

Lorsqu'une seule image système ou fournisseur doit prendre en charge plusieurs variantes matérielles, les valeurs de configuration ne peuvent pas toujours être codées en dur au moment de la compilation. Le service init_dev_config s'exécute pendant la phase early-init, juste avant apexd-bootstrap, ce qui permet aux fournisseurs d'inspecter l'état du matériel (par exemple, à partir des arguments du bootloader, des partitions montées en amont ou des tables de configuration matérielle) et d'initialiser dynamiquement les propriétés système avant l'initialisation des services et des bibliothèques dépendants.

Intégration et cycle de vie des services

Le service init_dev_config est défini par défaut dans le init.rc du système et exécuté de manière synchrone pendant early-init, avant apexd-bootstrap. Les intégrateurs n'ont pas besoin de déclarer un nouveau service init.

Au lieu de cela, le service existant utilise l'expansion de propriété sur son chemin exécutable, ce qui découple la déclaration de service système du binaire du fournisseur. Les intégrateurs spécifient le chemin d'accès à leur binaire fournisseur à l'aide de la propriété ro.vendor.init_dev_config.path et le configurent avec les libellés et autorisations SELinux requis.

Exigences d'implémentation pour les fournisseurs

Pour intégrer init_dev_config :

Configurez le chemin d'accès au binaire du fournisseur au moment de la compilation à l'aide de PRODUCT_VENDOR_PROPERTIES. Le chemin d'accès binaire fourni doit être un chemin d'accès valide vers un binaire installé dans le système :
```
PRODUCT_VENDOR_PROPERTIES += \
    ro.vendor.init_dev_config.path=/vendor/bin/init_dev_config
```
Si cette propriété n'est pas définie, init ignore l'exécution du service et le démarrage se poursuit normalement.
Étant donné que le service s'exécute avant apexd-bootstrap, les bibliothèques bioniques complètes fournies par APEX ne sont pas encore disponibles. Dans Android.bp, définissez bootstrap: true :
```
rust_binary {
    name: "init_dev_config",
    vendor: true,
    srcs: ["src/main.rs"],
    rustlibs: [
        "librustutils",
    ],
    bootstrap: true,
}
```

Écrivez la logique de service pour détecter la variante matérielle et définir les propriétés système appropriées :

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");
}

Attribuez le libellé init_dev_config_exec au binaire du fournisseur :
```
 /vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0
```
Accordez l'autorisation de domaine init_dev_config pour définir les types de propriétés requis :
```
 set_prop(init_dev_config, vendor_my_sku_prop)
```

Pour savoir comment utiliser init_dev_config pour activer et désactiver APEX, consultez Sélection de Vendor APEX au démarrage.

Propriétés HAL

Lorsque la source de vérité d'une configuration provient d'un composant matériel sur un appareil, la HAL du matériel doit fournir les informations pour ce composant. Définissez une nouvelle méthode HAL dans le HAL existant pour accéder à la configuration. Pour en savoir plus sur le développement d'une HAL, consultez AIDL pour les HAL.

Fichiers XML de configuration du système

Lorsque les données de configuration sont statiques, mais complexes (structurées), envisagez d'utiliser XML ou d'autres formats de ce type pour les données de configuration. Assurez-vous que le schéma du fichier reste stable. Pour les fichiers XML, vous pouvez utiliser xsd_config pour assurer la stabilité du schéma et profiter d'un analyseur XML généré automatiquement.

Superposition de ressources

Vous pouvez utiliser des calques de ressources pour personnaliser un produit. Il existe deux types de calques de ressources :

Superposition de ressources standards utilisée pour personnaliser un produit au moment de la compilation. Pour en savoir plus sur les overlays de ressources standards, consultez Personnaliser la compilation avec des overlays de ressources.
L'overlay de ressources d'exécution (RRO) permet de modifier les valeurs de ressources d'un package cible au moment de l'exécution. Par exemple, une application installée sur l'image système peut modifier son comportement en fonction de la valeur d'une ressource. Plutôt que d'encoder en dur la valeur de la ressource au moment de la compilation, un RRO installé sur une autre partition peut modifier les valeurs des ressources de l'application au moment de l'exécution. Pour en savoir plus sur les RRO, consultez Modifier la valeur des ressources d'une application au moment de l'exécution.