À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Guide d'intégration du contrôleur de restriction de débogage
Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Suivez les instructions de cette page pour intégrer le contrôleur de restriction de débogage (DRC) AAOS.

Figure 1 : Exemple d'application DRC.

Architecture

L'architecture de la DRC est illustrée à la figure 2. Les composants en rouge (émetteur de jetons et DRC) sont accompagnés d'implémentations de référence que vous pouvez personnaliser.

Figure 2. Architecture de la DRC.

Qu'est-ce que la RDC ?

L'unité centrale de la voiture inclut l'application DRC (voir l'implémentation de référence dans packages/apps/Car/DebuggingRestrictionController). L'application de référence inclut la logique permettant de recevoir un jeton d'accès de l'émetteur de jetons, de valider le jeton, puis d'appliquer les modifications de restriction de débogage spécifiées dans le jeton. La logique comprend des éléments d'expérience utilisateur de base du côté de la voiture.

Qui est l'émetteur du jeton ?

Il s'agit d'un service Web qui émet des jetons d'accès signés de manière cryptographique (voir l'implémentation de référence dans packages/apps/Car/DebuggingRestrictionController/server). Le service Web de référence est une fonction Cloud Firebase déployable (pour en savoir plus, consultez Cloud Functions for Firebase).

Prérequis

Avant de déployer une implémentation de référence, assurez-vous d'effectuer les tâches suivantes.

Préparer des certificats pour signer des jetons d'accès

L'émetteur de jetons génère des signatures Web JSON (JWS) en tant que jetons d'accès. Pour une compatibilité optimale, l'émetteur de référence n'accepte que l'algorithme RS256 (signatures RSA avec SHA256). Pour faciliter la rotation des clés, utilisez une chaîne de certificats au lieu d'un seul certificat pour signer les jetons d'accès. Une chaîne de certificats typique doit se composer d'un certificat d'autorité de certification racine, d'un certificat d'autorité de certification intermédiaire et d'un certificat d'entité finale.

