Os smartphones contêm vários processadores, cada um otimizado para realizar tarefas diferentes. No entanto, o Android só é executado em um processador: o processador de aplicativos (AP). O AP é ajustado para oferecer ótimo desempenho em casos de uso com a tela ativada, como jogos, mas consome muita energia para oferecer suporte a recursos que exigem bursts curtos e frequentes de processamento o tempo todo, mesmo quando a tela está desativada. Processadores menores podem lidar com essas cargas de trabalho com mais eficiência, concluindo as tarefas sem afetar a duração da bateria. No entanto, os ambientes de software nesses processadores de baixa potência são mais limitados e podem variar muito, dificultando o desenvolvimento multiplataforma.
O ambiente de execução do hub de contexto (CHRE, na sigla em inglês) oferece uma plataforma comum para executar apps em um processador de baixa potência, com uma API simples, padronizada e compatível com incorporação. O CHRE facilita para os OEMs de dispositivos e parceiros confiáveis descarregar o processamento do AP, economizar bateria e melhorar várias áreas da experiência do usuário, além de ativar uma classe de recursos sempre ativados e contextualmente conscientes, especialmente aqueles que envolvem a aplicação de machine learning à detecção de ambiente.
Principais conceitos
O CHRE é o ambiente de software em que pequenos apps nativos, chamados
nanoapps, são executados em um processador de baixa potência e interagem com o
sistema subjacente pela API CHRE comum. Para acelerar a implementação adequada das APIs CHRE, uma implementação de referência multiplataforma do CHRE está incluída no AOSP. A implementação de referência inclui código e abstrações comuns para o hardware e software subjacentes por meio de uma série de camadas de abstração de plataforma (PALs). Os nanoapps quase sempre estão vinculados a um ou mais apps clientes em execução no
Android, que interagem com o CHRE e os nanoapps por APIs de sistema
ContextHubManager.
Em um nível alto, é possível fazer paralelos entre a arquitetura do CHRE e o Android como um todo. No entanto, há algumas distinções importantes:
- O CHRE oferece suporte à execução apenas de nanoapps desenvolvidos em código nativo (C ou C++); o Java não é compatível.
- Devido a restrições de recursos e limitações de segurança, o CHRE não está aberto para uso por apps Android de terceiros arbitrários. Somente apps confiáveis do sistema podem acessá-lo.
Também há uma distinção importante a ser feita entre o conceito de CHRE e um hub de sensores. Embora seja comum usar o mesmo hardware para implementar o hub de sensores e o CHRE, o CHRE em si não oferece os recursos de sensor exigidos pelo HAL de sensores do Android. O CHRE está vinculado ao HAL do hub de contexto e atua como um cliente de um framework de sensor específico do dispositivo para receber dados do sensor sem envolver o AP.
Figura 1. Arquitetura do framework CHRE
HAL do hub de contexto
A camada de abstração de hardware (HAL) do hub de contexto é a interface entre o
framework do Android e a implementação do CHRE do dispositivo, definida em
hardware/interfaces/contexthub.
O HAL do hub de contexto define as APIs pelas quais o framework do Android descobre os hubs de contexto disponíveis e os nanoapps deles, interage com esses nanoapps por passagem de mensagens e permite que os nanoapps sejam carregados e descarregados. Uma implementação de referência do HAL do hub de contexto que funciona com a
implementação de referência do CHRE está disponível em
system/chre/host.
Em caso de conflito entre esta documentação e a definição do HAL, a definição do HAL terá precedência.
Inicialização
Quando o Android é inicializado, o
ContextHubService
invoca a função getHubs() HAL para determinar se há hubs de contexto
disponíveis no dispositivo. Essa é uma chamada de bloqueio única, então ela precisa ser concluída rapidamente para evitar atrasos na inicialização e retornar um resultado preciso, já que novos hubs de contexto não podem ser introduzidos depois.
Carregar e descarregar nanoapps
Um hub de contexto pode incluir um conjunto de nanoapps que estão incluídos na imagem do dispositivo e são carregados quando o CHRE é iniciado. Eles são conhecidos como nanoapps pré-carregados e precisam ser incluídos na primeira resposta possível a queryApps().
O HAL do hub de contexto também oferece suporte ao carregamento e descarregamento dinâmico de nanoapps no ambiente de execução, pelas funções loadNanoApp() e unloadNanoApp(). Os nanoapps são fornecidos ao HAL em um formato binário específico para a implementação de hardware e software do CHRE do dispositivo.
Se a implementação para carregar um nanoapp envolver a gravação dele na memória não volátil, como o armazenamento flash conectado ao processador que executa o CHRE, a implementação do CHRE sempre precisará ser inicializada com esses nanoapps dinâmicos no estado desativado. Isso significa que nenhum código do nanoapp será executado até que uma solicitação enableNanoapp() seja recebida pelo HAL. Os nanoapps pré-carregados podem ser inicializados no estado ativado.
Reinicializações do hub de contexto
Embora não seja esperado que o CHRE seja reinicializado durante a operação normal, pode ser necessário se recuperar de condições inesperadas, como uma tentativa de acessar um endereço de memória não mapeado. Nessas situações, o CHRE é reinicializado de forma independente do Android. O HAL notifica o Android sobre isso pelo evento RESTARTED, que precisa ser enviado somente depois que o CHRE for reinicializado a ponto de aceitar novas solicitações, como queryApps().
Visão geral do sistema CHRE
O CHRE foi projetado em torno de uma arquitetura orientada a eventos, em que a unidade principal de computação é um evento transmitido ao ponto de entrada de processamento de eventos de um nanoapp. Embora o framework CHRE possa ser multithread, um determinado nanoapp nunca é executado em várias linhas de execução em paralelo. O framework CHRE interage com um determinado nanoapp por um dos três pontos de entrada do nanoapp (nanoappStart(), nanoappHandleEvent() e nanoappEnd()) ou por um callback fornecido em uma chamada de API CHRE anterior, e os nanoapps interagem com o framework CHRE e o sistema subjacente pela API CHRE. A API CHRE oferece um conjunto de recursos básicos, bem como instalações para acessar sinais contextuais, incluindo sensores, GNSS, Wi-Fi, WWAN e áudio, e pode ser estendida com outros recursos específicos do fornecedor para uso por nanoapps específicos do fornecedor.
Sistema de build
Embora o HAL do hub de contexto e outros componentes necessários do lado do AP sejam criados junto com o Android, o código executado no CHRE pode ter requisitos que o tornam incompatível com o sistema de build do Android, como a necessidade de um conjunto de ferramentas especializado. Portanto, o projeto CHRE no AOSP oferece um sistema de build simplificado com base no GNU Make para compilar nanoapps e, opcionalmente, o framework CHRE em bibliotecas que podem ser integradas ao sistema. Os fabricantes de dispositivos que adicionam suporte ao CHRE precisam integrar o suporte do sistema de build para os dispositivos de destino no AOSP.
A API CHRE é escrita no padrão de linguagem C99, e a implementação de referência usa um subconjunto restrito de C++11 adequado para apps com recursos limitados.
API CHRE
A API CHRE é uma coleção de arquivos de cabeçalho C que definem a interface de software entre um nanoapp e o sistema. Ela foi projetada para tornar o código de nanoapps compatível em todos os dispositivos que oferecem suporte ao CHRE, o que significa que o código-fonte de um nanoapp não precisa ser modificado para oferecer suporte a um novo tipo de dispositivo, embora possa ser necessário recompilar especificamente para o conjunto de instruções do processador do dispositivo de destino ou interface binária do aplicativo (ABI). A arquitetura CHRE e o design da API também garantem que os nanoapps sejam compatíveis com binários em diferentes versões da API CHRE, o que significa que um nanoapp não precisa ser recompilado para ser executado em um sistema que implementa uma versão diferente da API CHRE em comparação com a API de destino em que o nanoapp é compilado. Em outras palavras, se um binário de nanoapp for executado em um dispositivo que oferece suporte à API CHRE v1.3 e esse dispositivo for atualizado para oferecer suporte à API CHRE v1.4, o mesmo binário de nanoapp continuará funcionando. Da mesma forma, o nanoapp pode ser executado na API CHRE v1.2 e pode determinar no ambiente de execução se ele exige recursos da API v1.3 para atingir o uso ou se ele pode operar, possivelmente com degradação de recursos.
Resumo da versão
Assim como o
esquema de controle de versão do HIDL do Android,
a API CHRE segue o controle de versão semântica.
A versão principal indica compatibilidade binária, enquanto a versão secundária é incrementada quando recursos compatíveis com versões anteriores são introduzidos. A API CHRE inclui anotações de código-fonte para identificar qual versão introduziu uma função ou parâmetro, por exemplo, @since v1.1.
A implementação do CHRE também expõe uma versão de patch específica da plataforma por chreGetVersion(), que indica quando correções de bugs ou atualizações secundárias são feitas na implementação.
Para resumos de cada versão, consulte version.h.
Recursos obrigatórios do sistema
Embora as fontes de sinais contextuais, como sensores, sejam categorizadas em áreas de recursos opcionais, algumas funções principais são necessárias em todas as implementações do CHRE. Isso inclui APIs de sistema principais, como aquelas para definir timers, enviar e receber mensagens para clientes no processador de aplicativos, fazer registros e outras. Para detalhes completos, consulte os cabeçalhos da API.
Além dos recursos principais do sistema codificados na API CHRE, também há recursos obrigatórios do sistema CHRE especificados no nível HAL do hub de contexto. O mais significativo deles é a capacidade de carregar e descarregar nanoapps dinamicamente.
Biblioteca padrão C/C++
Para minimizar o uso da memória e a complexidade do sistema, as implementações do CHRE precisam oferecer suporte apenas a um subconjunto das bibliotecas C e C++ padrão e recursos de linguagem que exigem suporte de ambiente de execução. Seguindo esses princípios, alguns recursos são explicitamente excluídos devido à memória e às dependências extensas no nível do SO, e outros porque são substituídos por APIs mais adequadas específicas do CHRE. Embora não seja uma lista completa, os seguintes recursos não se destinam a ser disponibilizados para nanoapps:
- Exceções C++ e informações de tipo de ambiente de execução (RTTI)
- Suporte multithread da biblioteca padrão, incluindo cabeçalhos C++11
<thread>,<mutex>,<atomic>,<future> - Bibliotecas de entrada/saída padrão C e C++
- Biblioteca de modelos padrão C++ (STL)
- Biblioteca de expressões regulares padrão C++
- Alocação de memória dinâmica por funções padrão (por exemplo,
malloc,calloc,realloc,free,operator new) e outras funções de biblioteca padrão que usam alocação dinâmica, comostd::unique_ptr - Suporte a localização e caracteres Unicode
- Bibliotecas de data e hora
- Funções que modificam o fluxo normal do programa, incluindo
<setjmp.h>,<signal.h>,abort,std::terminate - Acessar o ambiente do host, incluindo
system,getenv - POSIX e outras bibliotecas não incluídas nos padrões de linguagem C99 ou C++11
Em muitos casos, recursos equivalentes estão disponíveis nas funções da API CHRE e nas bibliotecas de utilitários. Por exemplo, chreLog pode ser usado para registro de depuração direcionado ao sistema logcat do Android, em que um programa mais tradicional pode usar printf ou std::cout.
Por outro lado, alguns recursos da biblioteca padrão são necessários. Cabe à implementação da plataforma expor esses recursos por bibliotecas estáticas para inclusão em um binário de nanoapp ou por vinculação dinâmica entre o nanoapp e o sistema. Isso inclui, mas não se limita a:
- Utilitários de string e matriz:
memcmp,memcpy,memmove,memset,strlen Biblioteca matemática: funções de ponto flutuante de precisão única usadas com frequência:
- Operações básicas:
ceilf,fabsf,floorf,fmaxf,fminf,fmodf,roundf,lroundf,remainderf - Funções exponenciais e de potência:
expf,log2f,powf,sqrtf - Funções trigonométricas e hiperbólicas:
sinf,cosf,tanf,asinf,acosf,atan2f,tanhf
- Operações básicas:
Embora algumas plataformas subjacentes ofereçam suporte a outros recursos, um nanoapp não é considerado portátil em implementações do CHRE, a menos que restrinja as dependências externas às funções da API CHRE e às funções de biblioteca padrão aprovadas.
Recursos opcionais
Para promover hardware e software, a API CHRE é dividida em áreas de recursos, que são consideradas opcionais do ponto de vista da API. Embora esses recursos não sejam necessários para oferecer suporte a uma implementação compatível do CHRE, eles podem ser necessários para oferecer suporte a um nanoapp específico. Mesmo que uma plataforma não ofereça suporte a um determinado conjunto de APIs, os nanoapps que fazem referência a essas funções precisam ser capazes de criar e carregar.
Sensores
A API CHRE oferece a capacidade de solicitar dados de sensores, incluindo acelerômetro, giroscópio, magnetômetro, sensor de luz ambiente e proximidade. Essas APIs têm como objetivo fornecer um conjunto de atributos semelhante às APIs de sensores do Android, incluindo suporte para amostras de sensores em lote para reduzir o consumo de energia. O processamento de dados do sensor no CHRE permite um processamento de sinais de movimento com muito menos energia e latência em comparação com a execução no AP.
GNSS
O CHRE fornece APIs para solicitar dados de localização de um sistema global de navegação por satélite (GNSS), incluindo GPS e outras constelações de satélites. Isso inclui solicitações de correções de posição periódicas, bem como dados de medição brutos, embora ambos sejam recursos independentes. Como o CHRE tem um link direto para o subsistema GNSS, a energia é reduzida em comparação com as solicitações GNSS baseadas em AP, porque o AP pode permanecer inativo durante todo o ciclo de vida de uma sessão de localização.
Wi-Fi
O CHRE oferece a capacidade de interagir com o chip Wi-Fi, principalmente para fins de localização. Embora o GNSS funcione bem para locais externos, os resultados das verificações de Wi-Fi podem fornecer informações de localização precisas em ambientes internos e em áreas desenvolvidas. Além de evitar o custo de ativar o AP para uma verificação, o CHRE pode ouvir os resultados das verificações de Wi-Fi realizadas pelo firmware Wi-Fi para fins de conectividade, que normalmente não são entregues ao AP por motivos de energia. Aproveitar as verificações de conectividade para fins contextuais ajuda a reduzir o número total de verificações de Wi-Fi realizadas, economizando energia.
O suporte a Wi-Fi foi adicionado na API CHRE v1.1, incluindo a capacidade de monitorar os resultados da verificação e acionar verificações sob demanda. Esses recursos foram estendidos na v1.2 com a capacidade de realizar medições de tempo de retorno (RTT) em pontos de acesso que oferecem suporte ao recurso, o que permite a determinação precisa da posição relativa.
WWAN
A API CHRE oferece a capacidade de recuperar informações de identificação de célula para a célula de serviço e os vizinhos dela, que normalmente são usadas para fins de localização aproximada.
Áudio
O CHRE pode processar lotes de dados de áudio de um microfone de baixa potência, que normalmente aproveita o hardware usado para implementar o HAL SoundTrigger. O processamento de dados de áudio no CHRE permite que ele seja mesclado com outros dados, como sensores de movimento.
Bluetooth
O CHRE oferece APIs que oferecem suporte a um subconjunto de funcionalidades do Bluetooth que se beneficiam do descarregamento de baixa potência. O CHRE permite que os nanoapps realizem verificações de BLE, monitorem o RSSI e processem dados de publicidade BLE sem ativar o AP. Além disso, a propriedade de uma conexão de soquete Bluetooth estabelecida pode ser movida para o domínio de descarregamento, o que exige menos energia para manutenção e permite que os nanoapps se comuniquem pela conexão de soquete BLE descarregada.
Implementação de referência
O código de referência para o framework CHRE está incluído no AOSP no projeto system/chre, implementado em C++11. Embora não seja estritamente necessário, é recomendável que todas as implementações do CHRE sejam baseadas nessa base de código para garantir a consistência e acelerar a adoção de novos recursos. Esse código pode ser visto como análogo ao framework principal do Android, já que é uma implementação de código aberto de APIs usadas por apps, servindo como uma linha de base e padrão de compatibilidade. Embora possa ser personalizado e estendido com recursos específicos do fornecedor, a recomendação é manter o código comum o mais próximo possível da referência. Semelhante aos HALs do Android, a implementação de referência do CHRE usa várias abstrações de plataforma para permitir que ela seja adaptada a qualquer dispositivo que atenda aos requisitos mínimos.
Para detalhes técnicos e um guia de portabilidade, consulte o
LEIAME
incluído no system/chre projeto.