Ambiente de tempo de execução do hub de contexto (CHRE)

Os smartphones contêm vários processadores, cada um otimizado para executar tarefas diferentes. No entanto, o Android só roda em um processador: o processador de aplicativos (AP). O AP é ajustado para oferecer ótimo desempenho para casos de uso de tela, como jogos, mas consome muita energia para suportar recursos que exigem rajadas frequentes e curtas de processamento o tempo todo, mesmo quando a tela está desligada. Processadores menores são capazes de lidar com essas cargas de trabalho com mais eficiência, concluindo suas tarefas sem afetar visivelmente a vida útil da bateria. No entanto, os ambientes de software nesses processadores de baixo consumo são mais limitados e podem variar muito, dificultando o desenvolvimento entre plataformas.

O Context Hub Runtime Environment (CHRE) fornece uma plataforma comum para executar aplicativos em um processador de baixo consumo de energia, com uma API simples, padronizada e amigável para incorporação. O CHRE torna mais fácil para OEMs de dispositivos e seus parceiros confiáveis ​​descarregar o processamento do AP, economizar bateria e melhorar várias áreas da experiência do usuário, e habilitar uma classe de recursos sempre ativos e contextualmente conscientes, especialmente aqueles que envolvem a aplicação da máquina aprendizagem para o sensoriamento ambiente.

Conceitos chave

CHRE é o ambiente de software onde pequenos aplicativos nativos, chamados nanoapps , são executados em um processador de baixo consumo de energia e interagem com o sistema subjacente por meio da API CHRE comum. Para acelerar a implementação adequada das APIs CHRE, uma implementação de referência de plataforma cruzada do 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 de plataforma (PALs). Os nanoapps estão quase sempre vinculados a um ou mais aplicativos clientes executados no Android, que interagem com CHRE e nanoapps por meio de APIs do sistema ContextHubManager de acesso restrito.

Em alto nível, paralelos podem ser traçados entre a arquitetura do CHRE e o Android como um todo. No entanto, existem algumas distinções importantes:

  • O CHRE suporta a execução apenas de nanoapps desenvolvidos em código nativo (C ou C++); Java não é suportado.
  • Devido a restrições de recursos e limitações de segurança, o CHRE não está aberto para uso por aplicativos Android arbitrários de terceiros. Somente aplicativos confiáveis ​​do sistema podem acessá-lo.

Há também 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 do sensor e o CHRE, o próprio CHRE não fornece a funcionalidade de sensor exigida pelo Android Sensors HAL . O CHRE está vinculado ao Context Hub HAL e atua como um cliente de uma estrutura de sensor específica do dispositivo para receber dados do sensor sem envolver o AP.

Arquitetura da estrutura CHRE

Figura 1. Arquitetura da estrutura CHRE

HAL do hub de contexto

A camada de abstração de hardware do Context Hub (HAL) é a interface entre a estrutura do Android e a implementação CHRE do dispositivo, definida em hardware/interfaces/contexthub . O Context Hub HAL define as APIs por meio das quais a estrutura do Android descobre hubs de contexto disponíveis e seus nanoapps, interage com esses nanoapps por meio da passagem de mensagens e permite que os nanoapps sejam carregados e descarregados. Uma implementação de referência do Context Hub HAL 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 HAL, a definição HAL tem precedência.

Inicialização

Quando o Android é inicializado, o ContextHubService invoca a getHubs() HAL para determinar se algum hub de contexto está disponível no dispositivo. Esta é uma chamada única de bloqueio, portanto, deve ser concluída rapidamente para evitar atrasos na inicialização e deve retornar um resultado preciso, pois novos hubs de contexto não podem ser introduzidos posteriormente.

Carregando e descarregando nanoapps

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

O Context Hub HAL também suporta o carregamento e descarregamento de nanoapps dinamicamente em tempo de execução, por meio das 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 CHRE do dispositivo.

