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 ignorar o hub de sensores quando ele está presente. O controle flui dos aplicativos para os sensores, e os dados fluem dos sensores para os aplicativos.
Figura 1. Camadas da pilha de sensores do Android e os respectivos proprietários
SDK
Os aplicativos acessam sensores pela API do SDK (kit de desenvolvimento de software) de sensores. O SDK contém funções para listar sensores disponíveis e se registrar em um sensor.
Ao se registrar em um sensor, o aplicativo especifica a frequência de amostragem preferida e os requisitos de latência.
- Por exemplo, um aplicativo pode se registrar no acelerômetro padrão, solicitando eventos a 100 Hz e permitindo que eles sejam informados com uma latência de 1 segundo.
- O aplicativo vai receber eventos do acelerômetro a uma taxa de pelo menos 100 Hz, e possivelmente com um atraso de até 1 segundo.
Consulte a documentação para desenvolvedores para mais informações sobre o SDK.
Framework
A estrutura é responsável por vincular os vários aplicativos à HAL. A HAL em si é de cliente único. Sem essa multiplexação no nível do framework, apenas um aplicativo poderia acessar cada sensor a qualquer momento.
- Quando um primeiro aplicativo se registra em um sensor, o framework envia uma solicitação à HAL para ativar o sensor.
- Quando outros apps se registram no mesmo sensor, o framework considera os requisitos de cada um e envia os parâmetros atualizados solicitados para a HAL.
- A frequência de amostragem será o máximo das frequências solicitadas. Isso significa que alguns aplicativos vão receber eventos em uma frequência maior do que a solicitada.
- A latência máxima de geração de relatórios será o mínimo das latências solicitadas. Se um aplicativo solicitar um sensor com uma latência máxima de relatório de 0, todos os aplicativos vão receber os eventos desse sensor no modo contínuo, mesmo que alguns tenham solicitado o sensor com uma latência máxima de relatório diferente de zero. Consulte Lotes para mais detalhes.
- Quando o último aplicativo registrado em um sensor é cancelado, os frameworks enviam uma solicitação à 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 no framework explica algumas decisões de design.
- Quando um aplicativo solicita uma frequência de amostragem específica, não há garantia de que os eventos não vão chegar em uma taxa mais rápida. Se outro aplicativo solicitar o mesmo sensor com uma taxa mais rápida, o primeiro aplicativo também vai receber os dados nessa taxa.
- 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 o solicitado.
- Além da frequência de amostragem e da latência máxima de geração de relatórios, os aplicativos não podem configurar parâmetros de sensor.
- Por exemplo, imagine um sensor físico que pode funcionar nos modos "alta precisão" e "baixo consumo de energia".
- Apenas um desses dois modos pode ser usado em um dispositivo Android. Caso contrário, um aplicativo poderia solicitar o modo de alta precisão e outro, o modo de baixo consumo de energia. Não haveria como o framework atender aos dois aplicativos. O framework precisa sempre atender a todos os clientes, então essa não é uma opção.
- Não há um mecanismo para enviar dados dos aplicativos para os sensores ou os drivers deles. Isso garante que um aplicativo não possa modificar o comportamento dos sensores, prejudicando outros aplicativos.
Fusão de sensores
O framework do Android oferece 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, o framework implementa esses sensores para que os aplicativos ainda possam usá-los.
A implementação padrão não tem acesso a todos os dados que outras implementações têm, e ela precisa ser executada no SoC. Portanto, não é tão precisa nem eficiente em termos de energia quanto outras implementações. Sempre que possível, os fabricantes de dispositivos precisam definir os próprios sensores combinados (vetor de rotação, gravidade e aceleração linear, além de sensores compostos mais recentes, como o vetor de rotação de jogos) em vez de depender dessa implementação padrão. Os fabricantes de dispositivos também podem pedir aos fornecedores de chips de sensor que ofereçam uma implementação.
A implementação padrão da fusão de sensores não está sendo mantida e pode fazer com que os dispositivos que dependem dela falhem no CTS.
Configurações avançadas
Esta seção é fornecida como informações básicas para quem mantém o código do framework do Android Open Source Project (AOSP). Ele não é relevante para fabricantes de hardware.
JNI
O framework usa uma Java Native Interface (JNI) associada a android.hardware e localizada no diretório frameworks/base/core/jni/. Esse código chama o
código nativo de nível mais baixo para ter acesso ao hardware do sensor.
Framework nativo
O framework nativo é definido em frameworks/native/ e fornece um equivalente nativo ao pacote android.hardware. O framework nativo chama os proxies do Binder IPC para acessar
serviços específicos do sensor.
IPC do Binder
Os proxies do Binder IPC facilitam a comunicação entre limites de processos.
HAL
A API Sensors Hardware Abstraction Layer (HAL) é a interface entre os drivers de hardware e a estrutura do Android. Ela consiste em uma interface HAL sensors.h e uma implementação HAL chamada sensors.cpp.
A interface é definida por colaboradores do Android e do AOSP, e a implementação é fornecida pelo fabricante do dispositivo.
A interface HAL do sensor está localizada em hardware/libhardware/include/hardware.
Consulte sensors.h para mais detalhes.
Ciclo de lançamento
A implementação da HAL especifica qual versão da interface HAL ela
implementa definindo your_poll_device.common.version. As versões da interface HAL
são definidas em sensors.h, e a funcionalidade está vinculada a essas
versões.
No momento, o framework do Android é compatível com as versões 1.0 e 1.3, mas a 1.0 não terá mais suporte em breve. Esta documentação descreve o comportamento da versão 1.3, para a qual todos os dispositivos precisam fazer upgrade. Para detalhes sobre como fazer upgrade para 1.3, consulte Descontinuação da versão do HAL.
Driver do kernel
Os drivers de sensor interagem com os dispositivos físicos. Em alguns casos, a implementação da HAL e os drivers são a mesma entidade de software. Em outros casos, o integrador de hardware pede aos fabricantes de chips de sensor que forneçam os drivers, mas eles são os responsáveis por escrever a implementação da HAL.
Em todos os casos, a implementação da HAL e os drivers do kernel são de responsabilidade dos fabricantes de hardware, e o Android não oferece abordagens preferenciais para escrevê-los.
Hub de sensor
A pilha de sensores de um dispositivo pode incluir um hub de sensores, útil para realizar algumas computações de baixo nível com baixo consumo de energia enquanto o SoC pode estar em um modo de suspensão. Por exemplo, a contagem de passos ou a fusão de sensores podem ser realizadas nesses chips. Também é um bom lugar para implementar o agrupamento de sensores, adicionando FIFOs de hardware para os eventos do sensor. Consulte Lotes para 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.
A forma como o hub de sensores é materializado depende da arquitetura. Às vezes, ele é um chip separado e, às vezes, incluído no mesmo chip do SoC. Uma característica importante do hub de sensores é que ele precisa ter memória suficiente para o agrupamento em lotes e consumir pouca energia para permitir a implementação dos sensores Android de baixa energia. Alguns hubs de sensores contêm um microcontrolador para computação genérica e aceleradores de hardware para permitir computação de baixíssima potência para sensores de baixa potência.
A arquitetura do hub de sensores e como ele se comunica com os sensores e o SoC (barramento I2C, barramento SPI etc.) não são especificados pelo Android, mas devem visar a minimização do 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 despertar (para sensores de despertar) e outra para interrupções que não são de despertar (para sensores que não são de despertar).
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. Esses chips são geralmente chamados de chips de 9 eixos, já que cada sensor fornece dados em três eixos.
Alguns desses chips também contêm lógica para realizar cálculos comuns, como detecção de movimento e de passos e fusão de sensores de nove eixos.
Embora os requisitos e as recomendações de energia e precisão do CDD sejam destinados ao sensor do Android e não aos sensores físicos, eles 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.