Ambiente de execução do hub de contexto (CHRE, na sigla em inglês)

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, na sigla em inglês). O AP é ajustado para oferecer ótima performance em casos de uso com a tela ligada, como jogos. No entanto, ele consome muita energia para oferecer suporte a recursos que exigem processamento frequente e rápido o tempo todo, mesmo quando a tela está desligada. Processadores menores conseguem lidar com essas cargas de trabalho de maneira mais eficiente, concluindo as tarefas sem afetar significativamente 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 dispositivos incorporados. 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 permitir uma classe de recursos sempre ativos e contextualmente conscientes, especialmente aqueles que envolvem a aplicação de machine learning à detecção ambiental.

Principais conceitos

O CHRE é o ambiente de software em que pequenos apps nativos, chamados de nanoapps, são executados em um processador de baixo consumo de energia 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, na sigla em inglês). Os nanapps quase sempre estão vinculados a um ou mais apps clientes em execução no Android, que interagem com o CHRE e os nanapps por APIs do sistema ContextHubManager de acesso restrito.

Em um nível mais alto, é possível fazer paralelos entre a arquitetura do CHRE e do Android como um todo. No entanto, há algumas distinções importantes:

  • O CHRE só é compatível com a execução 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 arbitrários de terceiros. Somente apps confiáveis pelo sistema podem acessar esse recurso.

Também é importante distinguir 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 não oferece os recursos de sensor exigidos pela HAL de sensores do Android. A CHRE está vinculada à HAL do Context Hub e atua como um cliente de uma estrutura de sensor específica do dispositivo para receber dados de sensores sem envolver o AP.

Arquitetura do framework CHRE

Figura 1. Arquitetura do framework CHRE

HAL do hub de contexto

A camada de abstração de hardware (HAL) do Context Hub é a interface entre a estrutura do Android e a implementação do CHRE do dispositivo, definida em hardware/interfaces/contexthub. A HAL do Context Hub 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 transmissão de mensagens e permite que os nanoapps sejam carregados e descarregados. Uma implementação de referência da HAL do Context Hub 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 de HAL, a definição de HAL prevalece.

Inicialização

Quando o Android é inicializado, o ContextHubService invoca a função HAL getHubs() para determinar se há hubs de contexto disponíveis no dispositivo. Essa é uma chamada única e de bloqueio. Portanto, 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 nanapps que são incluídos na imagem do dispositivo e 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().

A HAL do Context Hub também oferece suporte ao carregamento e descarregamento dinâmicos de nanoapps em tempo de execução, usando as funções loadNanoApp() e unloadNanoApp(). Os nanoapps são fornecidos à HAL em um formato binário específico para a implementação de hardware e software do dispositivo CHRE.

Se a implementação para carregar um nanoapp envolver a gravação dele em memória não volátil, como o armazenamento flash conectado ao processador que executa o CHRE, a implementação do CHRE sempre será inicializada com esses nanoapps dinâmicos no estado desativado. Isso significa que nenhum código do nanoapp é executado até que uma solicitação enableNanoapp() seja recebida pela 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 reiniciado 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 é reiniciado de forma independente do Android. A HAL notifica o Android sobre isso pelo evento RESTARTED, que só pode ser enviado depois que o CHRE for reinicializado até o ponto em que pode aceitar novas solicitações, como queryApps().

Visão geral do sistema CHRE

O CHRE foi projetado com base em 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 de 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. Os nanoapps interagem com o framework CHRE e o sistema subjacente pela API CHRE. A API CHRE oferece um conjunto de recursos básicos e facilidades para acessar sinais contextuais, incluindo sensores, GNSS, Wi-Fi, WWAN e áudio. Ela pode ser estendida com outros recursos específicos do fornecedor para uso por nanapps específicos do fornecedor.

Sistema de build

Embora a HAL do Context Hub 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 uma cadeia de ferramentas especializada. Portanto, o projeto CHRE no AOSP oferece um sistema de build simplificado baseado 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 ao 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. Ele foi projetado para tornar o código de nanousos compatível em todos os dispositivos que oferecem suporte ao CHRE. Isso significa que o código-fonte de um nanouso não precisa ser modificado para oferecer suporte a um novo tipo de dispositivo, mas talvez seja necessário recompilar especificamente para o conjunto de instruções do processador ou a interface binária do aplicativo (ABI) do dispositivo de destino. A arquitetura do CHRE e o design da API também garantem que os nanoapps sejam compatíveis em termos binários em diferentes versões da API CHRE. Isso 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 nanapp for executado em um dispositivo compatível com a API CHRE v1.3 e esse dispositivo for atualizado para oferecer suporte à API CHRE v1.4, o mesmo binário de nanapp vai continuar funcionando. Da mesma forma, o nanoapp pode ser executado na API CHRE v1.2 e determinar em tempo de execução se ele requer recursos da API v1.3 para atingir o uso ou se pode operar, possivelmente com degradação gradual de recursos.

Novas versões da API CHRE são lançadas junto com o Android. No entanto, como a implementação do CHRE faz parte da implementação do fornecedor, a versão da API CHRE compatível com um dispositivo não está necessariamente vinculada a uma versão do Android.

Resumo da versão

Assim como o esquema de controle de versões do HIDL do Android, a API CHRE segue o controle de versões semântico. 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 um 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 meio de chreGetVersion(), que indica quando correções de bugs ou atualizações secundárias são feitas na implementação.

Versão 1.0 (Android 7)

Inclui suporte para sensores e recursos principais de nanousuários, como eventos e timers.