Se a implementação para carregar um nanoapp envolve gravá-lo na memória não volátil, como armazenamento flash conectado ao processador que executa o CHRE, a implementação do CHRE deve sempre inicializar com esses nanoapps dinâmicos no estado desabilitado. Isso significa que nenhum código do nanoapp é executado até que uma solicitação enableNanoapp() seja recebida por meio do HAL. Os nanoapps pré-carregados podem inicializar no estado ativado.

O hub de contexto é reiniciado

Embora não seja esperado que o CHRE reinicie durante o curso da operação normal, pode ser necessário recuperar-se de condições inesperadas, como uma tentativa de acessar um endereço de memória não mapeado. Nessas situações, o CHRE é reiniciado independentemente do Android. O HAL notifica o Android sobre isso por meio do evento RESTARTED , que deve ser enviado somente após a reinicialização do CHRE a ponto de poder aceitar novas solicitações, como queryApps() .

Visão geral do sistema CHRE

CHRE é projetado em torno de uma arquitetura orientada a eventos, onde a unidade primária de computação é um evento passado para o ponto de entrada de manipulação de eventos de um nanoapp. Embora a estrutura CHRE possa ser multithread, um determinado nanoapp nunca é executado a partir de vários threads em paralelo. A estrutura CHRE interage com um determinado nanoapp por meio de um dos três pontos de entrada do nanoapp ( nanoappStart() , nanoappHandleEvent() e nanoappEnd() ) ou por meio de um retorno de chamada fornecido em uma chamada de API CHRE anterior, e os nanoapps interagem com a estrutura CHRE e o sistema subjacente através da API CHRE. A API CHRE fornece um conjunto de funcionalidades básicas, bem como recursos para acessar sinais contextuais, incluindo sensores, GNSS, Wi-Fi, WWAN e áudio, e pode ser estendida com recursos adicionais específicos do fornecedor para uso por nanoaplicativos específicos do fornecedor .

Construir sistema

Embora o Context Hub HAL e outros componentes necessários do lado do AP sejam criados juntamente com o Android, o código executado no CHRE pode ter requisitos que o tornam incompatível com o sistema de compilação do Android, como a necessidade de uma cadeia de ferramentas especializada. Portanto, o projeto CHRE em AOSP fornece um sistema de compilação 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 devem integrar o suporte ao sistema de compilação para seus dispositivos de destino no AOSP.

A API CHRE é gravada no padrão de linguagem C99 e a implementação de referência usa um subconjunto restrito de C++11 adequado para aplicativos com recursos limitados.

API CHRE

A API CHRE é uma coleção de arquivos de cabeçalho C que definem a interface do software entre um nanoapp e o sistema. Ele foi projetado para tornar o código de nanoapps compatível em todos os dispositivos que suportam 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 precisar ser recompilado especificamente para o processador do dispositivo de destino conjunto de instruções ou interface binária do aplicativo (ABI). A arquitetura CHRE e o design da API também garantem que os nanoapps sejam binários compatíveis 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 nanoapp 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 nanoapp continuará funcionando. Da mesma forma, o nanoapp pode ser executado na API CHRE v1.2 e pode determinar em tempo de execução se requer funcionalidade da API v1.3 para atingir sua funcionalidade ou se pode operar, potencialmente com degradação de recursos graciosa.

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

Resumo da versão

Assim como o esquema de versionamento HIDL do Android , a API CHRE segue o versionamento 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 parâmetro, por exemplo @since v1.1 .

A implementação CHRE também expõe uma versão de patch específica da plataforma por meio chreGetVersion() , que indica quando correções de bugs ou pequenas atualizações são feitas na implementação.

Versão 1.0 (Android 7)

Inclui suporte para sensores e funcionalidade principal do nanoapp, como eventos e temporizadores.

Versão 1.1 (Android 8)

Apresenta recursos de localização por meio de localização GNSS e medições brutas, varredura de Wi-Fi e informações de rede celular, juntamente com refinamentos gerais para permitir a comunicação nanoapp para nanoapp e outras melhorias.

Versão 1.2 (Android 9)

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

Versão 1.3 (Android 10)

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

Versão 1.4 (Android 11)

Adiciona suporte para informações de células 5G, dump de depuração de nanoapps e outras melhorias.

