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 do sensor quando ele estiver presente. O controle flui dos aplicativos até os sensores e os dados fluem dos sensores até os aplicativos.
Figura 1. Camadas da pilha de sensores do Android e seus respectivos proprietários
SDK
Os aplicativos acessam sensores por meio da API Sensors SDK (Software Development Kit) . O SDK contém funções para listar os sensores disponíveis e registrar-se em um sensor.
Ao registrar-se em um sensor, o aplicativo especifica sua frequência de amostragem preferida e seus requisitos de latência.
- Por exemplo, um aplicativo pode registrar-se no acelerômetro padrão, solicitando eventos a 100 Hz e permitindo que os eventos sejam relatados com latência de 1 segundo.
- O aplicativo receberá eventos do acelerômetro a uma taxa de pelo menos 100 Hz 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 que essa multiplexação acontecesse no nível da estrutura, apenas um único aplicativo poderia acessar cada sensor a qualquer momento.
- Quando um primeiro aplicativo é registrado em um sensor, a estrutura envia uma solicitação ao HAL para ativar o sensor.
- Quando aplicações adicionais são registradas no mesmo sensor, a estrutura leva em consideração os requisitos de cada aplicação 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, o que significa que algumas aplicações receberão eventos com uma frequência superior à solicitada.
- A latência máxima do relatório será a mínima das solicitadas. Se um aplicativo solicitar um sensor com latência máxima de relatório 0, todos os aplicativos receberão os eventos desse sensor em modo contínuo, mesmo que alguns tenham solicitado o sensor com latência máxima de relatório diferente de zero. Consulte Lote para obter mais detalhes.
- Quando o último aplicativo registrado em um sensor cancela o registro dele, o framework envia uma solicitação ao HAL para desativar o sensor para que a energia não seja consumida desnecessariamente.
Impacto da multiplexação
Esta necessidade de uma camada de multiplexação na estrutura 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 chegarão a uma taxa mais rápida. Se outro aplicativo solicitou o mesmo sensor mais rapidamente, o primeiro aplicativo também os receberá mais rapidamente.
- A mesma falta de garantia se aplica à latência máxima de relatório solicitada: os aplicativos podem receber eventos com muito menos latência do que solicitaram.
- Além da frequência de amostragem e da latência máxima de relatório, os aplicativos não podem configurar os parâmetros do sensor.
- Por exemplo, imagine um sensor físico que pode funcionar tanto nos modos de “alta precisão” quanto de “baixo consumo de energia”.
- Apenas um desses dois modos pode ser usado em um dispositivo Android, caso contrário, um aplicativo poderá solicitar o modo de alta precisão e outro, o modo de baixo consumo de energia; não haveria como a estrutura satisfazer ambas as aplicações. O framework deve sempre ser capaz de satisfazer todos os seus clientes, portanto esta não é uma opção.
- Não há 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 de sensores
A estrutura 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 nenhum vetor de rotação , gravidade e sensores de aceleração linear estão presentes, 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 em termos de energia quanto outras implementações podem ser. 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 confiar nesta implementação padrão. Os fabricantes de dispositivos também podem solicitar aos fornecedores de chips sensores que lhes forneçam uma implementação.
A implementação padrão de fusão de sensores 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
A estrutura usa uma Java Native Interface (JNI) associada a 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
A estrutura nativa é definida em frameworks/native/ e fornece um equivalente nativo ao pacote android.hardware . A estrutura nativa chama os proxies Binder IPC para obter acesso a serviços específicos do sensor.
Fichário IPC
Os proxies Binder IPC facilitam a comunicação além dos limites do processo.
HAL
A API Sensors Hardware Abstraction Layer (HAL) é a interface entre os drivers de hardware e a estrutura Android. Ele consiste em uma interface HALsens.h e uma implementação HAL que chamamos desensores.cpp.
A interface é definida pelos colaboradores 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 existentes da interface HAL são definidas em sensores.h e a funcionalidade está vinculada a essas versões.
A estrutura do Android atualmente suporta as versões 1.0 e 1.3, mas a 1.0 em breve não será mais suportada. Esta documentação descreve o comportamento da versão 1.3, para a qual todos os dispositivos devem ser atualizados. Para obter detalhes sobre como atualizar para 1.3, consulte Suspensão de uso 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 aos fabricantes de chips sensores que forneçam os drivers, mas são eles que escrevem a implementação HAL.
Em todos os casos, a implementação 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.
Cubo do sensor
A pilha de sensores de um dispositivo pode incluir opcionalmente um hub de sensor, ú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, a contagem de passos ou a fusão de sensores podem ser realizadas nesses chips. Também é um bom lugar para implementar lotes de sensores, adicionando FIFOs de hardware para os eventos do sensor. Consulte Lote para obter mais informações.
Nota: 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 do sensor é materializado depende da arquitetura. Às vezes é um chip separado e às vezes incluído no mesmo chip do SoC. Características importantes do hub do sensor é que ele deve conter memória suficiente para processamento em lote e consumir muito pouca energia para permitir a implementação dos sensores Android de baixo consumo de energia. Alguns hubs de sensores contêm um microcontrolador para computação genérica e aceleradores de hardware para permitir computação de potência muito baixa para sensores de baixa potência.
A forma 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 ter como objetivo 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 que não são de ativação. (para sensores sem 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 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 visem o sensor Android e não os 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 determinar os requisitos para sensores físicos.