Questa pagina è stata tradotta dall'API Cloud Translation.

Guida all'integrazione del controller di limitazione del debug

Utilizzare le istruzioni in questa pagina per integrare il controller di restrizione di debug AAOS (DRC).

Figura 1. Esempio di app DRC.

Architettura

L'architettura DRC è illustrata nella Figura 2. I componenti delineati in rosso (emittente del token e DRC) sono accompagnati da implementazioni di riferimento che è possibile personalizzare.

Figura 2. Architettura DRC.

Cos'è la RDC?

L'unità principale dell'auto include l'app DRC (vedere l'implementazione di riferimento in packages/apps/Car/DebuggingRestrictionController ). L'app di riferimento include la logica per ricevere un token di accesso dall'emittente del token, convalidare il token e quindi applicare le modifiche alle restrizioni di debug come specificato nel token. La logica include elementi UX di base sul lato vettura.

Qual è l'emittente del token?

Si tratta di un servizio Web che emette token di accesso firmati crittograficamente (vedere l'implementazione di riferimento in packages/apps/Car/DebuggingRestrictionController/server ). Il servizio Web di riferimento è una funzione Firebase Cloud distribuibile (per ulteriori informazioni, consulta Funzioni Cloud per Firebase ).

Prerequisiti

Prima di distribuire un'implementazione di riferimento, assicurati di completare le seguenti attività.

Preparare i certificati per la firma dei token di accesso

L'emittente del token genera firme Web JSON (JWS) come token di accesso. Per una compatibilità ottimale, l'emittente di riferimento supporta solo l'algoritmo RS256 (firme RSA con SHA256). Per facilitare la rotazione delle chiavi, utilizza una catena di certificati anziché un singolo certificato per firmare i token di accesso. Una tipica catena di certificati dovrebbe essere costituita da un certificato CA radice, un certificato CA intermedio e un certificato dell'entità finale.

Il certificato dell'entità finale che firma i token JWS non è diverso da un certificato TLS standard. Puoi acquistare un certificato da CA pubbliche come DigiCert o mantenere la tua catena di certificati utilizzando certificati CA radice autofirmati o moduli di sicurezza hardware. Il certificato dell'entità finale deve essere un certificato X509v3 con estensione SAN (Nome alternativo soggetto). L'estensione SAN contiene un identificatore (ad esempio, il nome host) dell'emittente del token. Infine, i certificati RSA dovrebbero essere preferiti rispetto ai certificati EC perché l’emittente del token supporta solo RS256.

Google fornisce uno script di shell per generare certificati autofirmati in packages/apps/Car/DebuggingRestrictionController/server/genkey.sh .

Configura Firebase

L'emittente del token di riferimento utilizza Firebase Authentication e Firebase Cloud Function .

Per configurare il tuo account Firebase:

Per creare un progetto Firebase, consulta Aggiungere Firebase al tuo progetto Android .
Per abilitare alcuni autenticatori Firebase, vedi Da dove inizio con l'autenticazione Firebase? .
Per aggiungere una funzione Firebase Cloud vuota, consulta Inizia .
Se non lo hai già fatto, installa gli strumenti Node.js , NPM e Firebase per compilare e distribuire l'emittente del token.
Nota: dopo aver creato un progetto Firebase, ti viene richiesto di scaricare un file di configurazione chiamato google-services.json . Questo file non contiene informazioni sensibili e viene utilizzato successivamente sia dall'app DRC di riferimento che dall'emittente del token.

Integra l'app DRC

L'app DRC di riferimento si trova in packages/apps/Car/DebuggingRestrictionController . L'app può essere creata in bundle in AOSP con Soong o disaggregata con Gradle .

Costruzione in bundle

Per creare un'app in bundle:

Copia applicationId , projectId e apiKey da google-services.json in packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java . Ciò consente all'app DRC di connettersi correttamente a Firebase.
Aggiorna queste costanti in packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java :
- TOKEN_USES_SELF_SIGNED_CA indica se vengono utilizzati certificati CA radice autofirmati. Se abilitato, l'app DRC considera attendibile solo il certificato CA radice con codifica PEM specificato in ROOT_CA_CERT .
- TOKEN_ISSUER_API_NAME è il nome della funzione Cloud di Firebase e deve corrispondere alla funzione Cloud creata in precedenza nella console Firebase.
- TOKEN_ISSUER_HOSTNAME deve corrispondere al nome alternativo del soggetto nel certificato dell'entità finale che firmerà i token di accesso.
- DRC_TEST_EMAIL e DRC_TEST_PASSWORD sono credenziali per un account di prova facoltativo, di cui è possibile effettuare il pre-provisioning in Firebase se hai abilitato l'accesso tramite email/password. Questi vengono utilizzati solo per test strumentati.

L'app è ora configurata per utilizzare il tuo account Firebase e i tuoi certificati. In Android 9 e versioni successive, è necessario impostare la lista consentita delle autorizzazioni privilegiate . La lista consentita deve contenere almeno android.permission.MANAGE_USERS . Per esempio:

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

Costruzione disaggregata

Le build DRC disaggregate utilizzano Gradle per compilare l'app.

Per creare una build non raggruppata:

Conferma di aver installato l'SDK di Android.
Crea un file di testo denominato local.properties nella directory principale dell'app.
Imposta la posizione dell'SDK Android:
```
 sdk.dir=path/to/android/sdk
```
Per configurare Firebase, copia google-services.json in packages/apps/Car/DebuggingRestrictionController/app . Gradle analizza il file e imposta automaticamente il resto.
Definire le variabili d'ambiente. Come per le build in bundle, è necessario specificare:
- $TOKEN_USES_SELF_SIGNED_CA : vero o falso;
- $ROOT_CA_CERT : percorso del certificato CA radice con codifica PEM;
- $TOKEN_ISSUER_API_NAME : nome della funzione Firebase Cloud;
- $TOKEN_ISSUER_HOST_NAME : SAN nel certificato;
- $DRC_TEST_EMAIL e $DRC_TEST_EMAI L: credenziali per un account di prova, solo build di debug.
Per creare l'app con Gradle, esegui un comando come questo:
```
$ ./gradlew build
```
Nota: un'app DRC disaggregata deve essere firmata con il certificato della piattaforma perché richiede un'autorizzazione privilegiata, MANAGE_USERS . l'inserimento nella lista consentita delle autorizzazioni privilegiate è ancora richiesto per lo stesso motivo.

Integrare l'emittente del token

L'emittente del token di riferimento è una Firebase Cloud Function implementata in Node.js La funzione può essere richiamata solo da un utente autenticato. Prima di distribuire l'app, è necessario configurare la chiave privata e i certificati utilizzati per firmare i token JWS.

Compila un file JSON con i seguenti contenuti:

{
    "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"
}

I certificati vengono ordinati con prima il certificato dell'entità finale e alla fine il certificato della CA radice. Il periodo di scadenza è personalizzabile e può essere impostato su una durata più lunga se un token emesso impiega del tempo prima di poter essere ricevuto e utilizzato da un'app DRC. La revoca del token non è supportata.

Carica la configurazione su Firebase:

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

Distribuisci la funzione Firebase Cloud:

$ firebase deploy --only functions

Per gestire e monitorare l'emittente del token, consulta Gestire la distribuzione delle funzioni e le opzioni di runtime .

Imposta restrizioni predefinite

Le restrizioni predefinite possono essere applicate prima del primo avvio. Fallo con sovrapposizioni di risorse statiche per sovrascrivere le impostazioni predefinite nel framework Android. Le restrizioni possono essere applicate rispettivamente a diverse tipologie di utenti. Per informazioni sui diversi tipi di utenti, consulta Supporto multiutente .

La restrizione predefinita per l' utente del sistema headless può essere configurata con l'array di stringhe config_defaultFirstUserRestrictions in frameworks/base/core/res/res/values/config.xml . L'impostazione di questa restrizione disabilita automaticamente Android Debug Bridge (ADB) finché la restrizione non viene rimossa, ad esempio:

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

Le restrizioni predefinite per gli utenti regolari (ad esempio, conducenti e passeggeri) e gli ospiti possono essere configurate in frameworks/base/core/res/res/xml/config_user_types.xml . È possibile sovrapporre queste stringhe per impostare rispettivamente le restrizioni predefinite su ciascun tipo di utente, ad esempio:

<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>