Funcionalidades obrigatórias 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 CHRE. Isso inclui APIs principais do sistema, como aquelas para definir temporizadores, enviar e receber mensagens para clientes no processador de aplicativos, registro e outros. Para obter 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 no nível do sistema CHRE especificados no nível HAL do Context Hub. O mais significativo deles é a capacidade de carregar e descarregar nanoapps dinamicamente.

Biblioteca padrão C/C++

Para minimizar o uso de memória e a complexidade do sistema, as implementações CHRE são necessárias para oferecer suporte apenas a um subconjunto das bibliotecas C e C++ padrão e recursos de linguagem que exigem suporte de tempo de execução. Seguindo esses princípios, alguns recursos são explicitamente excluídos devido à sua memória e/ou extensas dependências no nível do SO, e outros porque são suplantados por APIs específicas do CHRE mais adequadas. Embora não seja uma lista exaustiva, os recursos a seguir não devem ser disponibilizados para nanoapps:

  • Exceções C++ e informações de tipo de tempo de execução (RTTI)
  • Suporte a multithreading de 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 dinâmica de memória por meio de funções padrão (por exemplo, malloc , calloc , realloc , free , operator new ) e outras funções de biblioteca padrão que usam inerentemente alocação dinâmica, como std::unique_ptr
  • Localização e suporte a caracteres Unicode
  • Bibliotecas de data e hora
  • Funções que modificam o fluxo normal do programa, incluindo <setjmp.h> , <signal.h> , abort , std::terminate
  • Acessando 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, a funcionalidade equivalente está disponível nas funções CHRE API e/ou bibliotecas de utilitários. Por exemplo, chreLog pode ser usado para log de depuração direcionado ao sistema logcat Android, onde um programa mais tradicional pode usar printf ou std::cout .

Por outro lado, algumas funcionalidades de biblioteca padrão são necessárias. Cabe à implementação da plataforma expô-los por meio de 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/array: memcmp , memcpy , memmove , memset , strlen
  • Biblioteca matemática: funções de ponto flutuante de precisão simples comumente usadas:

    • Operações básicas: ceilf , fabsf , floorf , fmaxf , fminf , fmodf , roundf , lroundf , remainderf
    • Funções exponenciais/potência: expf , log2f , powf , sqrtf
    • Funções trigonométricas/hiperbólicas: sinf , cosf , tanf , asinf , acosf , atan2f , tanhf

Embora algumas plataformas subjacentes ofereçam suporte a funcionalidades adicionais, um nanoapp não é considerado portátil em implementações CHRE, a menos que restrinja suas dependências externas às funções da API CHRE e 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 possam não ser necessários para oferecer suporte a uma implementação CHRE compatível, eles podem ser necessários para oferecer suporte a um nanoapp específico. Mesmo que uma plataforma não dê suporte a um determinado conjunto de APIs, os nanoapps que fazem referência a essas funções devem ser capazes de construir 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 destinam-se a fornecer um conjunto de recursos 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 muito menor de energia e menor latência 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 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, bem como dados brutos de medição, 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 ao ar livre, os resultados das varreduras de Wi-Fi podem fornecer informações precisas de localização em ambientes fechados e em áreas desenvolvidas. Além de evitar o custo de despertar o AP para uma varredura, o CHRE pode ouvir os resultados das varreduras 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 para 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 Round-Trip Time (RTT) em relação a pontos de acesso que suportam o 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élula para a célula de serviço e seus vizinhos, que normalmente são usadas para fins de localização de granulação grossa.

Á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 SoundTrigger HAL. O processamento de dados de áudio no CHRE pode permitir que eles sejam fundidos com outros dados, como sensores de movimento.

Implementação de referência

O código de referência para a estrutura CHRE está incluído no AOSP no projeto system/chre , implementado em C++11. Embora não seja estritamente necessário, é recomendado que 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. Esse código pode ser visto como um análogo ao framework principal do Android, pois é uma implementação de código aberto de APIs que os aplicativos usam, servindo como linha de base e padrão para 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 às HALs do Android, a implementação de referência 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 README incluído no projeto system/chre .