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 os sensores pela API do SDK (kit de desenvolvimento de software) de sensores. O SDK contém funções para listar os 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 os eventos 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
O framework é responsável por vincular os vários aplicativos ao HAL. O HAL é um cliente único. Sem essa multiplexação no nível do framework, apenas um único aplicativo poderia acessar cada sensor a qualquer momento.
- Quando um primeiro aplicativo se registra em um sensor, o framework envia uma solicitação para o HAL para ativar o sensor.
- Quando outros aplicativos são registrados no mesmo sensor, o framework considera
os requisitos de cada aplicativo e envia os parâmetros atualizados
para o HAL.
- A frequência de amostragem será o máximo das frequências de amostragem solicitadas. Isso significa que alguns aplicativos vão receber eventos com uma frequência maior do que a solicitada.
- A latência máxima de relatórios será a menor das solicitadas. Se um app solicitar um sensor com uma latência máxima de relatório de 0, todos os apps 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 Como fazer o agrupamento para mais detalhes.
- Quando o último aplicativo registrado em um sensor é removido, os frameworks enviam uma solicitação para 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 chegam 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 recebê-los 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 foi solicitado.
- Além da frequência de amostragem e da latência máxima de relatórios, os aplicativos não podem
configurar parâmetros do sensor.
- Por exemplo, imagine um sensor físico que possa funcionar nos modos de "alta precisão" e "baixo consumo de energia".
- Apenas um desses dois modos pode ser usado em um dispositivo Android, porque, caso contrário, um app poderia solicitar o modo de alta precisão e outro um modo de baixo consumo de energia. Não haveria como o framework atender aos dois apps. O framework precisa sempre atender a todos os clientes, então isso não é uma opção.
- Não há um 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
O framework do Android oferece uma implementação padrão para alguns sensores compostos. Quando um giroscópio, um sensor de aceleração e um magnetômetro estão presentes em um dispositivo, mas nenhum sensor de vetor de rotação, gravidade e aceleração linear está presente, 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 a que outras implementações têm acesso e precisa ser executada no SoC. Portanto, ela não é tão precisa nem tão eficiente em termos de energia quanto outras implementações. Os fabricantes de dispositivos devem definir os próprios sensores combinados (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 que os fornecedores de chips de sensores 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.
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 interface nativa do Java (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 inferior 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 IPC do Binder para ter acesso a
serviços específicos do sensor.
IPC de vinculação
Os proxies IPC do Binder facilitam a comunicação entre limites de processo.
HAL
A API Sensors Hardware Abstraction Layer (HAL) é a interface entre os drivers de hardware e o framework do Android. Ele consiste em uma interface HAL sensors.h e uma implementação HAL que chamamos de sensors.cpp.
A interface é definida pelos 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 do HAL especifica qual versão da interface HAL ela
implementa definindo your_poll_device.common.version. As versões da interface
HAL atuais são definidas em sensors.h, e a funcionalidade está vinculada a essas
versões.
No momento, o framework do Android oferece suporte às versões 1.0 e 1.3, mas a 1.0 vai deixar de ser compatível em breve. Esta documentação descreve o comportamento da versão 1.3, para a qual todos os dispositivos precisam fazer upgrade. Para saber como fazer upgrade para a 1.3, consulte Descontinuação da versão HAL.
Driver do kernel
Os drivers de sensores interagem com os dispositivos físicos. Em alguns casos, a implementação do HAL e os drivers são a mesma entidade de software. Em outros casos, o integrador de hardware solicita que os fabricantes de chips de sensores forneçam os drivers, mas são eles que escrevem a implementação do HAL.
Em todos os casos, a implementação do HAL e os drivers do kernel são de responsabilidade dos fabricantes de hardware, e o Android não oferece abordagens preferidas para gravá-los.
Hub de sensores
A pilha de sensores de um dispositivo pode incluir um hub de sensores, útil para realizar algumas computações de baixo nível com pouca energia enquanto o SoC pode estar em modo de suspensão. Por exemplo, a contagem de passos ou a fusão de sensores pode ser realizada nesses chips. Ele também é um bom lugar para implementar o agrupamento de sensores, adicionando FIFOs de hardware para os eventos do sensor. Consulte Processamento em lote para mais informações.
Observação:para desenvolver novos recursos do ContextHub que usem 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. As características importantes do hub de sensores é que ele precisa ter memória suficiente para agrupamento 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 muito baixa potência para sensores de baixa potência.
A arquitetura do hub de sensores e a forma como ele se comunica com os sensores e o SoC (barramento I2C, barramento SPI etc.) não são especificadas pelo Android, mas o 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 que vão 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 que não são de ativação).
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 geralmente são chamados de chips de 9 eixos, já que cada sensor fornece dados em três eixos.
Alguns desses chips também contêm uma 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 energia e precisão do CDD sejam direcionados ao sensor do Android e não aos sensores físicos, esses requisitos afetam a escolha de 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 extrair os requisitos para sensores físicos.