Le certificat d'entité de fin qui signe les jetons JWS ne diffère pas d'un certificat TLS standard. Vous pouvez acheter un certificat auprès d'autorités de certification publiques telles que DigiCert ou gérer votre propre chaîne de certificats à l'aide de certificats de CA racine autosignés ou de modules de sécurité matériels. Le certificat d'entité finale doit être un certificat X509v3 avec une extension SAN (Subject Alternative Name). L'extension SAN contient un identifiant (par exemple, un nom d'hôte) de l'émetteur du jeton. Enfin, les certificats RSA sont à privilégier par rapport aux certificats EC, car l'émetteur de jetons n'est compatible qu'avec RS256.

Google fournit un script shell permettant de générer des certificats autosignés dans packages/apps/Car/DebuggingRestrictionController/server/genkey.sh.

Configurer Firebase

L'émetteur du jeton de référence utilise Firebase Authentication et Firebase Cloud Function.

Pour configurer votre compte Firebase:

Pour créer un projet Firebase, consultez la section Ajouter Firebase à votre projet Android.
Pour activer certains authentificateurs Firebase, consultez la section Où puis-je commencer avec Firebase Authentication ?.
Pour ajouter une fonction Firebase Cloud vide, consultez la section Premiers pas.
Si ce n'est pas déjà fait, installez les outils Node.js, NPM et Firebase pour compiler et déployer l'émetteur de jetons.
Remarque:Une fois que vous avez créé un projet Firebase, vous êtes invité à télécharger un fichier de configuration appelé google-services.json. Ce fichier ne contient aucune information sensible et est utilisé à la fois par l'application de référence DRC et l'émetteur de jetons par la suite.

Intégrer l'application DRC

L'application de référence pour la DRC se trouve dans packages/apps/Car/DebuggingRestrictionController. L'application peut être compilée en bundle dans AOSP avec Soong ou en bundle séparé avec Gradle.

Compilation groupée

Pour créer une application groupée:

Copiez applicationId, projectId et apiKey de google-services.json dans packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java. Cela permet à l'application DRC de se connecter correctement à Firebase.
Mettez à jour ces constantes dans packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java :
- TOKEN_USES_SELF_SIGNED_CA indique si des certificats d'autorité de certification racine autosignés sont utilisés. Si elle est activée, l'application DRC n'accepte que le certificat racine de l'autorité de certification encodé au format PEM spécifié dans ROOT_CA_CERT.
- TOKEN_ISSUER_API_NAME est le nom de la fonction Cloud Firebase et doit correspondre à la fonction Cloud que vous avez créée précédemment dans la console Firebase.
- TOKEN_ISSUER_HOSTNAME doit correspondre à l'autre nom d'objet dans le certificat d'entité finale qui signera les jetons d'accès.
- DRC_TEST_EMAIL et DRC_TEST_PASSWORD sont des identifiants pour un compte de test facultatif, qui peuvent être préprovisionnés dans Firebase si vous avez activé la connexion par e-mail/mot de passe. Ils ne sont utilisés que pour les tests d'instrumentation.

L'application est maintenant configurée pour utiliser votre compte Firebase et vos certificats. Sous Android 9 ou version ultérieure, vous devez configurer la liste d'autorisation des autorisations privilégiées. La liste d'autorisation doit contenir au moins android.permission.MANAGE_USERS. Exemple :

<permissions>
  <privapp-permissions package="com.android.car.debuggingrestrictioncontroller">
    <permission name="android.permission.INTERNET"/>
    <permission name="android.permission.MANAGE_USERS"/>
  </privapp-permissions>
</permissions>

Compilation non groupée

Les builds DRC non groupés utilisent Gradle pour compiler l'application.

Pour créer un build non groupé:

Vérifiez que vous avez installé le SDK Android.
Créez un fichier texte nommé local.properties dans le répertoire racine de l'application.
Définissez l'emplacement du SDK Android:
```
 sdk.dir=path/to/android/sdk
```
Pour configurer Firebase, copiez google-services.json dans packages/apps/Car/DebuggingRestrictionController/app. Gradle analyse le fichier et configure automatiquement le reste.
Définissez les variables d'environnement. Comme pour les builds groupés, vous devez spécifier les éléments suivants :
- $TOKEN_USES_SELF_SIGNED_CA : "true" ou "false"
- $ROOT_CA_CERT: chemin d'accès au certificat de l'autorité de certification racine au format PEM.
- $TOKEN_ISSUER_API_NAME: nom de la fonction Cloud Firebase
- $TOKEN_ISSUER_HOST_NAME: SAN du certificat
- $DRC_TEST_EMAIL et $DRC_TEST_EMAIL: identifiants pour un compte de test, compilations de débogage uniquement.
Pour compiler l'application avec Gradle, exécutez une commande comme celle-ci:
```
$ ./gradlew build
```
Remarque:Une application DRC non groupée doit être signée avec le certificat de la plate-forme, car elle nécessite une autorisation privilégiée, MANAGE_USERS. La liste d'autorisation des autorisations privilégiées est toujours requise pour la même raison.

Intégrer l'émetteur de jetons

L'émetteur du jeton de référence est une fonction Cloud Firebase implémentée dans Node.js. La fonction ne peut être appelée que par un utilisateur authentifié. Avant de déployer l'application, vous devez configurer la clé privée et les certificats utilisés pour signer les jetons JWS.

Renseignez un fichier JSON avec le contenu suivant:

{
    "key": "---BEGIN PRIVATE KEY---\nRSA_PRIVATE_KEY\n-----END PRIVATE KEY-----\n",
    "certificates.0": "-----BEGIN CERTIFICATE-----\nTOKEN_SIGNING_CERT\n-----END CERTIFICATE-----\n",
    "certificates.1": "-----BEGIN CERTIFICATE-----\nINTERMEDIATE_CA_CERT\n-----END CERTIFICATE-----\n",
    "certificates.2": "-----BEGIN CERTIFICATE-----\nROOT_CA_CERT\n-----END CERTIFICATE-----\n",
    "expiration": "30m",
    "issuer": "Debugging Access Token Issuer",
    "audience": "IHU"
}

Les certificats sont triés dans l'ordre suivant : certificat d'entité finale en premier, puis certificat de l'autorité de certification racine. La période d'expiration est personnalisable et peut être définie sur une durée plus longue si un jeton émis prend un certain temps avant de pouvoir être reçu et consommé par une application DRC. La révocation de jeton n'est pas prise en charge.

Importez la configuration dans Firebase:

$ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"

Déployez la fonction Cloud Firebase:

$ firebase deploy --only functions

Pour gérer et surveiller l'émetteur de jetons, consultez la section Gérer les options de déploiement et d'exécution des fonctions.

Définir des restrictions par défaut

Les restrictions par défaut peuvent être appliquées avant le premier démarrage. Pour ce faire, utilisez des superpositions de ressources statiques afin de remplacer les valeurs par défaut du framework Android. Des restrictions peuvent être appliquées respectivement à différents types d'utilisateurs. Pour en savoir plus sur les différents types d'utilisateurs, consultez la section Compatibilité avec plusieurs utilisateurs.

La restriction par défaut pour l'utilisateur système sans tête peut être configurée avec la matrice de chaînes config_defaultFirstUserRestrictions dans frameworks/base/core/res/res/values/config.xml. Définir cette restriction désactive automatiquement Android Debug Bridge (ADB) jusqu'à ce que la restriction soit supprimée, par exemple:

<string-array translatable="false" name="config_defaultFirstUserRestrictions">
  <item>no_debugging_features</item>
</string-array>

Les restrictions par défaut pour les utilisateurs réguliers (par exemple, les conducteurs et les passagers) et les invités peuvent être configurées dans frameworks/base/core/res/res/xml/config_user_types.xml. Vous pouvez superposer ces chaînes pour définir les restrictions par défaut sur chaque type d'utilisateur, par exemple:

<user-types>
  <full-type name="android.os.usertype.full.SECONDARY" >
    <default-restrictions no_debugging_features="true"/>
  </full-type>
  <full-type name="android.os.usertype.full.GUEST" >
    <default-restrictions no_debugging_features="true"/>
  </full-type>
</user-types>