Questa pagina è stata tradotta dall'API Cloud Translation.

Guida all'integrazione del controller delle restrizioni di debug

Utilizza le istruzioni in questa pagina per integrare il controller AAOS Debugging Restriction (RDC).

Figura 1. Esempio di app DRC.

Architettura

L'architettura della Repubblica Popolare Democratica di Corea (DRC) è illustrata nella Figura 2. Componenti con contorno rosso (emittente token e DRC) sono corredate di implementazioni di riferimento personalizzabili.

Figura 2. dell'architettura DRC.

Che cos'è la Repubblica Democratica del Congo?

L'unità principale dell'auto include l'app DRC (vedi 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 applicando le modifiche alle restrizioni di debug come specificato nel token. La logica include gli elementi UX di base sul lato auto.

Qual è l'emittente del token?

Si tratta di un servizio web che emette token di accesso firmati tramite crittografia (vedi il riferimento implementazione in packages/apps/Car/DebuggingRestrictionController/server). Il servizio web di riferimento è una funzione Firebase Cloud di cui è possibile eseguire il deployment (per saperne di più, consulta Cloud Functions per Firebase).

Prerequisiti

Prima di eseguire il deployment di un'implementazione di riferimento, assicurati di completare le attività seguenti.

Prepara i certificati per la firma dei token di accesso

L'emittente del token genera firme web JSON (JWS) come token di accesso. Per ottimizzare compatibilità, l'emittente del 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 di accesso ai token di accesso. Una tipica catena di certificati dovrebbe essere composta 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 protocollo TLS standard certificato. 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 un nome alternativo del soggetto (SAN). L'estensione SAN contiene un identificatore (ad esempio, il nome host) del token emittente. Infine, i certificati RSA dovrebbero avere la precedenza sui certificati EC, perché il token l'emittente supporta solo RS256.

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

Configura Firebase

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

Per configurare il tuo account Firebase:

Per creare un progetto Firebase, consulta Aggiungi Firebase a nel tuo progetto Android.
Per attivare alcuni autenticatori Firebase, consulta Dove posso trovare iniziare con Firebase Authentication?.
Per aggiungere una funzione Firebase Cloud vuota, consulta Ottieni Iniziata.
Se non lo hai già fatto, installa gli strumenti Node.js, NPM e Firebase per compilare e il deployment dell'emittente del token.
Nota: dopo aver creato un progetto Firebase, ti viene richiesto per scaricare un file di configurazione denominato google-services.json. Questo file non contiene informazioni sensibili e vengono utilizzate sia dall'app DRC di riferimento sia dall'emittente del token in un secondo momento.

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 non in bundle con Gradle.

Build in bundle

Per creare un'app in bundle:

Copia applicationId, projectId e apiKey da google-services.json a packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java. In questo modo l'app DRC può connettersi correttamente a Firebase.
Aggiorna queste costanti in packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java:
- TOKEN_USES_SELF_SIGNED_CA indica se i certificati CA radice autofirmati sono in uso. 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 Functions di Firebase e dovrebbe corrispondono alla funzione Cloud che hai creato in precedenza nella console Firebase.
- TOKEN_ISSUER_HOSTNAME deve corrispondere al nome alternativo del soggetto in il certificato end-entity che firmerà i token di accesso.
- DRC_TEST_EMAIL e DRC_TEST_PASSWORD sono credenziali di un l'account di prova facoltativo, di cui è possibile eseguire il pre-provisioning in Firebase se hai abilitato Accesso tramite email/password. Vengono utilizzati solo per i test strumentati.

L'app è ora configurata per utilizzare il tuo account Firebase e i tuoi certificati. In Android 9 e versioni successive, devi configurare inserimento nella lista consentita di autorizzazioni privilegiate. La lista consentita deve contenere almeno android.permission.MANAGE_USERS. Ad esempio:

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

Build non in bundle

Le build DRC non in bundle utilizzano Gradle per compilare l'app.

Per creare una build non in bundle:

Verifica di aver installato l'SDK 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 configura automaticamente il resto.
Definisci le variabili di ambiente. Come per le build in bundle, devi 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 Cloud Functions Firebase;
- $TOKEN_ISSUER_HOST_NAME: SAN nel certificato;
- $DRC_TEST_EMAIL e $DRC_TEST_EMAIL: credenziali per un test solo le build di debug.
Per creare l'app con Gradle, esegui un comando come questo:
```
$ ./gradlew build
```
Nota: un'app DRC non inclusa deve essere firmata con la piattaforma perché richiede un'autorizzazione con privilegi, MANAGE_USERS. l'inserimento nella lista consentita di autorizzazioni con privilegi è ancora valido richiesti per lo stesso motivo.

Integra l'emittente del token

L'emittente del token di riferimento è una funzione Cloud Functions di Firebase implementata in Node.js. La funzione può essere chiamata solo da un utente autenticato. Prima di eseguire il deployment dell'app, devi impostare 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 il certificato dell'entità finale e il certificato CA radice alla fine. Il periodo di scadenza è personalizzabile e può essere impostato su una durata maggiore se emesso per il token richiede del tempo prima che possa essere ricevuto e utilizzato da un'app della DRC. Token la revoca non è supportata.

Carica la configurazione in Firebase:

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

Esegui il deployment della funzione Firebase Cloud Functions:

$ firebase deploy --only functions

Per gestire e monitorare l'emittente del token, consulta Gestisci le opzioni di deployment e runtime.

Imposta restrizioni predefinite

Le limitazioni predefinite possono essere applicate prima del primo avvio. Esegui questa operazione usando una risorsa statica per sostituire i valori predefiniti nel framework Android. Le restrizioni possono essere rispettivamente applicati a diversi tipi di utenti. Per informazioni sui diversi tipi di utenti, consulta Supporto multiutente.

È possibile configurare la limitazione predefinita per l'utente di sistema headless con il array di stringhe config_defaultFirstUserRestrictions frameworks/base/core/res/res/values/config.xml. Impostazione di questa restrizione disattiva automaticamente Android Debug Bridge (ADB) finché la limitazione non viene rimossa, per esempio:

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

Le limitazioni predefinite per gli utenti normali (ad es. conducenti e passeggeri), e gli ospiti possono essere configurati in frameworks/base/core/res/res/xml/config_user_types.xml. Puoi sovrapporre questi stringhe per impostare le restrizioni predefinite rispettivamente per ogni 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>