A figura abaixo representa a pilha de sensores do Android. Cada componente se comunica apenas com os componentes diretamente acima e abaixo dele, embora algumas os sensores podem ignorar o hub do sensor quando ele estiver presente. Fluxos de controle da aplicativos até os sensores, e os dados fluem dos sensores para os aplicativos conteinerizados.
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 registrar-se em um sensor
Ao se registrar em um sensor, o aplicativo especifica a amostragem preferida a frequência e os requisitos de latência.
- Por exemplo, um aplicativo pode se registrar no acelerômetro padrão, a solicitação de eventos a 100 Hz e o registro de eventos com um segundo latência de rede.
- O aplicativo receberá eventos do acelerômetro a uma taxa de mínimo de 100 Hz com atraso de até um 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 acontecendo no do framework, apenas um aplicativo poderia acessar cada sensor a qualquer em um determinado período.
- Quando um primeiro aplicativo é registrado em um sensor, o framework envia uma solicitação à HAL para ativar o sensor.
- Quando outros aplicativos são registrados no mesmo sensor, o framework
os requisitos de cada aplicativo e envia a versão atualizada
parâmetros para a HAL.
- A frequência de amostragem será a máxima das frequências de amostragem solicitadas, o que significa que algumas aplicativos receberão eventos com uma frequência maior solicitado.
- A latência máxima de relatórios será a mínima solicitada. Se um aplicativo solicitar uma com uma latência máxima de relatório de 0, todos os aplicativos receberão o deste sensor no modo contínuo, mesmo que alguém tenha solicitado o sensor com latência máxima diferente de zero. Consulte Agrupamento em lotes para mais detalhes.
- Quando o último aplicativo registrado em um sensor cancelar o registro, o envia uma solicitação à HAL para desativar o sensor para que a energia não seja consumidas desnecessariamente.
Impacto da multiplexação
Essa necessidade de uma camada multiplexada no framework explica alguns aspectos de negócios.
- Quando um aplicativo solicita uma frequência de amostragem específica, não há garantir que os eventos não cheguem mais rápido. Se outro aplicativo solicitar o mesmo sensor mais rápido, a primeira aplicação também e recebê-los rapidamente.
- A mesma falta de garantia se aplica à latência máxima de relatório solicitada: 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 dos relatórios, os aplicativos não podem
configura os parâmetros do sensor.
- Por exemplo, imagine um sensor físico que possa funcionar em condições precisão” e “baixo consumo de energia”.
- Somente um desses dois modos pode ser usado em um dispositivo Android, porque Caso contrário, um aplicativo poderia solicitar o modo de alta precisão, e outro um modo de baixo consumo de energia; a estrutura não atenderia a aplicativos conteinerizados. A estrutura deve sempre ser capaz de satisfazer todos os seus clientes, para que mas isso não é possível.
- Não existe mecanismo para enviar dados de aplicativos para os sensores ou os motoristas. Isso garante que um aplicativo não possa modificar o comportamento da ou corrompendo outros aplicativos.
Fusão do sensor
O framework do Android fornece uma implementação padrão para alguns ou sensores. 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 aceleração linear estão presentes, o framework implementa esses sensores para que os aplicativos ainda poderá usá-las.
A implementação padrão não tem acesso a todos os dados dos outros têm acesso e precisam ser executados no SoC, portanto, não é tão tão precisa nem tão eficiente em termos de energia quanto outras implementações. Por mais que os fabricantes de dispositivos devem definir os próprios sensores combinados (rotação vetor, 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 podem solicitar que os fornecedores de chips do sensor forneçam uma implementação.
A implementação padrão de fusão do sensor não está sendo mantida e pode fazer com que os dispositivos que dependem dele falhem no CTS.
Configurações avançadas
Esta seção é fornecida como informações básicas para aqueles que mantêm os Código do framework do Android Open Source Project (AOSP). 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 método
código nativo de nível inferior para obter acesso ao hardware do sensor.
Framework nativo
O framework nativo é definido em frameworks/native/ e fornece um
equivalente ao pacote android.hardware. O framework nativo chama os proxies IPC Binder para ter acesso aos
serviços específicos de sensores.
IPC de vinculação
Os proxies IPC Binder facilitam a comunicação além dos limites do processo.
HAL
A API Sensors Hardware absion Layer (HAL) é a interface entre as drivers de hardware e o framework do Android. Ele consiste em uma interface HAL, sensores.h e uma implementação de HAL que chamamos de sensores.cpp.
A interface é definida pelos colaboradores do Android e do AOSP, e a é 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 para qual versão da interface ela
implementa pela configuração de your_poll_device.common.version. A HAL existente
As versões da interface são definidas em Sensores.h, e a funcionalidade delas
mais recentes.
Atualmente, o framework do Android oferece suporte às versões 1.0 e 1.3, mas a 1.0 em breve não serão mais compatíveis. Esta documentação descreve o comportamento da versão versão 1.3, para a qual todos os dispositivos devem ser atualizados. Para mais detalhes sobre como fazer upgrade para 1.3, consulte Descontinuação da versão da HAL.
Driver do kernel
Os drivers do sensor interagem com os dispositivos físicos. Em alguns casos, a HAL e os drivers são a mesma entidade de software. Em outros casos, o integrador de hardware solicita que os fabricantes de chips do sensor forneçam a mas são eles que gravam a implementação da HAL.
Em todos os casos, a implementação da HAL e os drivers de kernel são responsabilidade fabricantes de hardware, e o Android não fornece abordagens preferenciais para gravá-las.
Hub do sensor
A pilha de sensores de um dispositivo pode incluir um hub de sensor, útil para computação de baixo nível com baixa potência, enquanto o SoC pode estar modo de suspensão. Por exemplo, a contagem de passos ou a fusão de sensores podem ser realizadas esses chips. Também é um bom lugar para implementar lotes de sensores, adicionando FIFOs de hardware para os eventos dos sensores. Consulte Agrupamento em lotes para mais informações.
Observação: para desenvolver novos recursos do ContextHub que usar novos sensores ou LEDs, poderá usar Neonkey SensorHub conectado a um 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 que o SoC. Importante do hub do sensor é que ele precisa ter memória suficiente para lotes e consumir pouca energia para permitir a implementação da baixa pelos sensores do Android. Alguns hubs de sensores contêm um microcontrolador computação em nuvem e aceleradores de hardware para permitir uma computação de baixo consumo ou 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 na minimização do uso geral de energia.
Uma opção que parece ter um impacto significativo na implementação Para simplificar, duas linhas de interrupção vão do hub do sensor para o SoC: um para interrupções na ativação (para sensores de ativação) e outro para quando você não está acordado interrompe (para sensores que não ativam).
Sensores
Esses são os chips físicos de MEMs que fazem as medições. Em muitos casos, vários sensores físicos estão presentes no mesmo chip. Por exemplo, alguns ícones incluem um acelerômetro, um giroscópio e um magnetômetro. Esses ícones costumam ser são chamados de chips de nove eixos, porque 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, detecção de passos e fusão de sensores de nove eixos.
Ainda que os requisitos e as recomendações de precisão e potência do CDD tenham como alvo o e não os sensores físicos, esses requisitos afetam o de sensores físicos. Por exemplo, o requisito de precisão no jogo vetor de rotação tem implicações na precisão necessária para o giroscópio Cabe ao fabricante do dispositivo determinar os requisitos para e sensores físicos.