À 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 uses AI technology to translate content into your preferred language. AI translations can contain errors.

Générer un middleware

Le middleware VSIDL (Vehicle Services Interface Definition Language) définit un ensemble de bibliothèques Rust qui créent une couche d'abstraction au-dessus de la pile de communication du véhicule défini par logiciel (SDV) pour simplifier l'utilisation de l'écosystème SDV. Le middleware fournit une méthode standardisée permettant aux services de communiquer et d'interagir entre eux. Le code généré par VSIDLC et votre code personnalisé utilisent ces bibliothèques.

Le compilateur VSIDLC (Vehicle Services Interface Definition Language) valide les définitions, génère des fichiers de compilation (Android.bp) contenant des cibles genrule pour produire du code middleware Rust lors du processus de compilation et crée des configurations de déploiement à partir des fichiers VSIDL et protobuf dans un catalogue. La figure 1 montre l'entrée de VSIDLC et la sortie générée par VSIDLC :

Entrées et sorties VSIDLC

Figure 1. Entrées et sorties VSIDLC.

Voici une explication du diagramme :

En tant qu'entrées, vous fournissez les fichiers suivants organisés dans des répertoires appelés catalogues :
- Les fichiers proto (avec l'extension .proto) contiennent des structures de données échangées entre les unités de service définies par VSIDL.
- Les fichiers VSIDL (avec l'extension .vsidl) définissent les packs de services, les unités de service et la propriété du type d'unité.
- Les fichiers Android.bp de chaque répertoire de catalogue définissent les cibles de compilation rust_protobuf pour tous les fichiers proto du catalogue. VSIDLC utilise le crate_name spécifié dans ces cibles pour référencer les types de messages protobuf générés dans Rust.
Vous exécutez VSIDLC pour générer les fichiers suivants :
- Les fichiers Android.bp sont générés dans le dossier de chaque bundle de services. Si vous définissez --genrule, ces cibles génèrent des fichiers Rust à jour pendant le processus de compilation et incluent les dépendances de bibliothèque rust_protobuf nécessaires.
- Les fichiers service_bundle.rs sont générés pour chaque bundle de services et contiennent le struct principal et les fonctions permettant d'interagir avec les composants middleware.
- Les fichiers lib.rs sont générés pour chaque service RPC appartenant à un bundle et sont placés dans un sous-dossier portant le nom du service RPC. C'est le cas des données suivantes :
- Un trait Interface implémente la logique côté serveur.
- Une structure Client effectue des appels à un service RPC.
- Les fichiers diagnostics.rs sont générés si un diagnostics_declaration est présent dans le fichier VSIDL, fournissant les liaisons nécessaires pour les diagnostics basés sur UDS.
- Les configurations de déploiement et de sécurité sont générées lorsque vous utilisez l'indicateur --apex. Ils sont placés dans les répertoires apex/ et configs/ et incluent les fichiers d'orchestration .textproto et les règles de sécurité (autorisations) requises pour la communication de service à service.
- Un boilerplate de service est généré lorsque vous utilisez l'indicateur --services. Il est placé dans un répertoire services/ et contient un squelette d'application Rust, y compris un fichier main.rs, pour démarrer votre implémentation.

Exécuter VSIDLC

Pour exécuter VSIDLC :

Si vous n'avez pas configuré votre environnement, exécutez source build/envsetup.sh.
Exécutez la commande suivante pour créer VSIDLC :
```
m vsidlc
```
Assurez-vous que le répertoire de votre catalogue VSIDL contient les fichiers de compilation, protobuf et VSIDL nécessaires.

Remarque : Nous vous recommandons de définir de petites bibliothèques rust_protobuf regroupées de manière logique plutôt qu'une grande bibliothèque pour l'ensemble du catalogue. Pour éviter toute ambiguïté, assurez-vous que chaque fichier .proto n'appartient qu'à une seule cible de bibliothèque dans le catalogue.
Exécutez la commande vsidlc :
```
vsidlc -c path_to_catalog -o output_directory -p
```
Où :
- -c path_to_catalog identifie le chemin d'accès au répertoire principal du catalogue.
- -o output_directory identifie le répertoire parent dans lequel le répertoire de sortie generated_rs est créé.
- (Facultatif) --apex génère des artefacts de configuration d'orchestration et de sécurité.
- (Facultatif) --services génère un squelette d'application Rust de démarrage rapide.
- (facultatif) -p supprime les répertoires générés existants (comme generated_rs, et le cas échéant apex, configs ou services) avant de générer de nouveaux fichiers.
- (facultatif) --genrule génère des Android.bp genrules au lieu du code Rust. Les genrules génèrent le code Rust nécessaire à la volée lors de l'exécution de m pour éviter de placer les artefacts générés sous contrôle des versions.
Un répertoire generated_rs est créé. Il contient un fichier Android.bp et les fichiers middleware générés. Ce répertoire est organisé dans des sous-répertoires correspondant aux noms complets de vos bundles de services définis.

Gérer les dépendances

Par défaut, VSIDLC ne génère du code que pour le catalogue principal, et non pour les catalogues de dépendances. Si votre catalogue utilise des types ou des unités de service définis dans d'autres catalogues, spécifiez le chemin d'accès à chaque catalogue de dépendances à l'aide de l'indicateur -d :

vsidlc -c path_to_catalog -o output_directory -d dep1_path -d dep2_path ...

Vous devez fournir les chemins d'accès pour l'intégralité du graphique des dépendances, y compris les dépendances transitives (dépendances des dépendances). Par exemple, supposons que vous ayez l'arborescence de dépendances de catalogue suivante :

Exemple d'arborescence de dépendances VSIDLC

Figure 2. Exemple d'arborescence de dépendances VSIDLC.

Pour générer un middleware pour chaque catalogue de l'arborescence, vous devez exécuter les commandes suivantes :

Catalogue cible	Dépendances	Commande
Catalogue SDV Core	N/A	`vsidlc -o ./generated -c ./path/to/sdv_core_catalog`
Catalogue de diagnostics	Catalogue SDV Core	`vsidlc -o ./generated -c ./path/to/diagnostics_catalog -d ./path/to/sdv_core_catalog`
Catalogue SOME/IP	Catalogue de diagnostics, catalogue SDV Core	`vsidlc -o ./generated -c ./path/to/someip_catalog -d ./path/to/diagnostics_catalog -d ./path/to/sdv_core_catalog`
Catalogue OEM	Catalogue de diagnostics, catalogue SOME/IP, catalogue SDV Core (de manière transitive)	`vsidlc -o ./generated -c ./path/to/oem_catalog -d ./path/to/someip_catalog -d ./path/to/diagnostics_catalog -d ./path/to/sdv_core_catalog`

Mettre en forme la sortie Rust

Par défaut, VSIDL utilise rustfmt pour mettre en forme la sortie Rust. Pour que la valeur par défaut fonctionne correctement, définissez la variable d'environnement $ANDROID_BUILD_TOP ou les variables d'environnement RUSTFMT_PATH et RUSTFMT_TOML_PATH. Pour modifier le format par défaut de la sortie Rust, utilisez l'option --rust-formatter avec pretty-please ou none :

Pour modifier le format de résultat en crate prettyplease, utilisez la valeur pretty-please :
```
vsidlc -c path_to_catalog -o output_directory -p --rust-formatter pretty-please
```

Pour définir le format de sortie sur "aucun", utilisez la valeur none :

vsidlc -c path_to_catalog -o output_directory -p --rust-formatter none

Étape suivante

Après avoir généré le middleware, consultez Implémenter votre logique métier.