Esta página foi traduzida pela API Cloud Translation.

Guia de integração do controlador de restrição de depuração

Use as instruções nesta página para integrar o Controlador de Restrição de Depuração AAOS (DRC).

Figura 1. Exemplo de aplicativo RDC.

Arquitetura

A arquitetura DRC é ilustrada na Figura 2. Os componentes destacados em vermelho (emissor de token e DRC) acompanham implementações de referência que você pode personalizar.

Figura 2. Arquitetura RDC.

O que é a RDC?

A unidade principal do carro inclui o aplicativo DRC (veja a implementação de referência em packages/apps/Car/DebuggingRestrictionController ). O aplicativo de referência inclui a lógica para receber um token de acesso do emissor do token, validar o token e, em seguida, aplicar alterações de restrição de depuração conforme especificado no token. A lógica inclui elementos básicos de UX no lado do carro.

Qual é o emissor do token?

Este é um serviço web que emite tokens de acesso assinados criptograficamente (veja a implementação de referência em packages/apps/Car/DebuggingRestrictionController/server ). O serviço da Web de referência é uma função implantável do Firebase Cloud (para saber mais, consulte Cloud Functions para Firebase ).

Pré-requisitos

Antes de implementar uma implementação de referência, certifique-se de concluir as tarefas a seguir.

Preparar certificados para assinar tokens de acesso

O emissor do token gera assinaturas JSON Web (JWS) como tokens de acesso. Para compatibilidade ideal, o emissor de referência suporta apenas o algoritmo RS256 (assinaturas RSA com SHA256). Para facilitar a rotação de chaves, utilize uma cadeia de certificados em vez de um único certificado para assinar tokens de acesso. Uma cadeia de certificados típica deve consistir em um certificado de CA raiz, um certificado de CA intermediário e um certificado de entidade final.

O certificado da entidade final que assina os tokens JWS não é diferente de um certificado TLS padrão. Você pode adquirir um certificado de CAs públicas, como DigiCert, ou manter sua própria cadeia de certificados usando certificados de CA raiz autoassinados ou módulos de segurança de hardware. O certificado da entidade final deve ser um certificado X509v3 com uma extensão Subject Alternative Name (SAN). A extensão SAN contém um identificador (por exemplo, nome do host) do emissor do token. Por último, os certificados RSA devem ser preferidos aos certificados EC porque o emissor do token suporta apenas RS256.

O Google fornece um script de shell para gerar certificados autoassinados em packages/apps/Car/DebuggingRestrictionController/server/genkey.sh .

Configurar o Firebase

O emissor do token de referência usa Firebase Authentication e Firebase Cloud Function .

Para configurar sua conta do Firebase:

Para criar um projeto do Firebase, consulte Adicionar o Firebase ao seu projeto Android .
Para ativar alguns autenticadores do Firebase, consulte Por onde começo com o Firebase Authentication? .
Para adicionar uma função vazia do Firebase Cloud, consulte Primeiros passos .
Se ainda não tiver feito isso, instale as ferramentas Node.js , NPM e Firebase para compilar e implantar o emissor do token.
Observação: depois de criar um projeto do Firebase, você será solicitado a fazer download de um arquivo de configuração chamado google-services.json . Este arquivo não contém informações confidenciais e é consumido posteriormente pelo aplicativo DRC de referência e pelo emissor do token.

Integre o aplicativo RDC

O aplicativo DRC de referência está localizado em packages/apps/Car/DebuggingRestrictionController . O aplicativo pode ser construído empacotado em AOSP com Soong ou desagregado com Gradle .

Compilação em pacote

Para criar um aplicativo empacotado:

