Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Guía de integración del controlador de restricción de depuración

Utilice las siguientes instrucciones para integrar el controlador de restricción de depuración AAOS (DRC).

Ejemplo aplicación Figura 1. DRC

Arquitectura

La arquitectura de DRC se ilustra a continuación. Los componentes delineados en rojo (emisor de tokens y controlador de restricción de debut) tienen implementaciones de referencia adjuntas que puede personalizar.

Arquitectura Figura 2. DRC

¿Qué es la República Democrática del Congo?

La unidad de la pista del coche incluye la aplicación de la RDC (véase 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, validar el token 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 de tokens?

Este es un servicio web que firmaron cuestiones criptográficamente tokens de acceso (véase la implementación de referencia en packages/apps/Car/DebuggingRestrictionController/server ). El servicio web de referencia es una función de despliegue Firebase Cloud (para obtener más información, véase Funciones en la nube para Firebase ).

Prerrequisitos

Antes de implementar una implementación de referencia, asegúrese de completar las siguientes tareas.

Preparación de certificados para firmar tokens de acceso

El emisor de tokens 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 solo certificado para firmar tokens de acceso. Una cadena de certificados típica debe constar de un certificado de CA raíz, un certificado de CA intermedio 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, los certificados RSA deben preferirse a los certificados EC porque el emisor del token solo admite RS256.

Google proporciona un script de shell para generar certificados con firma de packages/apps/Car/DebuggingRestrictionController/server/genkey.sh .

Configurando Firebase

La referencia simbólico Emisor utiliza Firebase autenticación y la nube Firebase función .

Para configurar su cuenta de Firebase:

  1. Para crear un proyecto Firebase, consulte Añadir Firebase a su proyecto Android .
  2. Para habilitar algunas autentificadores base de fuego, vea ¿Por dónde empezar con la autenticación de Firebase? .
  3. Para agregar una función Firebase nube vacíos, consulte Get Started .
  4. Si aún no lo ha hecho, instale Node.js, NPM y Firebase Tools para compilar e implementar el Token Issuer.

Integrando la aplicación DRC

La aplicación RDC referencia se encuentra en packages/apps/Car/DebuggingRestrictionController . La aplicación se puede construir en manojos en AOSP con Soong o sólo asiento con Gradle .

Construcción combinada

Para crear una aplicación empaquetada:

  1. Copiar el applicationId , projectId y apiKey de google-services.json en packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java . Hacerlo permite que la aplicación DRC se conecte correctamente a Firebase.
  2. Actualizar estas constantes en packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java :
    • TOKEN_USES_SELF_SIGNED_CA indica si se utilizan certificados de CA raíz firmados. Si está activado, los fideicomisos de aplicaciones DRC sólo el certificado raíz CA-PEM codificado especifica en ROOT_CA_CERT .
    • TOKEN_ISSUER_API_NAME es el nombre de la función Firebase Cloud y debe coincidir con la función de la nube que creó anteriormente en la Consola de Firebase.
    • TOKEN_ISSUER_HOSTNAME debe coincidir con el nombre alternativo del sujeto en el certificado de entidad final que firmarán los tokens de acceso.
    • DRC_TEST_EMAIL y DRC_TEST_PASSWORD son las credenciales de una cuenta de prueba opcional, que puede ser aprovisionado previamente en Firebase si ha habilitado el inicio de sesión de correo electrónico / contraseña. Estos se utilizan solo para pruebas instrumentadas.

La aplicación ahora está configurada para usar su cuenta de Firebase y sus certificados. En Android 9 y superior, debe configurar el permiso privilegiado Allowlisting . El AllowList 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 DRC desagregadas usan Gradle para compilar la aplicación.

Para crear una compilación desagregada:

  1. Confirma que has instalado el SDK de Android.
  2. Crear un archivo de texto denominado local.properties en el directorio raíz de la aplicación.
  3. Establecer la ubicación del SDK de Android:
     sdk.dir=path/to/android/sdk
    
  4. Para configurar Firebase, copiar google-services.json a packages/apps/Car/DebuggingRestrictionController/app . Gradle analiza el archivo y configura automáticamente el resto.
  5. Defina las variables de entorno. Al igual que con las compilaciones empaquetadas, debe especificar:
    • $TOKEN_USES_SELF_SIGNED_CA : verdadero o falso;
    • $ROOT_CA_CERT : ruta al certificado raíz de la CA-PEM codificado;
    • $TOKEN_ISSUER_API_NAME : nombre de la función Firebase la nube;
    • $TOKEN_ISSUER_HOST_NAME : SAN en el certificado;
    • $DRC_TEST_EMAIL y $DRC_TEST_EMAI L: credenciales de una cuenta de prueba, versiones de depuración solamente.
  6. Para construir la aplicación con Gradle, ejecutar un comando como este:
    $ ./gradlew build
    

Integración del emisor de tokens

El emisor de tokens de referencia es una función de nube de Firebase 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.

  1. Rellenar 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 solicitan 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 pueda ser recibido y consumido por una aplicación de DRC. No se admite la revocación de tokens.

  2. Sube la configuración a Firebase:
  3. $ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"
    
  4. Implementa la función de Firebase Cloud:
  5. $ firebase deploy --only functions
    
  6. Para gestionar y controlar su Token Emisor, consulte Administración de opciones de implementación y funciones de tiempo de ejecución .

Establecer restricciones predeterminadas

Las restricciones predeterminadas se pueden aplicar antes del primer arranque. Haga esto con superposiciones de recursos estáticos para anular los valores predeterminados en el marco de Android. Las restricciones se pueden aplicar respectivamente a diferentes tipos de usuarios. Para aprender sobre los diferentes tipos de usuarios, consulte Soporte para múltiples usuarios .

La restricción por defecto para el usuario del sistema sin cabeza se puede configurar con la config_defaultFirstUserRestrictions string-matriz en frameworks/base/core/res/res/values/config.xml . Establecer esta restricción deshabilita 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 los usuarios habituales (por ejemplo, los conductores y pasajeros), y los huéspedes pueden configurarse 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>