Use as instruções a seguir para integrar o AAOS Debugging Restriction Controller (DRC).
Figura 1. Exemplo de aplicativo DRC
Arquitetura
A arquitetura DRC é ilustrada abaixo. Os componentes destacados em vermelho (Emissor de token e Controlador de restrição inicial) têm implementações de referência que podem ser personalizadas.
Figura 2. Arquitetura DRC
O que é a RDC?
A unidade principal do carro inclui o aplicativo DRC (consulte 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 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.
O que é o emissor de tokens?
Este é um serviço da web que emite tokens de acesso assinados criptograficamente (consulte a implementação de referência em packages/apps/Car/DebuggingRestrictionController/server
). O serviço web de referência é uma função implantável do Firebase Cloud (para saber mais, consulte Funções do Cloud para Firebase ).
Pré-requisitos
Antes de implantar uma implementação de referência, certifique-se de concluir as tarefas a seguir.
Preparando certificados para assinar tokens de acesso
O emissor de token gera JSON Web Signatures (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, use 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 de entidade final que assina os tokens JWS não é diferente de um certificado TLS padrão. Você pode comprar 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 de 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 fim, 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
.
Configurando o Firebase
O Token Issuer de referência usa Firebase Authentication e Firebase Cloud Function .
Para configurar sua conta do Firebase:
- Para criar um projeto Firebase, consulte Adicionar Firebase ao seu projeto Android .
- Para habilitar alguns autenticadores do Firebase, consulte Por onde começo com o Firebase Authentication? .
- Para adicionar uma função vazia do Firebase Cloud, consulte Introdução .
- Se ainda não tiver feito isso, instale Node.js, NPM e Firebase Tools para compilar e implantar o Token Issuer.
Integrando o aplicativo DRC
O aplicativo DRC de referência está localizado em packages/apps/Car/DebuggingRestrictionController
. O aplicativo pode ser construído junto com o AOSP com o Soong ou separado com o Gradle .
compilação empacotada
Para criar um aplicativo integrado:
- Copie
applicationId
,projectId
eapiKey
degoogle-services.json
parapackages/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 emROOT_CA_CERT
. -
TOKEN_ISSUER_API_NAME
é o nome da função Firebase Cloud e deve corresponder à função 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
eDRC_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. Estes 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 superior, você deve configurar a lista de permissões de permissão privilegiada . 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>
Compilação desagregada
Compilações DRC desagregadas usam Gradle para compilar o aplicativo.
Para criar uma compilação desagregada:
- Confirme se 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
parapackages/apps/Car/DebuggingRestrictionController/app
. Gradle analisa o arquivo e configura automaticamente o resto. - Defina as variáveis de ambiente. Tal como acontece com as compilações agrupadas, você deve especificar:
-
$TOKEN_USES_SELF_SIGNED_CA
: verdadeiro ou falso; -
$ROOT_CA_CERT
: caminho para o certificado CA raiz codificado por 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 criar o aplicativo com Gradle, execute um comando como este:
$ ./gradlew build
Integrando o emissor de token
O Token Issuer 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 implantar 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 com o certificado de entidade final primeiro e o certificado 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 ser recebido e consumido por um aplicativo DRC. A revogação de token não é suportada.
- Carregue a configuração no Firebase:
- Implante a função Firebase Cloud:
- Para gerenciar e monitorar seu emissor de token, consulte Gerenciar funções de implementação e opções de tempo de execução .
$ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"
$ firebase deploy --only functions
Definindo 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 em 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 o string-array 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 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>