Copie applicationId , projectId e apiKey de google-services.json em packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java . Isso permite que o aplicativo DRC se conecte corretamente ao Firebase.
Atualize essas constantes em packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java :
- TOKEN_USES_SELF_SIGNED_CA indica se certificados de CA raiz autoassinados são usados. Se ativado, o aplicativo DRC confia apenas no certificado CA raiz codificado por PEM especificado em ROOT_CA_CERT .
- TOKEN_ISSUER_API_NAME é o nome da função do Firebase Cloud e deve corresponder à função do Cloud que você criou anteriormente no Firebase Console.
- TOKEN_ISSUER_HOSTNAME deve corresponder ao Nome Alternativo do Assunto no certificado da entidade final que assinará os tokens de acesso.
- DRC_TEST_EMAIL e DRC_TEST_PASSWORD são credenciais para uma conta de teste opcional, que pode ser pré-provisionada no Firebase se você tiver ativado o login por e-mail/senha. Eles são usados apenas para testes instrumentados.

O aplicativo agora está configurado para usar sua conta do Firebase e seus certificados. No Android 9 e versões posteriores, você deve configurar a lista de permissões de permissões privilegiadas . A lista de permissões deve conter pelo menos android.permission.MANAGE_USERS . Por exemplo:

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

Construção desagregada

As compilações DRC desagregadas usam Gradle para compilar o aplicativo.

Para criar uma compilação desagregada:

Confirme que você instalou o Android SDK.
Crie um arquivo de texto chamado local.properties no diretório raiz do aplicativo.
Defina a localização do Android SDK:
```
 sdk.dir=path/to/android/sdk
```
Para configurar o Firebase, copie google-services.json para packages/apps/Car/DebuggingRestrictionController/app . Gradle analisa o arquivo e configura automaticamente o restante.
Defina as variáveis de ambiente. Tal como acontece com as compilações em pacote, você deve especificar:
- $TOKEN_USES_SELF_SIGNED_CA : verdadeiro ou falso;
- $ROOT_CA_CERT : caminho para o certificado CA raiz codificado em PEM;
- $TOKEN_ISSUER_API_NAME : nome da função Firebase Cloud;
- $TOKEN_ISSUER_HOST_NAME : SAN no certificado;
- $DRC_TEST_EMAIL e $DRC_TEST_EMAI L: credenciais para uma conta de teste, apenas compilações de depuração.
Para construir o aplicativo com Gradle, execute um comando como este:
```
$ ./gradlew build
```
Observação: um aplicativo DRC desagregado deve ser assinado com o certificado da plataforma porque requer uma permissão privilegiada, MANAGE_USERS . a lista de permissões de permissão privilegiada ainda é necessária pelo mesmo motivo.

Integre o emissor do token

O emissor do token de referência é uma Firebase Cloud Function implementada em Node.js A função só pode ser chamada por um usuário autenticado. Antes de implementar o aplicativo, você deve configurar a chave privada e os certificados usados para assinar os tokens JWS.

Preencha um arquivo JSON com o seguinte conteúdo:

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

Os certificados são solicitados primeiro com o certificado da entidade final e o certificado da CA raiz no final. O período de expiração é personalizável e pode ser definido para uma duração mais longa se um token emitido demorar algum tempo antes de poder ser recebido e consumido por um aplicativo DRC. A revogação de token não é suportada.

Faça upload da configuração para o Firebase:

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

Implante a função Firebase Cloud:

$ firebase deploy --only functions

Para gerenciar e monitorar seu emissor de token, consulte Gerenciar implementação de funções e opções de tempo de execução .

Definir restrições padrão

As restrições padrão podem ser aplicadas antes da primeira inicialização. Faça isso com sobreposições de recursos estáticos para substituir os padrões na estrutura do Android. As restrições podem ser aplicadas respectivamente a diferentes tipos de usuários. Para saber mais sobre os diferentes tipos de usuários, consulte Suporte multiusuário .

A restrição padrão para o usuário do sistema headless pode ser configurada com a matriz de strings config_defaultFirstUserRestrictions em frameworks/base/core/res/res/values/config.xml . Definir essa restrição desativa automaticamente o Android Debug Bridge (ADB) até que a restrição seja removida, por exemplo:

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

As restrições padrão para usuários regulares (por exemplo, motoristas e passageiros) e convidados podem ser configuradas em frameworks/base/core/res/res/xml/config_user_types.xml . Você pode sobrepor essas strings para definir as restrições padrão para cada tipo de usuário, respectivamente, por exemplo:

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