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

Os smartphones têm vários processadores, todos otimizados para o desempenho tarefas diferentes. No entanto, o Android só é executado em um processador: os aplicativos (AP, na sigla em inglês). O AP foi ajustado para oferecer um ótimo desempenho para o screenon. como jogos, mas precisa de muita energia para oferecer suporte a recursos que que exigem aumentos rápidos e frequentes de processamento o tempo todo, mesmo quando a tela está desativado. Processadores menores lidam com essas cargas de trabalho com mais eficiência, para realizar tarefas sem afetar visivelmente a duração da bateria. No entanto, ambientes de software nesses processadores de baixo consumo são mais limitados variam muito, o que dificulta o desenvolvimento multiplataforma.

O ambiente de execução do hub de contexto (CHRE, na sigla em inglês) fornece uma plataforma comum para executar aplicativos em um processador de baixo consumo de energia, e fácil de usar. A CHRE facilita o trabalho dos OEMs de dispositivos e dos provedores parceiros a descarregar o processamento do AP, economizar bateria e melhorar vários áreas da experiência do usuário e permitem uma classe de recursos recursos contextuais, especialmente os que envolvem a aplicação de de machine learning para a detecção ambiente.

Principais conceitos

CHRE é o ambiente de software em que pequenos apps nativos, chamados nanoapps, são executados em um processador de baixo consumo de energia e interagem com os por meio da API CHRE comum. Para acelerar a implementação adequada do APIs CHRE, uma implementação de referência multiplataforma de CHRE está incluída no AOSP. A implementação de referência inclui código comum e abstrações para o hardware e software subjacentes por meio de uma série de camadas de abstração da plataforma (PALs). Os nanoapps estão quase sempre vinculados a um ou mais aplicativos clientes em execução no Android, que interagem com CHRE e nanoapps por meio de acesso restrito ContextHubManager APIs do sistema.

De modo geral, é possível traçar paralelos entre a arquitetura do CHRE e o Android como um todo. No entanto, existem algumas distinções importantes:

  • O CHRE permite executar apenas nanoapps desenvolvidos em código nativo (C ou C++); Não há suporte para Java.
  • 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 para acessá-lo.

Há também uma diferença importante a ser feita entre o conceito de CHRE e um hub de sensor. Embora seja comum usar o mesmo hardware para implementar a hub do sensor e CHRE, o CHRE em si não fornece os recursos do sensor exigido pelos sensores do Android HAL. A CHRE está vinculada a a HAL do hub de contexto, que atua como cliente de um sensor específico do dispositivo para receber dados do sensor 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 hub de contexto é a interface entre framework do Android e a implementação do CHRE do dispositivo, definidos em hardware/interfaces/contexthub A HAL do hub de contexto define as APIs usadas pelo framework do Android descobre hubs de contexto disponíveis e seus nanoapps, interage com esses nanoapps por meio da transmissão de mensagens, além de permitir que eles sejam carregados e descarregada. Uma implementação de referência da 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 da HAL, o A definição da HAL tem precedência.

Inicialização

Quando o Android é inicializado, ContextHubService (link em inglês) invoca a função HAL getHubs() para determinar se algum hub de contexto está disponíveis no dispositivo. Como essa é uma chamada única de bloqueio, ela precisa ser concluída para evitar atrasos na inicialização e deve retornar um resultado preciso, pois as novas hubs de contexto não podem ser introduzidos depois.

Carregar e descarregar nanoapps

Um hub de contexto pode incluir um conjunto de nanoapps incluído no dispositivo e são carregados quando o CHRE é iniciado. Eles são conhecidos como nanoapps pré-carregados, e precisa ser incluída na primeira resposta possível para queryApps().

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

Se a implementação de carregamento de um nanoapp envolver a gravação em um como o armazenamento flash conectado ao processador que executa o CHRE, A implementação CHRE deve sempre inicializar com esses nanoapps dinâmicos na desativado. Isso significa que nenhum código do nanoapp é executado até que um A solicitação enableNanoapp() é recebida pela HAL. Nanosapps pré-carregados podem inicializado no estado ativado.

Reinicializações do hub de contexto

Não se espera que o CHRE seja reiniciado durante a operação normal, mas ele pode ser necessário para se recuperar de condições inesperadas, como uma tentativa de um endereço de memória não mapeado. Nessas situações, o CHRE reinicia independente do Android. A HAL notifica o Android sobre isso pela Evento RESTARTED, que precisa ser enviado somente depois que o CHRE for reinicializado para o ponto em que ele pode aceitar novas solicitações, como queryApps().

Visão geral do sistema CHRE

O CHRE foi desenvolvido com base em uma arquitetura orientada a eventos, em que a unidade principal a computação em nuvem é um evento passado para o ponto de entrada de manipulação de eventos de um nanoapp. o framework CHRE puder ter várias linhas de execução, um determinado nanoapp nunca será executado várias linhas de execução em paralelo. O framework CHRE interage com um determinado nanoapp. usando um dos três pontos de entrada do nanoapp (nanoappStart(), nanoappHandleEvent() e nanoappEnd()) ou por um callback fornecido em um chamada anterior da API CHRE, e os nanoapps interagem com o framework do CHRE e o sistema subjacente pela API CHRE. A API CHRE fornece um conjunto de bem como recursos para acessar sinais contextuais, incluindo GNSS, Wi-Fi, WWAN e áudio, podendo ser estendida recursos específicos do fornecedor para uso por nanoapps específicos do fornecedor.

