A figura abaixo representa a pilha de sensores do Android. Cada componente se comunica apenas com os componentes diretamente acima e abaixo dele, embora alguns sensores possam contornar o hub do sensor quando ele estiver presente. Controle os fluxos dos aplicativos para os sensores e os fluxos de dados dos sensores para os aplicativos.
Figura 1. Camadas da pilha de sensores do Android e seus respectivos proprietários
SDK
Os aplicativos acessam os sensores por meio da API Sensors SDK (Software Development Kit) . O SDK contém funções para listar os sensores disponíveis e registrar um sensor.
Ao se registrar em um sensor, o aplicativo especifica sua frequência de amostragem preferida e seus requisitos de latência.
- Por exemplo, um aplicativo pode se registrar no acelerômetro padrão, solicitando eventos em 100Hz e permitindo que os eventos sejam relatados com uma latência de 1 segundo.
- O aplicativo receberá eventos do acelerômetro a uma taxa de pelo menos 100Hz e possivelmente com atraso de até 1 segundo.
Consulte a documentação do desenvolvedor para obter mais informações sobre o SDK.
Estrutura
O framework é responsável por vincular as diversas aplicações ao HAL . O próprio HAL é de cliente único. Sem essa multiplexação acontecendo no nível da estrutura, apenas um único aplicativo poderia acessar cada sensor a qualquer momento.
- Quando um primeiro aplicativo se registra em um sensor, a estrutura envia uma solicitação ao HAL para ativar o sensor.
- Quando aplicativos adicionais se registram no mesmo sensor, a estrutura leva em consideração os requisitos de cada aplicativo e envia os parâmetros solicitados atualizados para o HAL.
- A frequência de amostragem será a máxima das frequências de amostragem solicitadas, ou seja, alguns aplicativos receberão eventos com frequência superior à que solicitaram.
- A latência máxima de relatórios será a mínima das solicitadas. Se um aplicativo solicitar um sensor com latência máxima de relatório de 0, todos os aplicativos receberão os eventos desse sensor em modo contínuo, mesmo que alguns solicitem o sensor com latência máxima de relatório diferente de zero. Consulte Lotes para obter mais detalhes.
- Quando o último aplicativo registrado em um sensor cancela o registro dele, os frameworks enviam uma solicitação ao HAL para desativar o sensor para que a energia não seja consumida desnecessariamente.
Impacto da multiplexação
Essa necessidade de uma camada de multiplexação na estrutura explica algumas decisões de projeto.
- Quando um aplicativo solicita uma frequência de amostragem específica, não há garantia de que os eventos não chegarão a uma taxa mais rápida. Se outro aplicativo solicitar o mesmo sensor em uma taxa mais rápida, o primeiro aplicativo também os receberá em uma taxa mais rápida.
- A mesma falta de garantia se aplica à latência máxima de relatórios solicitada: os aplicativos podem receber eventos com muito menos latência do que solicitaram.
- Além da frequência de amostragem e latência máxima de relatórios, os aplicativos não podem configurar os parâmetros do sensor.
- Por exemplo, imagine um sensor físico que pode funcionar nos modos “alta precisão” e “baixo consumo”.
- Apenas um desses dois modos pode ser usado em um dispositivo Android, caso contrário, um aplicativo pode solicitar o modo de alta precisão e outro o modo de baixo consumo; não haveria como o framework satisfazer ambas as aplicações. O framework deve sempre ser capaz de satisfazer todos os seus clientes, então isso não é uma opção.
- Não há nenhum mecanismo para enviar dados dos aplicativos para os sensores ou seus drivers. Isso garante que um aplicativo não possa modificar o comportamento dos sensores, interrompendo outros aplicativos.
Fusão do sensor
A estrutura do Android fornece uma implementação padrão para alguns sensores compostos. Quando um giroscópio , um acelerômetro e um magnetômetro estão presentes em um dispositivo, mas não há sensores de vetor de rotação , gravidade e aceleração linear , a estrutura implementa esses sensores para que os aplicativos ainda possam usá-los.
A implementação padrão não tem acesso a todos os dados aos quais outras implementações têm acesso e deve ser executada no SoC, portanto, não é tão precisa nem tão eficiente quanto outras implementações. Tanto quanto possível, os fabricantes de dispositivos devem definir seus próprios sensores fundidos (vetor de rotação, gravidade e aceleração linear, bem como sensores compostos mais recentes, como o vetor de rotação do jogo ) em vez de depender dessa implementação padrão. Os fabricantes de dispositivos também podem solicitar aos fornecedores de chips de sensores que forneçam uma implementação.
A implementação de fusão de sensores padrão não está sendo mantida e pode fazer com que os dispositivos que dependem dela falhem no CTS.
Sob o capô
Esta seção é fornecida como informações básicas para aqueles que mantêm o código da estrutura do Android Open Source Project (AOSP). Não é relevante para fabricantes de hardware.
JNI
O framework usa uma Java Native Interface (JNI) associada ao android.hardware e localizada no diretório frameworks/base/core/jni/ . Este código chama o código nativo de nível inferior para obter acesso ao hardware do sensor.
Estrutura nativa
O framework nativo é definido em frameworks/native/ e fornece um equivalente nativo ao pacote android.hardware . A estrutura nativa chama os proxies IPC do Binder para obter acesso a serviços específicos do sensor.
Aglutinante IPC
Os proxies Binder IPC facilitam a comunicação sobre os limites do processo.
HAL
A API Sensors Hardware Abstraction Layer (HAL) é a interface entre os drivers de hardware e a estrutura do Android. Ele consiste em uma interface HAL sensores.he uma implementação HAL que chamamos de sensores.cpp.
A interface é definida por contribuidores do Android e AOSP, e a implementação é fornecida pelo fabricante do dispositivo.
A interface HAL do sensor está localizada em hardware/libhardware/include/hardware . Consulte sensores.h para obter detalhes adicionais.
Ciclo de lançamento
A implementação HAL especifica qual versão da interface HAL ela implementa definindo your_poll_device.common.version . As versões de interface HAL existentes são definidas em sensores.h, e a funcionalidade está vinculada a essas versões.
A estrutura do Android atualmente oferece suporte às versões 1.0 e 1.3, mas a 1.0 em breve não será mais compatível. Esta documentação descreve o comportamento da versão 1.3, para a qual todos os dispositivos devem atualizar. Para obter detalhes sobre como atualizar para 1.3, consulte Descontinuação da versão HAL .
Driver do kernel
Os drivers do sensor interagem com os dispositivos físicos. Em alguns casos, a implementação HAL e os drivers são a mesma entidade de software. Em outros casos, o integrador de hardware solicita que os fabricantes do chip sensor forneçam os drivers, mas são eles que escrevem a implementação HAL.
Em todos os casos, a implementação de HAL e os drivers do kernel são de responsabilidade dos fabricantes de hardware, e o Android não fornece abordagens preferenciais para escrevê-los.
Hub do sensor
A pilha de sensores de um dispositivo pode opcionalmente incluir um hub de sensores, útil para realizar alguns cálculos de baixo nível com baixa potência enquanto o SoC pode estar em modo de suspensão. Por exemplo, contagem de passos ou fusão de sensores pode ser realizada nesses chips. Também é um bom lugar para implementar lotes de sensores, adicionando FIFOs de hardware para os eventos do sensor. Consulte Lotes para obter mais informações.
Observação: para desenvolver novos recursos do ContextHub que usam novos sensores ou LEDs, você também pode usar um Neonkey SensorHub conectado a uma placa de desenvolvimento Hikey ou Hikey960.
Como o hub do sensor é materializado depende da arquitetura. Às vezes, é um chip separado e, às vezes, incluído no mesmo chip que o SoC. Características importantes do hub do sensor é que ele deve conter memória suficiente para lotes e consumir muito pouca energia para permitir a implementação dos sensores Android de baixa potência. Alguns hubs de sensores contêm um microcontrolador para computação genérica e aceleradores de hardware para permitir computação de energia muito baixa para sensores de baixa potência.
Como o hub do sensor é arquitetado e como ele se comunica com os sensores e o SoC (barramento I2C, barramento SPI, …) não é especificado pelo Android, mas deve visar minimizar o uso geral de energia.
Uma opção que parece ter um impacto significativo na simplicidade da implementação é ter duas linhas de interrupção indo do hub do sensor para o SoC: uma para interrupções de ativação (para sensores de ativação) e outra para interrupções sem ativação (para sensores que não despertam).
Sensores
Esses são os chips MEMs físicos que fazem as medições. Em muitos casos, vários sensores físicos estão presentes no mesmo chip. Por exemplo, alguns chips incluem um acelerômetro, um giroscópio e um magnetômetro. (Tais chips são frequentemente chamados de chips de 9 eixos, pois cada sensor fornece dados em 3 eixos.)
Alguns desses chips também contêm alguma lógica para realizar cálculos usuais, como detecção de movimento, detecção de passos e fusão de sensores de 9 eixos.
Embora os requisitos e recomendações de potência e precisão do CDD sejam direcionados ao sensor Android e não aos sensores físicos, esses requisitos afetam a escolha dos sensores físicos. Por exemplo, o requisito de precisão no vetor de rotação do jogo tem implicações na precisão necessária para o giroscópio físico. Cabe ao fabricante do dispositivo derivar os requisitos para sensores físicos.