O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

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 desta página para integrar o controlador de restrição de depuração do AAOS (RDC).

Figura 1. Exemplo de app da DRC.

Arquitetura

A arquitetura da DRC está ilustrada na Figura 2. Componentes destacados em vermelho (emissor de token e DRC) têm implementações de referência complementares que podem ser personalizadas.

Figura 2. Arquitetura da DRC.

O que é a República Democrática Alemã?

A unidade principal do carro inclui o app DRC (consulte a implementação de referência em packages/apps/Car/DebuggingRestrictionController). O app de referência inclui a lógica para receber um token de acesso do emissor do token, validando-o; e Em seguida, aplique as 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 da Web que emite tokens de acesso assinados criptograficamente (consulte a referência implementação em packages/apps/Car/DebuggingRestrictionController/server). O serviço da Web de referência é uma função implantável do Cloud do Firebase. Para saber mais, consulte O Cloud Functions para Firebase).

Pré-requisitos

Antes de implantar uma implementação de referência, conclua as tarefas a seguir.

Preparar certificados para assinar tokens de acesso

O emissor do token gera JSON Web Signature (JWS) como tokens de acesso. Para otimizar compatibilidade, o emissor de referência oferece suporte apenas ao algoritmo RS256 (assinaturas RSA com SHA256). Para facilitar a rotação de chaves, use uma cadeia de certificados em vez de um único certificado para assinar ou 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 de entidade final que assina os tokens JWS não é diferente do TLS padrão certificado. Você pode comprar um certificado de CAs públicas, como a DigiCert, ou manter sua própria cadeia de certificados usando certificados raiz autoassinados ou módulos de segurança de hardware. O certificado de entidade final precisa ser X509v3 com um nome alternativo do assunto (SAN, na sigla em inglês). A extensão SAN contém um identificador (por exemplo, nome do host) do token emissor. Por último, os certificados RSA devem ter preferência em relação aos certificados de EC porque o token o emissor aceita apenas RS256.

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

Configurar o Firebase

O emissor do token de referência usa Firebase Authentication e Função do Cloud do Firebase.

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 Onde começar com o Firebase Authentication?.
Para adicionar uma função do Cloud do Firebase vazia, consulte Receba iniciado.
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ê vai receber uma solicitação para fazer o download de um arquivo de configuração chamado google-services.json. Este arquivo não contém informações sensíveis e são consumidas pelo app de DRC de referência e pelo emissor do token mais tarde.

Integrar o app DRC

O app de referência da DRC está localizado em packages/apps/Car/DebuggingRestrictionController: O app pode ser criado incluído no AOSP com Soong ou desagrupado com o Gradle (links em inglês).

Criação em pacote

Para criar um app empacotado:

Copie applicationId, projectId e apiKey de google-services.json para packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java. Isso permite que o app DRC se conecte corretamente ao Firebase.
Atualize essas constantes em packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java:
- TOKEN_USES_SELF_SIGNED_CA indica se os certificados de CA raiz autoassinados usados. Se ativado, o aplicativo DRC confiará apenas no certificado da CA raiz codificado em PEM especificado em ROOT_CA_CERT:
- TOKEN_ISSUER_API_NAME é o nome da função do Cloud no Firebase e precisa corresponder à função do Cloud que você criou anteriormente no console do Firebase.
- TOKEN_ISSUER_HOSTNAME deve corresponder ao nome alternativo do assunto na certificado de 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 Login com e-mail/senha. Eles são usados apenas para testes instrumentados.

Agora o app está configurado para usar sua conta do Firebase e seus certificados. No Android 9 e versões mais recentes, é necessário configurar lista de permissões de permissões privilegiadas. A lista de permissões precisa conter pelo menos android.permission.MANAGE_USERS. Exemplo:

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

Build desagrupado

Os builds do DRC desagrupados usam o Gradle para compilar o app.

Para criar um build desagrupado:

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

Integrar o emissor do token

O emissor do token de referência é uma função do Cloud do Firebase implementada em Node.js. A função só pode ser chamada por um usuário autenticado. Antes de implantar o app, é preciso 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 ordenados com o certificado de entidade final primeiro e o certificado de CA raiz no final. O período de expiração é personalizável e pode ser definido com uma duração maior se uma token emitido leva algum tempo antes de ser recebido e consumido por um aplicativo de DRC. Token não há suporte à revogação.

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

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

Implante a função do Cloud no Firebase:

$ firebase deploy --only functions

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

Definir restrições padrão

As restrições padrão podem ser aplicadas antes da primeira inicialização. Fazer isso com recursos estáticos para substituir os padrões no framework do Android. As restrições podem ser, respectivamente, aplicados a diferentes tipos de usuários. Para saber mais sobre os diferentes tipos de usuários, consulte Suporte a vários usuários.

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 esta 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 comuns (por exemplo, motoristas e passageiros) e convidados podem ser configurados em frameworks/base/core/res/res/xml/config_user_types.xml Você pode sobrepor essas strings para definir as restrições padrão em 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>