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 estiver presente. O fluxo de controle vai dos aplicativos para os sensores, e o fluxo de dados vai 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 os sensores disponíveis e registrar um sensor.
Ao registrar 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 atrasados em até 1 segundo.
Consulte a documentação do desenvolvedor para mais informações sobre o SDK.
Framework
O framework é responsável por vincular os vários aplicativos à HAL. A HAL é 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 para a HAL ativar o sensor.
- Quando outros aplicativos se registram no mesmo sensor, o framework leva
em consideração os requisitos de cada aplicativo e envia os parâmetros solicitados atualizados
para a HAL.
- A frequência de amostragem será o máximo das frequências de amostragem solicitadas, o que significa que alguns aplicativos vão receber eventos em uma frequência maior do que a solicitada.
- A latência máxima de relatório será o mínimo das 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 Lote para mais detalhes.
- Quando o último aplicativo registrado em um sensor cancela o registro, o framework envia uma solicitação para a HAL 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 a uma taxa mais rápida. Se outro aplicativo solicitar o mesmo sensor a uma taxa mais rápida, o primeiro aplicativo também vai recebê-los na taxa rápida.
- 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 o solicitado.
- Além da frequência de amostragem e da latência máxima de relatório, os aplicativos não podem
configurar parâmetros de sensor.
- Por exemplo, imagine um sensor físico que possa funcionar nos modos "alta precisão" e "baixa energia".
- Somente 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, um modo de baixo consumo. 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á mecanismo para enviar dados dos aplicativos para os sensores ou 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 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, 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 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. Sempre que possível, os fabricantes de dispositivos precisam definir os 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 de jogos) em vez de confiar nessa implementação padrão. Os fabricantes de dispositivos também podem solicitar que os fornecedores de chips de sensor 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). Ela não é relevante para fabricantes de hardware.
JNI
O framework usa uma Java Native Interface (JNI) associada ao android.hardware e localizada no frameworks/base/core/jni/ diretório. Esse código chama o
código nativo de nível inferior para acessar o 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.
Binder IPC
Os proxies do Binder IPC facilitam a comunicação em limites de processo.
HAL
A API da camada de abstração de hardware (HAL, na sigla em inglês) de sensores é a interface entre os drivers de hardware e o framework do Android. Ela consiste em uma interface HAL sensors.h e uma implementação HAL que chamamos de 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.
No 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
atuais são definidas em sensors.h, e a funcionalidade está vinculada a essas
versões.
O framework do Android oferece suporte às versões 1.0 e 1.3, mas o suporte à versão 1.0 será descontinuado 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 a versão 1.3, consulte Descontinuação da versão 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 solicita que os fabricantes de chips de sensor forneçam os drivers, mas eles são os que escrevem 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 sensor, útil para realizar alguns cálculos de baixo nível com baixa energia enquanto o SoC pode estar no modo de suspensão. Por exemplo, a contagem de passos ou a fusão de sensores podem ser realizadas em esses chips. Também é um bom lugar para implementar o lote de sensores, adicionando FIFOs de hardware para os eventos de sensor. Consulte Lote para mais informações.
Observação: para desenvolver novos recursos do ContextHub que usam os 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 sensor é materializado depende da arquitetura. Às vezes, é um chip separado e, às vezes, incluído no mesmo chip que o SoC. As características importantes do hub de sensor são que ele precisa conter memória suficiente para o lote e consumir muito pouca energia para permitir a implementação dos sensores Android de baixa energia. Alguns hubs de sensor 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 energia.
A forma como o hub de sensor é arquitetado e como ele se comunica com os sensores e o SoC (barramento I2C, barramento SPI etc.) não é especificada pelo Android, mas precisa 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 de sensor para o SoC: uma para interrupções de ativação (para sensores de ativação) e a outra para interrupções não de ativação (para sensores nã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 são chamados de chips de 9 eixos, já que cada sensor fornece dados em 3 eixos.
Alguns desses chips também contêm alguma lógica para realizar cálculos comuns, 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. É responsabilidade do fabricante do dispositivo derivar os requisitos para sensores físicos.