Utilice las instrucciones de esta página para integrar el controlador de restricción de depuración (DRC) de AAOS.
Figura 1. Ejemplo de aplicación DRC.
Arquitectura
La arquitectura DRC se ilustra en la Figura 2. Los componentes resaltados en rojo (emisor de token y DRC) tienen implementaciones de referencia adjuntas que puede personalizar.
Figura 2. Arquitectura de la República Democrática del Congo.
¿Qué es la República Democrática del Congo?
La unidad principal del automóvil incluye la aplicación DRC (consulte la implementación de referencia en packages/apps/Car/DebuggingRestrictionController
). La aplicación de referencia incluye la lógica para recibir un token de acceso del emisor del token, validarlo y luego aplicar cambios de restricción de depuración como se especifica en el token. La lógica incluye elementos básicos de UX en el lado del automóvil.
¿Qué es el emisor del token?
Este es un servicio web que emite tokens de acceso firmados criptográficamente (consulte la implementación de referencia en packages/apps/Car/DebuggingRestrictionController/server
). El servicio web de referencia es una función implementable de Firebase Cloud (para obtener más información, consulte Funciones de nube para Firebase ).
Requisitos previos
Antes de implementar una implementación de referencia, asegúrese de completar las siguientes tareas.
Preparar certificados para firmar tokens de acceso.
El emisor del token genera firmas web JSON (JWS) como tokens de acceso. Para una compatibilidad óptima, el emisor de referencia solo admite el algoritmo RS256 (firmas RSA con SHA256). Para facilitar la rotación de claves, utilice una cadena de certificados en lugar de un certificado único para firmar tokens de acceso. Una cadena de certificados típica debe constar de un certificado de CA raíz, un certificado de CA intermedia y un certificado de entidad final.
El certificado de entidad final que firma los tokens JWS no es diferente de un certificado TLS estándar. Puede comprar un certificado de CA públicas como DigiCert o mantener su propia cadena de certificados utilizando certificados de CA raíz autofirmados o módulos de seguridad de hardware. El certificado de entidad final debe ser un certificado X509v3 con una extensión de Nombre alternativo del sujeto (SAN). La extensión SAN contiene un identificador (por ejemplo, nombre de host) del emisor del token. Por último, se deben preferir los certificados RSA a los certificados EC porque el emisor del token solo admite RS256.
Google proporciona un script de shell para generar certificados autofirmados en packages/apps/Car/DebuggingRestrictionController/server/genkey.sh
.
Configurar base de fuego
El emisor del token de referencia utiliza Firebase Authentication y Firebase Cloud Function .
Para configurar su cuenta de Firebase:
- Para crear un proyecto de Firebase, consulte Agregar Firebase a su proyecto de Android .
- Para habilitar algunos autenticadores de Firebase, consulte ¿Por dónde empiezo con la autenticación de Firebase? .
- Para agregar una función de Firebase Cloud vacía, consulte Introducción .
- Si aún no lo ha hecho, instale las herramientas
Node.js
, NPM y Firebase para compilar e implementar el emisor del token.
Integrar la aplicación DRC
La aplicación DRC de referencia se encuentra en packages/apps/Car/DebuggingRestrictionController
. La aplicación se puede crear incluida en AOSP con Soong o desagregada con Gradle .
Construcción incluida
Para crear una aplicación incluida:
- Copie
applicationId
,projectId
yapiKey
degoogle-services.json
enpackages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java
. Al hacerlo, la aplicación DRC se conectará correctamente a Firebase. - Actualice estas constantes en
packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java
:-
TOKEN_USES_SELF_SIGNED_CA
indica si se utilizan certificados de CA raíz autofirmados. Si está habilitada, la aplicación DRC confía solo en el certificado de CA raíz codificado con PEM especificado enROOT_CA_CERT
. -
TOKEN_ISSUER_API_NAME
es el nombre de la función de Firebase Cloud y debe coincidir con la función de nube que creó anteriormente en Firebase Console. -
TOKEN_ISSUER_HOSTNAME
debe coincidir con el nombre alternativo del sujeto en el certificado de entidad final que firmará los tokens de acceso. -
DRC_TEST_EMAIL
yDRC_TEST_PASSWORD
son credenciales para una cuenta de prueba opcional, que se puede aprovisionar previamente en Firebase si ha habilitado el inicio de sesión por correo electrónico/contraseña. Se utilizan únicamente para pruebas instrumentadas.
-
La aplicación ahora está configurada para usar su cuenta de Firebase y sus certificados. En Android 9 y versiones posteriores, debes configurar una lista de permisos permitidos con privilegios . La lista de permitidos debe contener al menos android.permission.MANAGE_USERS
. Por ejemplo:
<permissions> <privapp-permissions package="com.android.car.debuggingrestrictioncontroller"> <permission name="android.permission.INTERNET"/> <permission name="android.permission.MANAGE_USERS"/> </privapp-permissions> </permissions>
Construcción desagregada
Las compilaciones de DRC desagregadas usan Gradle para compilar la aplicación.
Para crear una compilación desagregada:
- Confirma que has instalado el SDK de Android.
- Cree un archivo de texto llamado
local.properties
en el directorio raíz de la aplicación. - Establecer la ubicación del SDK de Android:
sdk.dir=path/to/android/sdk
- Para configurar Firebase, copie
google-services.json
apackages/apps/Car/DebuggingRestrictionController/app
. Gradle analiza el archivo y configura automáticamente el resto. - Definir las variables de entorno. Al igual que con las compilaciones empaquetadas, debes especificar:
-
$TOKEN_USES_SELF_SIGNED_CA
: verdadero o falso; -
$ROOT_CA_CERT
: ruta al certificado de CA raíz codificado en PEM; -
$TOKEN_ISSUER_API_NAME
: nombre de la función Firebase Cloud; -
$TOKEN_ISSUER_HOST_NAME
: SAN en el certificado; -
$DRC_TEST_EMAIL
y$DRC_TEST_EMAI
L: credenciales para una cuenta de prueba, solo compilaciones de depuración.
-
- Para crear la aplicación con Gradle, ejecute un comando como este:
$ ./gradlew build
Integrar el emisor de tokens
El emisor del token de referencia es una función de Firebase Cloud implementada en Node.js
La función solo puede ser invocada por un usuario autenticado. Antes de implementar la aplicación, debe configurar la clave privada y los certificados utilizados para firmar los tokens JWS.
- Complete un archivo JSON con el siguiente contenido:
{ "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" }
Los certificados se ordenan con el certificado de entidad final primero y el certificado de CA raíz al final. El período de vencimiento es personalizable y se puede establecer en una duración más larga si un token emitido tarda algún tiempo antes de que una aplicación DRC pueda recibirlo y consumirlo. No se admite la revocación de tokens.
- Sube la configuración a Firebase:
- Implemente la función Firebase Cloud:
- Para administrar y monitorear su emisor de tokens, consulte Administrar la implementación de funciones y las opciones de tiempo de ejecución .
$ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"
$ firebase deploy --only functions
Establecer restricciones predeterminadas
Se pueden aplicar restricciones predeterminadas antes del primer arranque. Haga esto con superposiciones de recursos estáticos para anular los valores predeterminados en el marco de Android. Se pueden aplicar restricciones respectivamente a diferentes tipos de usuarios. Para obtener información sobre los diferentes tipos de usuarios, consulte Soporte multiusuario .
La restricción predeterminada para el usuario del sistema sin cabeza se puede configurar con la matriz de cadenas config_defaultFirstUserRestrictions
en frameworks/base/core/res/res/values/config.xml
. Establecer esta restricción desactiva automáticamente Android Debug Bridge (ADB) hasta que se elimine la restricción, por ejemplo:
<string-array translatable="false" name="config_defaultFirstUserRestrictions"> <item>no_debugging_features</item> </string-array>
Las restricciones predeterminadas para usuarios habituales (por ejemplo, conductores y pasajeros) e invitados se pueden configurar en frameworks/base/core/res/res/xml/config_user_types.xml
. Puede superponer estas cadenas para establecer las restricciones predeterminadas para cada tipo de usuario respectivamente, por ejemplo:
<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>