Versão 1.1 (Android 8)

Introduz recursos de localização por GNSS e medições brutas, verificação de Wi-Fi e informações de rede móvel, além de refinamentos gerais para ativar a comunicação entre nanoapps e outras melhorias.

Versão 1.2 (Android 9)

Adiciona suporte a dados de um microfone de baixa potência, alcance de Wi-Fi RTT, notificações de ativação e suspensão de AP e outras melhorias.

Versão 1.3 (Android 10)

Melhora os recursos relacionados a dados de calibragem do sensor, adiciona suporte para limpar dados em lote do sensor sob demanda, define o tipo de sensor de detecção de etapas e estende eventos de localização GNSS com campos de precisão adicionais.

Versão 1.4 (Android 11)

Adiciona suporte para informações de célula 5G, despejo de depuração de nanoapp e outras melhorias.

Recursos obrigatórios do sistema

Embora as fontes de indicadores contextuais, como sensores, sejam categorizadas em áreas de recursos opcionais, algumas funções principais são necessárias em todas as implementações de CHRE. Isso inclui APIs principais do sistema, como as de definição de timers, envio e recebimento de mensagens para clientes no processador de aplicativos, registro em registros e outras. Para mais detalhes, consulte os cabeçalhos da API.

Além dos recursos principais do sistema codificados na API CHRE, também há recursos obrigatórios no nível do sistema CHRE especificados no nível da HAL do Context Hub. A mais significativa delas é a capacidade de carregar e descarregar nanoapps de forma dinâmica.

Biblioteca padrão C/C++

Para minimizar o uso de memória e a complexidade do sistema, as implementações do CHRE precisam oferecer suporte apenas a um subconjunto das bibliotecas padrão de C e C++ e recursos de linguagem que exigem suporte de tempo de execução. Seguindo esses princípios, alguns recursos são explicitamente excluídos devido à memória e às extensas dependências 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 devem ser disponibilizados para nanoapps:

  • Exceções de C++ e informações de tipo em tempo de execução (RTTI)
  • Suporte a multithreading da biblioteca padrão, incluindo cabeçalhos C++11 <thread>, <mutex>, <atomic>, <future>
  • Bibliotecas de entrada/saída padrão de C e C++
  • Biblioteca de modelos padrão C++ (STL)
  • Biblioteca de expressões regulares padrão do C++
  • Alocação dinâmica de memória 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, como std::unique_ptr.
  • Suporte para 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 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 em funções da API CHRE e bibliotecas de utilitários. Por exemplo, chreLog pode ser usado para registros de depuração direcionados ao sistema logcat do Android, em que um programa mais tradicional pode usar printf ou std::cout.

Em contraste, alguns recursos da biblioteca padrão são obrigatórios. Cabe à implementação da plataforma expor esses recursos por bibliotecas estáticas para inclusão em um binário de nanapp ou por vinculação dinâmica entre o nanapp e o sistema. Isso inclui, mas não se limita a:

  • Utilitários de string e matriz: memcmp, memcpy, memmove, memset, strlen

  • Biblioteca de 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

Embora algumas plataformas subjacentes ofereçam suporte a recursos adicionais, um nanoapp não é considerado portátil em implementações do CHRE, a menos que restrinja suas dependências externas a funções da API CHRE e funções aprovadas da biblioteca padrão.

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 seja compatível com um determinado conjunto de APIs, os nanapps que fazem referência a essas funções precisam ser capazes de criar e carregar.

Sensores

A API CHRE permite solicitar dados de sensores, incluindo acelerômetro, giroscópio, magnetômetro, sensor de luz ambiente e proximidade. Essas APIs oferecem um conjunto de recursos semelhante às APIs do Android Sensors, incluindo suporte para agrupamento de amostras de sensores para reduzir o consumo de energia. O processamento de dados de sensores no CHRE permite um consumo de energia e uma latência muito menores no processamento de sinais de movimento 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 periódicas de posição e dados de medição brutos, embora ambos sejam recursos independentes. Como o CHRE tem um link direto com o subsistema GNSS, o consumo de energia é reduzido em comparação com as solicitações de GNSS baseadas em AP, porque o AP pode ficar inativo durante todo o ciclo de vida de uma sessão de localização.

Wi-Fi

O CHRE permite interagir com o chip Wi-Fi, principalmente para fins de localização. Embora o GNSS funcione bem em locais externos, os resultados das buscas por Wi-Fi podem fornecer informações de localização precisas em ambientes internos e á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 de Wi-Fi para fins de conectividade, que normalmente não são entregues ao AP por motivos de energia. O uso de 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 para Wi-Fi foi adicionado à API CHRE v1.1, incluindo a capacidade de monitorar resultados de 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 uma determinação precisa da posição relativa.

WWAN

A API CHRE permite recuperar informações de identificação da célula para a célula de serviço e as vizinhas, que geralmente 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 geralmente usa hardware para implementar o HAL SoundTrigger. O processamento de dados de áudio no CHRE permite a fusão com outros dados, como sensores de movimento.

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 nesse código para garantir a consistência e acelerar a adoção de novos recursos. Esse código pode ser visto como um análogo ao framework principal do Android, já que é uma implementação de código aberto de APIs usadas por apps, servindo como uma base e um 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. Assim como as HALs do Android, a implementação de referência do CHRE usa várias abstrações de plataforma para permitir a adaptação a qualquer dispositivo que atenda aos requisitos mínimos.

Para detalhes técnicos e um guia de portabilidade, consulte o README incluído no projeto system/chre.