Sistema de build

Embora a 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 para torná-lo incompatíveis com o sistema de compilação do Android, como a necessidade de um conjunto de ferramentas. Portanto, o projeto CHRE no AOSP oferece um build simplificado baseado no GNU Make para compilar nanoapps e, como opção, o em bibliotecas que podem ser integradas ao sistema. Dispositivo os fabricantes que adicionam suporte a CHRE devem integrar o suporte ao sistema de build para os dispositivos de destino para o AOSP.

A API CHRE foi criada no padrão de linguagem C99, e a referência implementação usa um subconjunto restrito do C++11 adequado para recursos limitados apps.

API CHRE

A API CHRE é uma coleção de arquivos de cabeçalho C que definem o software interface entre um nanoapp e o sistema. Ele é projetado para criar nanoapps códigos compatíveis em todos os dispositivos que oferecem suporte a CHRE, o que significa que o código-fonte de um nanoapp não precisa ser modificado para oferecer suporte a um novo dispositivo tipo, embora possa precisar ser recompilado especificamente para o sistema conjunto de instruções do processador ou interface binária de aplicativo (ABI). O CHRE a arquitetura e o design de APIs 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 a API CHRE em comparação com a API de destino para a compilação do nanoapp. Em outras palavras, se um binário nanoapp for executado em um dispositivo com suporte à API CHRE v1.3, e o dispositivo é atualizado para oferecer suporte à API CHRE v1.4, o mesmo nanoapp e o binário continua funcionando. Da mesma forma, o nanoapp pode ser executado na API CHRE v1.2, e pode determinar no ambiente de execução se são necessários recursos da API v1.3 alcançar o uso dela ou se pode operar, potencialmente com degradação de atributos.

Novas versões da API CHRE são lançadas junto com o Android, mas como a API CHRE implementação faz parte implementação do fornecedor, a versão da API CHRE aceita em um dispositivo não está necessariamente vinculada a uma Versão do Android.

Resumo da versão

Como o Esquema de controle de versão 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 indica 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 meio de chreGetVersion(), que indica quando correções de bugs ou atualizações menores são feitas no a implementação.

Versão 1.0 (Android 7)

Inclui suporte a sensores e recursos essenciais do nanoapp, como eventos e timers.

Versão 1.1 (Android 8)

Introduz recursos de localização por meio de medições brutas e de localização do GNSS, busca por Wi-Fi e informações sobre a rede móvel, além de refinamentos gerais. para permitir a comunicação entre nanoapp e nanoapp e outras melhorias.

Versão 1.2 (Android 9)

Adiciona suporte a dados de microfone de baixo consumo, alcance Wi-Fi RTT, AP notificações de despertar e sono e outras melhorias.

Versão 1.3 (Android 10)

Aprimora os recursos relacionados aos dados de calibração do sensor e adiciona suporte a transferir dados do sensor em lote sob demanda, definir o tipo de sensor de detecção de etapas e estende os eventos de localização do GNSS com campos de precisão adicionais.

Versão 1.4 (Android 11)

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

Recursos obrigatórios do sistema

As origens de indicadores de contexto, como sensores, são categorizadas como áreas de recurso, algumas funções principais são necessárias em todos os CHREs e implementações. Isso inclui as principais APIs do sistema, como as de configuração timers, enviar e receber mensagens de clientes no processador dos aplicativos, geração de registros e outros. Para mais detalhes, consulte a Cabeçalhos da API.

Além dos principais recursos de sistema codificados na API CHRE, há também recursos obrigatórios no nível do sistema CHRE especificados no nível da HAL do hub de contexto. A o mais significativo deles é a capacidade de carregar e descarregar dinamicamente nanosapps.

Biblioteca C/C++ padrão

Para minimizar o uso de memória e a complexidade do sistema, as implementações CHRE são necessário para oferecer suporte a apenas um subconjunto das bibliotecas C e C++ padrão e recursos de linguagem grandes que exigem suporte de tempo de execução. Seguindo esses princípios, algumas recursos são explicitamente excluídos devido à memória e à amplitude do sistema operacional dependências e outras porque foram substituídas por APIs específicas de CHRE. Embora essa não seja uma lista completa, os itens a seguir que não devem ser disponibilizados para nanoapps:

  • Exceções de C++ e informações sobre o tipo de ambiente de execução (RTTI)
  • Suporte a multissegmentação da biblioteca padrão, incluindo cabeçalhos C++11 <thread>, <mutex>, <atomic> e <future>
  • Bibliotecas de entrada/saída padrão em C e C++
  • Biblioteca C++ padrão de modelos (STL, na sigla em inglês)
  • Biblioteca C++ padrão de expressões regulares
  • Alocação dinâmica de memória usando funções padrão (por exemplo, malloc, calloc, realloc, free, operator new) e outro padrão funções de biblioteca que usam inerentemente a alocação dinâmica, como std::unique_ptr
  • Compatibilidade com 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 e std::terminate
  • Como acessar o ambiente do host, incluindo system, getenv
  • POSIX e outras bibliotecas não incluídas na linguagem C99 ou C++11 padrões

Em muitos casos, recursos equivalentes estão disponíveis nas funções da API CHRE e bibliotecas de utilitários. Por exemplo, chreLog pode ser usado para depurar a geração de registros direcionados para o sistema logcat do Android, no qual um programa mais tradicional poderia use printf ou std::cout.

Por outro lado, alguns recursos padrão da biblioteca são necessários. Cabe ao implementação de plataforma para expor usando bibliotecas estáticas para inclusão em um binário nanoapp ou por vínculo dinâmico entre o nanoapp e o sistema. Isso inclui, sem limitação:

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

  • Biblioteca Math: funções de ponto flutuante de precisão única usadas frequentemente:

    • Operações básicas: ceilf, fabsf, floorf, fmaxf, fminf, fmodf, roundf, lroundf e 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

Enquanto algumas plataformas subjacentes suportam recursos adicionais, um nanoapp não é considerado portátil entre implementações CHRE, a menos que restrinja seu dependências externas para funções da API CHRE e biblioteca padrão aprovada .

Recursos opcionais

Para promover o hardware e o software, a API CHRE é dividida em áreas de recursos, que são considerados opcionais do ponto de vista da API. Embora esses recursos podem não ser obrigados a oferecer suporte a uma implementação de CHRE compatível, eles podem ser necessárias para a compatibilidade com um nanoapp específico. Mesmo que uma plataforma não ofereça suporte a uma determinado conjunto de APIs, os nanoaplicativos que fazem referência a essas funções devem ser capazes de criar e carregar.

Sensores

A API CHRE fornece a capacidade de solicitar dados de sensores, incluindo acelerômetro, giroscópio, magnetômetro, sensor de luz ambiente e proximidade. Essas APIs fornecem um conjunto de recursos semelhante ao dos sensores do Android APIs, incluindo suporte para agrupar amostras de sensores para reduzir o consumo de energia. O processamento de dados do sensor no CHRE permite muito menos energia e latência menor. processamento de sinais de movimento em comparação com a execução no AP.

GNSS

A CHRE fornece APIs para solicitar dados de localização de uma navegação global sistema de satélite (GNSS, na sigla em inglês), incluindo GPS e outras constelações de satélites. Isso inclui solicitações de correções periódicas de posição, bem como dados brutos de medição, embora ambos sejam capacidades independentes. Como o CHRE tem um link direto para o GNSS no subsistema, a energia é reduzida em comparação com solicitações GNSS baseadas em AP, porque o AP pode permanecer dormindo durante todo o ciclo de vida de uma sessão de localização.

Wi-Fi

O CHRE permite interagir com o chip de Wi-Fi, principalmente para para fins de localização. Embora o GNSS funcione bem para locais ao ar livre, os resultados do As verificações de Wi-Fi fornecem informações de localização precisas em ambientes fechados e áreas Além de evitar o custo de ativar o AP para uma verificação, o CHRE pode ouvir os resultados das buscas por Wi-Fi realizadas pelo firmware para fins de conectividade, que normalmente não são entregues ao AP por motivos de poder. Usar as verificações de conectividade para fins contextuais ajuda para reduzir o número total de buscas por Wi-Fi realizadas, economizando energia.

Foi adicionado suporte a Wi-Fi na API CHRE v1.1, incluindo a capacidade de monitorar os resultados das verificações e acionar verificações sob demanda. Esses recursos foram estendidos para v1.2, com a capacidade de realizar Tempo de retorno (RTT) medições em relação aos pontos de acesso que dão suporte ao recurso, o que permite a determinação precisa da posição relativa.

WWAN

A API CHRE fornece a capacidade de recuperar informações de identificação de células para a célula de serviço e suas vizinhas, que é normalmente usada para para fins de localização de alta granularidade.

Áudio

O CHRE pode processar lotes de dados de áudio de um microfone de baixo consumo, normalmente aproveita o hardware usado para implementar a HAL SoundTrigger. Processando os dados de áudio no CHRE podem permitir a fusão com outros dados, como movimento ou sensores.

Implementação de referência

O código de referência do framework CHRE está incluído no AOSP no system/chre implementado em C++11. Embora não seja estritamente obrigatório, é recomendado para todas as implementações CHRE sejam baseadas nessa base de código, para ajudar a garantir consistência e acelerar a adoção de novos recursos. Este código pode ser visto como um análogo ao framework principal do Android, por se tratar de um implementação de APIs usadas por apps, servindo como referência e padrão para compatibilidade. Embora possa ser personalizado e estendido com opções específicas de fornecedor, recursos, a recomendação é manter o código comum o mais próximo sempre que possível. Semelhante às HALs do Android, a referência CHRE usa várias abstrações da plataforma para permitir que ela seja adaptada para qualquer dispositivo que atenda aos requisitos mínimos.

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