Tipos de sensor

Esta seção descreve os eixos do sensor, sensores de base e sensores compostos (atividade, atitude, não calibrado e interação).

Eixos do sensor

Os valores de eventos de sensores de muitos sensores são expressos em um frame específico que é estático em relação ao dispositivo.

Eixos de dispositivos móveis

A API Sensor é relativa apenas à orientação natural da tela. Os eixos não são trocados quando a orientação da tela do dispositivo muda.

Figura 1. Sistema de coordenadas (em relação a um dispositivo móvel) usado pela API Sensor

Eixos automotivos

Nas implementações do Android Automotive, os eixos são definidos em relação à estrutura da carroceria do veículo. A origem do referencial do veículo é o centro do eixo traseiro. O frame de referência do veículo é orientado para que:

• O eixo X aponta para a direita e está em um plano horizontal, perpendicular ao plano de simetria do veículo.
• O eixo Y aponta para frente e está em um plano horizontal.

Figura 2. Sistema de coordenadas (em relação a um dispositivo automotivo) usado pela API Sensor

O marco de referência do veículo é um sistema de coordenadas com orientação para a direita. Portanto, o eixo Z aponta para cima.

O eixo Z do frame de referência está alinhado à gravidade, o que significa que os eixos X e Y são horizontais. Como resultado, o eixo Y nem sempre passa pelo eixo dianteiro.

Sensores de base

Os tipos de sensores básicos são nomeados de acordo com os sensores físicos que representam. Esses sensores transmitem dados de um único sensor físico, em vez de sensores compostos que geram dados de outros sensores. Exemplos de tipos de sensores básicos incluem:

• SENSOR_TYPE_ACCELEROMETER
• SENSOR_TYPE_GYROSCOPE
• SENSOR_TYPE_MAGNETOMETER

No entanto, os sensores básicos não são iguais e não devem ser confundidos com o sensor físico subjacente. Os dados de um sensor base não são a saída bruta do sensor físico porque correções (como compensação de viés e compensação de temperatura) são aplicadas.

Por exemplo, as características de um sensor de base podem ser diferentes das características do sensor físico subjacente nos seguintes casos de uso:

• Um chip de giroscópio com uma faixa de viés de 1 deg/s.
  • Depois que a calibração de fábrica, a compensação de temperatura e a compensação de viés são aplicadas, o viés real do sensor do Android é reduzido, podendo chegar a um ponto em que o viés é garantido abaixo de 0,01 deg/s.
  • Nessa situação, dizemos que o sensor do Android tem uma viés abaixo de 0,01 deg/s, mesmo que a folha de dados do sensor indique 1 deg/s.
• Um barômetro com consumo de energia de 100 uW.
  • Como os dados gerados precisam ser transportados do chip para o SoC, o custo de energia real para coletar dados do sensor de barômetro do Android pode ser muito maior, por exemplo, 1.000 uW.
  • Nessa situação, dizemos que o sensor do Android tem um consumo de energia de 1.000 uW, mesmo que o consumo de energia medido nos fios do chip do barômetro seja de 100 uW.
• Um magnetômetro que consome 100uW quando calibrado, mas consome mais durante a calibração.
  • A rotina de calibração pode exigir a ativação do giroscópio, consumindo 5.000 uW, e a execução de algum algoritmo, custando mais 900 uW.
  • Nessa situação, dizemos que o consumo máximo de energia do sensor do Android (magnetômetro) é de 6.000 uW.
  • Nesse caso, o consumo médio de energia é a medida mais útil e é o que é relatado nas características estáticas do sensor por meio da HAL.

Acelerômetro

Modo de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER) retorna um sensor de não ativação

Um sensor de acelerômetro informa a aceleração do dispositivo ao longo dos três eixos do sensor. A aceleração medida inclui a aceleração física (mudança de velocidade) e a gravidade. A medição é informada nos campos x, y e z de sensors_event_t.acceleration.

Todos os valores são expressos em unidades SI (m/s²) e medem a aceleração do dispositivo menos a força da gravidade ao longo dos três eixos do sensor.

Confira alguns exemplos:

• A norma de (x, y, z) deve estar próxima de 0 na queda livre.
• Quando o dispositivo está plano em uma mesa e é empurrado no lado esquerdo para a direita, o valor de aceleração x é positivo.
• Quando o dispositivo está nivelado em uma mesa, o valor de aceleração ao longo de z é +9,81 alo, o que corresponde à aceleração do dispositivo (0 m/s^2) menos a força da gravidade (-9,81 m/s^2).
• Quando o dispositivo está nivelado em uma mesa e é empurrado em direção ao céu, o valor de aceleração será maior que +9,81, que corresponde à aceleração do dispositivo (+A m/s^2) menos a força da gravidade (-9,81 m/s^2).

As leituras são calibradas usando:

• Compensação de temperatura
• Calibração de viés on-line
• Calibração de balança on-line

A calibração de viés e escala só pode ser atualizada enquanto o sensor está desativado, para evitar saltos nos valores durante o streaming.

O acelerômetro também informa a precisão esperada para as leituras usando sensors_event_t.acceleration.status. Consulte as constantes SensorManager SENSOR_STATUS_* para mais informações sobre os possíveis valores desse campo.

Temperatura ambiente

Modo de relatório: mudança

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE) retorna um sensor de não ativação

Esse sensor fornece a temperatura ambiente (do local) em graus Celsius.

Sensor de campo magnético

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD) retorna um sensor de não ativação

SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD

Um sensor de campo magnético (também conhecido como magnetômetro) informa o campo magnético do ambiente, conforme medido ao longo dos três eixos do sensor.

A medição é informada nos campos x, y e z de sensors_event_t.magnetic, e todos os valores são expressos em microTesla (uT).

O magnetômetro também informa a precisão esperada para as leituras usando sensors_event_t.magnetic.status. Consulte as constantes SensorManager SENSOR_STATUS_* para mais informações sobre os possíveis valores desse campo.

As leituras são calibradas usando:

• Compensação de temperatura
• Calibração de ferro macio de fábrica (ou on-line)
• Calibração de hardware on-line

Giroscópio

Modo de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE) retorna um sensor de não ativação

Um sensor de giroscópio informa a taxa de rotação do dispositivo em torno dos três eixos do sensor.

A rotação é positiva no sentido anti-horário (regra da mão direita). Ou seja, um observador de uma localização positiva nos eixos X, Y ou Z em um dispositivo posicionado na origem informaria uma rotação positiva, caso o dispositivo parecesse girar em sentido anti-horário. Esta é a definição matemática padrão de rotação positiva e não concorda com a definição aeroespacial de rolagem.

A medição é informada nos campos x, y e z de sensors_event_t.gyro e todos os valores são radianos por segundo (rad/s).

As leituras são calibradas usando:

• Compensação de temperatura
• Compensação de escala de fábrica (ou on-line)
• Calibração de viés on-line (para remover a deriva)

O giroscópio também informa a precisão esperada das leituras por meio de sensors_event_t.gyro.status. Consulte as constantes SensorManager SENSOR_STATUS_* para mais informações sobre os possíveis valores desse campo.

O giroscópio não pode ser emulado com base em magnetômetros e acelerômetros, porque isso reduziria a consistência e a capacidade de resposta local. Ele precisa ser baseado em um chip de giroscópio comum.

Frequência cardíaca

Modo de relatório: ao mudar

getDefaultSensor(SENSOR_TYPE_HEART_RATE) retorna um sensor que não é ativado.

Um sensor de frequência cardíaca informa a frequência cardíaca atual da pessoa que está tocando no dispositivo.

A frequência cardíaca atual em batimentos por minuto (BPM) é informada em sensors_event_t.heart_rate.bpm, e o status do sensor é informado em sensors_event_t.heart_rate.status. Consulte as constantes SensorManager SENSOR_STATUS_* para mais informações sobre os possíveis valores desse campo. Em particular, na primeira ativação, a menos que o dispositivo não esteja no corpo, o campo de status do primeiro evento precisa ser definido como SENSOR_STATUS_UNRELIABLE. Como esse sensor está em mudança, os eventos são gerados quando e somente quando heart_rate.bpm ou heart_rate.status mudaram desde o último evento. Os eventos são gerados a cada sampling_period.

sensor_t.requiredPermission é sempre SENSOR_PERMISSION_BODY_SENSORS.

Claro

Modo de relatório: ao mudar

getDefaultSensor(SENSOR_TYPE_LIGHT) retorna um sensor de não ativação

Um sensor de luz informa a iluminação atual em unidades de lux do SI.

A medição é informada em sensors_event_t.light.

Proximidade

Modo de relatório: ao mudar

Geralmente definido como um sensor de ativação

getDefaultSensor(SENSOR_TYPE_PROXIMITY) retorna um sensor de ativação

Um sensor de proximidade informa a distância entre o sensor e a superfície visível mais próxima.

Até o Android 4.4, os sensores de proximidade eram sempre sensores de ativação, ativando o SoC ao detectar uma mudança na proximidade. Após o Android 4.4, recomendamos implementar primeiro a versão de ativação desse sensor, já que é ela que é usada para ligar e desligar a tela ao fazer ligações.

A medida é informada em centímetros no sensors_event_t.distance. Alguns sensores de proximidade são compatíveis apenas com medições binárias de "perto" ou "longe". Nesse caso, o sensor informa o valor sensor_t.maxRange no estado "longe" e um valor menor que sensor_t.maxRange no estado "perto".

Pressão

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_PRESSURE) retorna um sensor de não ativação

Um sensor de pressão (também conhecido como barômetro) informa a pressão atmosférica em hectopascais (hPa).

As leituras são calibradas usando

• Compensação de temperatura
• Calibração de viés de fábrica
• Calibração da escala de fábrica

O barômetro é usado com frequência para estimar mudanças de elevação. Para estimar a elevação absoluta, a pressão ao nível do mar (que muda de acordo com o clima) precisa ser usada como referência.

Umidade relativa

Modo de relatório: ao mudar

getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY) retorna um sensor de não ativação

Um sensor de umidade relativa mede a umidade do ar ambiente e retorna um valor em porcentagem.

Tipos de sensores compostos

Um sensor composto gera dados processando e/ou fundindo dados de um ou vários sensores físicos. Qualquer sensor que não seja base é chamado de sensor composto. Exemplos de sensores compostos incluem:

• Detector de passos e movimento significativo, que geralmente são baseados em um acelerômetro, mas também podem ser baseados em outros sensores, se o consumo de energia e a precisão forem aceitáveis.
• Vetor de rotação do jogo, com base em um sensor de aceleração e um giroscópio.
• Giroscópio não calibrado, que é semelhante ao sensor de base do giroscópio, mas com a calibração de viés sendo informada separadamente em vez de ser corrigida na medição.

Assim como os sensores básicos, as características dos sensores compostos vêm das características dos dados finais. Por exemplo, o consumo de energia de um vetor de rotação de jogo provavelmente é igual à soma dos consumos de energia do chip do acelerômetro, do giroscópio, do chip que processa os dados e dos barramentos que transportam os dados. Como outro exemplo, a deriva de um vetor de rotação de jogo depende tanto da qualidade do algoritmo de calibração quanto das características do sensor físico.

A tabela a seguir lista os tipos de sensores compostos disponíveis. Cada sensor composto depende de dados de um ou vários sensores físicos. Evite escolher outros sensores físicos para aproximar os resultados, porque eles oferecem uma experiência de usuário ruim.

Tipo de sensor	Categoria	Sensores físicos subjacentes	Modo de relatório
Vetor de rotação do jogo	Atitude	Acelerômetro, giroscópio, NÃO USE o magnetômetro	Contínuo
Vetor de rotação geomagnética	Atitude	Acelerômetro, magnetômetro, NÃO PODE USAR o giroscópio	Contínuo
Gesto de Glance	Interação	Indefinido	Uma vez
Gravidade	Atitude	Acelerômetro, giroscópio	Contínuo
Giroscópio não calibrado	Não calibrado	Giroscópio	Contínuo
Aceleração linear	Atividade	Acelerômetro, giroscópio (se houver) ou magnetômetro (se não houver giroscópio)	Contínuo
Campo magnético não calibrado	Não calibrado	Magnetômetro	Contínuo
Orientação (descontinuado)	Atitude	Acelerômetro, magnetômetro, giroscópio (se houver)	Contínuo
Gesto de pegar	Interação	Indefinido	One-shot
Vetor de rotação	Atitude	Acelerômetro, magnetômetro, giroscópio	Contínuo
Movimento significativo	Atividade	Acelerômetro (ou outro, desde que tenha consumo muito baixo)	One-shot
Contador de passos	Atividade	Acelerômetro	Ao mudar
Detector de passos	Atividade	Acelerômetro	Especial
Detetor de inclinação	Atividade	Acelerômetro	Especial
Gesto de ativação	Interação	Indefinido	One-shot

= Sensor de baixo consumo

Sensores compostos de atividade

Aceleração linear

Sensores físicos subjacentes: acelerômetro e, se houver, giroscópio (ou magnetômetro, se o giroscópio não estiver presente)

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION) retorna um sensor de não ativação

Um sensor de aceleração linear informa a aceleração linear do dispositivo no frame do sensor, sem incluir a gravidade.

Conceitualmente, a saída é a saída do sensor de aceleração menos a saída do sensor de gravidade. É informado em m/s^2 nos campos x, y e z de sensors_event_t.acceleration.

As leituras em todos os eixos devem estar próximas de 0 quando o dispositivo estiver imóvel.

Se o dispositivo tiver um giroscópio, o sensor de aceleração linear precisará usar o giroscópio e o acelerômetro como entrada.

Se o dispositivo não tiver um giroscópio, o sensor de aceleração linear precisará usar o acelerômetro e o magnetômetro como entradas.

Movimento significativo

Sensor físico subjacente: acelerômetro (ou outro de baixa potência)

Modo de relatório: one-shot

Baixo consumo energético

Implemente apenas a versão de ativação desse sensor.

getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION) retorna um sensor de ativação

Um detector de movimento significativo é acionado quando detecta um movimento significativo: um movimento que pode levar a uma mudança no local do usuário.

Exemplos de movimentos significativos são:

• A pé ou de bicicleta
• Sentado em um carro, ônibus ou trem em movimento

Exemplos de situações que não acionam movimentos significativos:

• O smartphone está no bolso e a pessoa não está se movendo
• O smartphone está em uma mesa e ela balança um pouco devido ao tráfego ou à máquina de lavar perto

De modo geral, o detector de movimento significativo é usado para reduzir o consumo de energia da determinação da localização. Quando os algoritmos de localização detectam que o dispositivo está estático, eles podem alternar para um modo de baixo consumo de energia, em que dependem de movimentos significativos para despertar o dispositivo quando o usuário mudar de local.

Esse sensor precisa ter baixo consumo de energia. Ele faz uma troca de consumo de energia que pode resultar em uma pequena quantidade de falsos negativos. Isso é feito por alguns motivos:

• O objetivo desse sensor é economizar energia.
• O acionamento de um evento quando o usuário não está em movimento (falso positivo) é dispendioso em termos de poder, por isso deve ser evitado.
• Não acionar um evento quando o usuário está em movimento (falso negativo) é aceitável, desde que isso não seja feito repetidamente. Se o usuário estiver andando há 10 segundos, não acionar um evento nesses 10 segundos não é aceitável.

Cada evento do sensor informa 1 em sensors_event_t.data[0].

Detector de passos

Sensor físico subjacente: acelerômetro (e possivelmente outros, desde que de baixo consumo)

Modo de relatório: especial (um evento por etapa realizada)

Baixo consumo energético

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR) retorna um sensor de não ativação

Um detector de passos gera um evento sempre que o usuário dá um passo.

O carimbo de data/hora do evento sensors_event_t.timestamp corresponde ao momento em que o pé toca o chão, gerando uma alta variação na aceleração.

Em comparação com o pedômetro, o detector de passos tem uma latência menor (menos de dois segundos). O detector e o contador de passos detectam quando o usuário está caminhando, correndo ou subindo escadas. Elas não podem ser acionadas quando o usuário estiver pedalando, dirigindo ou em outros veículos.

Esse sensor precisa ter baixo consumo de energia. Ou seja, se a detecção de passos não puder ser feita no hardware, esse sensor não deverá ser definido. Mais especificamente, quando o detector de passos está ativado e o acelerômetro não, apenas as etapas precisam acionar interrupções (e não todas as leituras do acelerômetro).

sampling_period_ns não afeta os detectores de passos.

Cada evento do sensor informa 1 em sensors_event_t.data[0].

Contador de passos

Sensor físico subjacente: acelerômetro (e possivelmente outros, desde que de baixo consumo)

Modo de relatório: ao mudar

Baixo consumo energético

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER) retorna um sensor de não ativação

Um contador de passos informa o número de passos do usuário desde a última reinicialização enquanto o sensor estava ativado.

A medição é informada como uint64_t em sensors_event_t.step_counter e é redefinida para zero apenas na reinicialização do sistema.

O carimbo de data/hora do evento é definido como a hora em que a última etapa dele foi realizada.

Consulte o tipo de sensor Detector de passos para saber o significado do tempo de uma etapa.

Em comparação com o detector de passos, o contador de passos pode ter uma latência maior (até 10 segundos). Graças a essa latência, esse sensor tem uma alta precisão. A contagem de passos após um dia inteiro de medições deve estar dentro de 10% da contagem real. O detector e o contador de passos detectam quando o usuário está caminhando, correndo ou subindo escadas. Elas não podem ser acionadas quando o usuário estiver pedalando, dirigindo ou em outros veículos.

O hardware precisa garantir que a contagem interna de etapas nunca transborde. O tamanho mínimo do contador interno do hardware é de 16 bits. Em caso de transbordamento iminente (no máximo a cada ~2^16 etapas), o SoC pode ser ativado para que o driver possa fazer a manutenção do contador.

Conforme indicado em Interaction, embora esse sensor funcione, ele não vai interromper nenhum outro sensor, principalmente o acelerômetro, que pode muito bem estar em uso.

Se um dispositivo específico não oferecer suporte a esses modos de operação, esse tipo de sensor não poderá ser informado pelo HAL. Ou seja, não é aceitável "emular" esse sensor no HAL.

Esse sensor precisa ter baixo consumo de energia. Ou seja, se a detecção de etapas não puder ser feita no hardware, esse sensor não será definido. Especificamente, quando o contador de etapas é ativado e o acelerômetro não, apenas as etapas podem acionar interrupções (não dados do acelerômetro).

Detector de inclinação

Sensor físico subjacente: acelerômetro (e possivelmente outros, desde que de baixo consumo)

Modo de relatório: Especial

Baixo consumo energético

Implemente apenas a versão de ativação desse sensor.

getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR) retorna um sensor de ativação

Um detector de inclinação gera um evento sempre que um evento de inclinação é detectado.

Um evento de inclinação é definido pela direção da média da janela de 2 segundos de gravidade mudando pelo menos 35 graus desde a ativação ou o último evento gerado pelo sensor. Confira o algoritmo:

• reference_estimated_gravity = média das medições do acelerômetro no primeiro segundo após a ativação ou à gravidade estimada quando o último evento de inclinação foi gerado.
• current_estimated_gravity = média das medições do sensor de aceleração nos últimos 2 segundos.
• Acionar quando angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees

Acelerações grandes sem uma mudança na orientação do smartphone não devem acionar um evento de inclinação. Por exemplo, uma curva fechada ou uma aceleração forte ao dirigir um carro não deve acionar um evento de inclinação, mesmo que o ângulo da aceleração média possa variar em mais de 35 graus. Normalmente, esse sensor é implementado com a ajuda de apenas um acelerômetro. Outros sensores também podem ser usados se não aumentarem o consumo de energia significativamente. Esse é um sensor de baixo consumo que permite que o SoC entre no modo de suspensão. Não emule esse sensor no HAL. Cada evento do sensor informa 1 em sensors_event_t.data[0].

Sensores compostos de atitude

Vetor de rotação

Sensores físicos subjacentes: acelerômetro, magnetômetro e giroscópio

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR) retorna um sensor de não ativação

Um sensor de vetor de rotação informa a orientação do dispositivo em relação ao sistema de coordenadas leste-norte-cima. Geralmente, é obtida pela integração de leituras de acelerômetro, giroscópio e magnetômetro. O sistema de coordenadas leste-norte-cima é definido como uma base ortonormal direta em que:

• X aponta para o leste e é tangencial ao solo.
• Y aponta para o norte e é tangencial ao solo.
• Z aponta em direção ao céu e é perpendicular ao solo.

A orientação do smartphone é representada pela rotação necessária para alinhar as coordenadas leste-norte-cima com as coordenadas do smartphone. Ou seja, aplicar a rotação ao frame do mundo (X,Y,Z) as alinharia com as coordenadas do smartphone (x,y,z).

A rotação pode ser vista como a rotação do smartphone em um ângulo θ em torno de um eixo rot_axis para passar da orientação de referência (orientação alinhada leste-norte-cima) para a orientação atual do dispositivo. A rotação é codificada como os quatro componentes x, y, z, w sem unidade de um quatérnio de unidade:

• sensors_event_t.data[0] = rot_axis.x*sin(theta/2)
• sensors_event_t.data[1] = rot_axis.y*sin(theta/2)
• sensors_event_t.data[2] = rot_axis.z*sin(theta/2)
• sensors_event_t.data[3] = cos(theta/2)

Em que:

• Os campos x, y e z de rot_axis são as coordenadas leste-norte-cima de um vetor de comprimento unitário que representa o eixo de rotação.
• theta é o ângulo de rotação

O quatérnion é um quatérnion unitário: ele precisa ter norma 1. Não garantir isso causará um comportamento instável do cliente.

Além disso, esse sensor informa uma precisão de direção estimada:

sensors_event_t.data[4] = estimated_accuracy (em radianos)

O erro de cabeçalho precisa ser inferior a estimated_accuracy 95% do tempo. Esse sensor precisa usar um giroscópio como a entrada principal de mudança de orientação.

Esse sensor também usa a entrada do acelerômetro e do magnetômetro para compensar o deslocamento do giroscópio e não pode ser implementado usando apenas o acelerômetro e o magnetômetro.

Vetor de rotação do jogo

Sensores físicos subjacentes: acelerômetro e giroscópio (sem magnetômetro)

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR) retorna um sensor de não ativação

Um sensor vetorial de rotação para jogos é semelhante a um sensor vetorial de rotação, mas não usa o campo geomagnético. Por isso, o eixo Y não aponta para o norte, e sim para outra referência. Essa referência pode se deslocar na mesma ordem de magnitude que o giroscópio em torno do eixo Z.

Consulte o sensor vetor de rotação para saber como definir sensors_event_t.data[0-3]. Esse sensor não informa uma precisão de direção estimada: sensors_event_t.data[4] está reservado e precisa ser definido como 0.

No caso ideal, um smartphone girado e retornado à mesma orientação do mundo real precisa informar o mesmo vetor de rotação do jogo.

Esse sensor precisa ser baseado em um giroscópio e um acelerômetro. Não é possível usar o magnetômetro como entrada, além de indiretamente, pela estimativa da polarização do giroscópio.

Gravidade

Sensores físicos subjacentes: acelerômetro e (se presente) giroscópio (ou magnetômetro, se o giroscópio não estiver presente)

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_GRAVITY) retorna um sensor de não ativação

Um sensor de gravidade informa a direção e a magnitude da gravidade nas coordenadas do dispositivo.

Os componentes do vetor de gravidade são informados em m/s² nos campos x, y e z de sensors_event_t.acceleration.

Quando o dispositivo está em repouso, a saída do sensor de gravidade é idêntica à do acelerômetro. Na Terra, a magnitude é de cerca de 9,8 m/s^2.

Se o dispositivo tiver um giroscópio, o sensor de gravidade precisará usar o giroscópio e o acelerômetro como entrada.

Se o dispositivo não tiver um giroscópio, o sensor de gravidade precisará usar o acelerômetro e o magnetômetro como entrada.

Vetor de rotação geomagnética

Sensores físicos subjacentes: acelerômetro e magnetômetro (sem giroscópio)

Modo de relatório: contínuo

Baixo consumo energético

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) retorna um sensor de não ativação

Um vetor de rotação geomagnética é semelhante a um sensor vetorial de rotação, mas usa um magnetômetro e não um giroscópio.

Esse sensor precisa ser baseado em um magnetômetro. Ele não pode ser implementado usando um giroscópio, e a entrada do giroscópio não pode ser usada por esse sensor.

Consulte o sensor de vetor de rotação para ver detalhes sobre como definir sensors_event_t.data[0-4].

Assim como no sensor vetorial de rotação, o erro de direção precisa ser menor que a precisão estimada (sensors_event_t.data[4]) 95% do tempo.

Esse sensor precisa ter baixo consumo de energia, então ele precisa ser implementado no hardware.

Orientação (descontinuado)

Sensores físicos subjacentes: acelerômetro, magnetômetro e (se presente) giroscópio

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_ORIENTATION) retorna um sensor que não é ativado.

Observação:esse é um tipo de sensor mais antigo que foi descontinuado no SDK do Android. Ele foi substituído pelo sensor vetorial de rotação, que é definido de forma mais clara. Use o sensor de vetor de rotação sobre o sensor de orientação sempre que possível.

Um sensor de orientação informa a atitude do dispositivo. As medições são informadas em graus nos campos x, y e z de sensors_event_t.orientation:

• sensors_event_t.orientation.x: azimute, o ângulo entre a direção do norte magnético e o eixo Y, em torno do eixo Z (0<=azimuth<360). 0=Norte, 90=Leste, 180=Sul, 270=Oeste.
• sensors_event_t.orientation.y: inclinação, rotação ao redor do eixo X (-180<=pitch<=180), com valores positivos quando o eixo Z se move em direção ao eixo Y.
• sensors_event_t.orientation.z: rolagem, rotação em torno do eixo Y (-90<=roll<=90), com valores positivos quando o eixo X se move em direção ao eixo Z.

Por motivos históricos, o ângulo de inclinação é positivo no sentido horário. (Em termos matemáticos, ele precisa ser positivo no sentido anti-horário):

Essa definição é diferente da guinada, inclinação e rolagem usadas na aviação, em que o eixo X está ao longo do lado mais longo do avião (da cauda ao nariz).

O sensor de orientação também informa a precisão esperada das leituras pelo sensors_event_t.orientation.status. Consulte as constantes SensorManager SENSOR_STATUS_* para mais informações sobre os possíveis valores desse campo.

Sensores não calibrados

Os sensores sem calibração fornecem resultados mais brutos e podem incluir algumas tendências, mas também contêm menos "saltos" de correções aplicadas por meio da calibração. Alguns apps podem preferir esses resultados não calibrados e considerá-los mais suaves e confiáveis. Por exemplo, se um app estiver tentando realizar uma fusão de sensor própria, a apresentação de calibrações pode distorcer os resultados.

Acelerômetro não calibrado

Sensor físico subjacente: acelerômetro

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED) retorna um sensor de não ativação

Um sensor de acelerômetro não calibrado informa a aceleração do dispositivo ao longo dos três eixos do sensor sem nenhuma correção de tendência (a tendência de fábrica e a compensação de temperatura são aplicadas a medições não calibradas), além de uma estimativa de tendência. Todos os valores são expressos em unidades SI (m/s²) e são informados nos campos de sensors_event_t.uncalibrated_accelerometer:

• x_uncalib: aceleração (sem compensação de tendência) ao longo do eixo X
• y_uncalib: aceleração (sem compensação de tendência) ao longo do eixo Y
• z_uncalib: aceleração (sem compensação de tendência) ao longo do eixo Z
• x_bias: tendência estimada ao longo do eixo X
• y_bias: viés estimado no eixo Y
• z_bias: viés estimado ao longo do eixo Z

Giroscópio não calibrado

Sensor físico subjacente: giroscópio

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED) retorna um sensor de não ativação

Um giroscópio não calibrado informa a taxa de rotação em torno dos eixos do sensor sem aplicar a compensação de tendência a eles, junto com uma estimativa de tendência. Todos os valores são expressos em radianos/segundo e são informados nos campos de sensors_event_t.uncalibrated_gyro:

• x_uncalib: velocidade angular (sem compensação de deslocamento) ao redor do eixo X
• y_uncalib: velocidade angular (sem compensação de deslocamento) ao redor do eixo Y
• z_uncalib: velocidade angular (sem compensação de deslocamento) ao redor do eixo Z
• x_bias: deslocamento estimado ao redor do eixo X
• y_bias: deslocamento estimado ao redor do eixo Y
• z_bias: deslocamento estimado ao redor do eixo Z

Conceitualmente, a medição não calibrada é a soma da medição calibrada e da estimativa de viés: _uncalibrated = _calibrated + _bias.

Os valores x_bias, y_bias e z_bias devem pular assim que a estimativa do viés mudar, e devem ser estáveis pelo resto do tempo.

Consulte a definição do sensor do giroscópio para saber detalhes sobre o sistema de coordenadas usado.

A calibração de fábrica e a compensação de temperatura precisam ser aplicadas às medições. Além disso, a estimativa de deriva do giroscópio precisa ser implementada para que estimativas razoáveis possam ser informadas em x_bias, y_bias e z_bias. Se a implementação não conseguir estimar a deriva, esse sensor não poderá ser implementado.

Se esse sensor estiver presente, o sensor de giroscópio correspondente também precisará estar presente e ambos os sensores precisarão compartilhar os mesmos valores sensor_t.name e sensor_t.vendor.

Campo magnético não calibrado

Sensor físico subjacente: magnetômetro

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED) retorna um sensor de não ativação

Um sensor de campo magnético sem calibração informa o campo magnético ambiente com uma estimativa de calibração de ferro duro. Todos os valores são expressos em microTesla (µT) e são informados nos campos de sensors_event_t.uncalibrated_magnetic:

• x_uncalib: campo magnético (sem compensação de ferro duro) ao longo do eixo X
• y_uncalib: campo magnético (sem compensação de ferro duro) ao longo do eixo Y
• z_uncalib: campo magnético (sem compensação de ferro duro) ao longo do eixo Z
• x_bias: estimativa da polarização do ferro ao longo do eixo X
• y_bias: estimativa da polarização do ferro ao longo do eixo Y
• z_bias: estimativa da polarização do ferro ao longo do eixo Z

Conceitualmente, a medição não calibrada é a soma da medição calibrada e da estimativa de viés: _uncalibrated = _calibrated + _bias.

O magnetômetro sem calibração permite que algoritmos de nível mais alto processem estimativas ruins de ferro duro. Os valores x_bias, y_bias e z_bias devem mudar assim que a estimativa do hardware mudar, e devem permanecer estáveis pelo resto do tempo.

A calibração de ferro macio e a compensação de temperatura precisam ser aplicadas às medições. Além disso, a estimativa rígida precisa ser implementada para que estimativas razoáveis possam ser informadas em x_bias, y_bias e z_bias. Se a implementação não conseguir estimar a inclinação, esse sensor não poderá ser implementado.

Se esse sensor estiver presente, o sensor de campo magnético correspondente também precisa estar presente, e ambos precisam compartilhar os mesmos valores de sensor_t.name e sensor_t.vendor.

Ângulo de articulação

Modo de relatório: ao mudar

getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) retorna um sensor de ativação

Um sensor de ângulo de dobradiça mede o ângulo, em graus, entre duas partes integrais do dispositivo. O movimento de uma articulação medido por esse tipo de sensor pode mudar as maneiras como o usuário pode interagir com o dispositivo, por exemplo, desdobrando ou revelando uma tela.

Sensores compostos de interação

Alguns sensores são usados principalmente para detectar interações com o usuário. Não definimos como esses sensores precisam ser implementados, mas eles precisam ter baixo consumo de energia e é responsabilidade do fabricante do dispositivo verificar a qualidade deles em termos de experiência do usuário.

Gesto de ativação

Sensores físicos subjacentes: indefinidos (qualquer coisa de baixo consumo)

Modo de relatório: One-shot

Baixo consumo energético

Implemente apenas a versão de ativação desse sensor.

getDefaultSensor(SENSOR_TYPE_WAKE_GESTURE) retorna um sensor de ativação

Um sensor de gesto de ativação permite ativar o dispositivo com base em um movimento específico. Quando esse sensor é acionado, o dispositivo se comporta como se o botão liga/desliga tivesse sido pressionado, ativando a tela. Esse comportamento (ligar a tela quando o sensor é acionado) pode ser desativado pelo usuário nas configurações do dispositivo. Mudanças nas configurações não afetam o comportamento do sensor, apenas se o framework liga a tela quando ele é acionado. O gesto a ser detectado não é especificado e pode ser escolhido pelo fabricante do dispositivo.

Esse sensor precisa ser de baixa potência, porque provavelmente será ativado 24 horas.

Cada evento do sensor informa 1 em sensors_event_t.data[0].

Gesto de levantar a mão

Sensores físicos subjacentes: indefinidos (qualquer coisa de baixo consumo)

Modo de relatório: One-shot

Baixo consumo energético

Implemente apenas a versão de ativação deste sensor.

getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE) retorna um sensor de ativação

Um sensor de gesto de levantamento é acionado quando o dispositivo é levantado, independente de onde ele estava antes (mesa, bolso, bolsa).

Cada evento do sensor informa 1 em sensors_event_t.data[0].

Gesto de olhar

Sensores físicos subjacentes: indefinidos (qualquer coisa de baixo consumo)

Modo de relatório: One-shot

Baixo consumo energético

Implemente apenas a versão de ativação deste sensor.

getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE) retorna um sensor de ativação

Um sensor de gesto de relance permite ativar brevemente a tela para que o usuário possa conferir o conteúdo na tela com base em um movimento específico. Quando esse sensor é acionado, o dispositivo ativa a tela momentaneamente para permitir que o usuário confira notificações ou outro conteúdo enquanto o dispositivo permanece bloqueado em um estado não interativo (em suspensão), e a tela é desligada novamente. Esse comportamento (acendendo a tela brevemente quando esse sensor é acionado) pode ser desativado pelo usuário nas configurações do dispositivo. Mudanças nas configurações não afetam o comportamento do sensor, apenas se o framework liga brevemente a tela quando ele é acionado. O gesto a ser detectado não é especificado e pode ser escolhido pelo fabricante do dispositivo.

Esse sensor precisa ter baixo consumo de energia, já que provavelmente será ativado 24 horas por dia. Cada evento do sensor informa 1 em sensors_event_t.data[0].

Sensores IMU de eixos limitados

Disponíveis no Android 13, os sensores IMU de eixos limitados são sensores que oferecem suporte a casos de uso em que nem todos os três eixos (x, y, z) estão disponíveis. Os tipos de IMU padrão no Android (como SENSOR_TYPE_ACCELEROMETER e SENSOR_TYPE_GYROSCOPE) assumem que os três eixos são compatíveis. No entanto, nem todos os formatos e dispositivos oferecem suporte a acelerômetros e giroscópios de três eixos.

Eixos limitados do acelerômetro

Sensores físicos subjacentes: acelerômetro

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES) retorna um sensor de não ativação

Um sensor de eixos limitados do acelerômetro é equivalente a TYPE_ACCELEROMETER, mas oferece suporte a casos em que um ou dois eixos não são compatíveis.

Os três últimos valores de evento do sensor informados pelo sensor representam se o valor de aceleração para os eixos x, y e z é compatível. O valor 1.0 indica que o eixo é compatível, e o valor 0 indica que ele não é compatível. Os fabricantes de dispositivos identificam os eixos compatíveis no momento da criação, e os valores não mudam durante a execução.

Os fabricantes de dispositivos precisam definir os valores de aceleração para eixos não usados como 0, em vez de valores indefinidos.

Eixos limitados do giroscópio

Sensores físicos subjacentes: giroscópio

Modo de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES) retorna um sensor de não ativação

Um sensor de eixos limitados do giroscópio é equivalente a TYPE_GYROSCOPE, mas é compatível com casos em que um ou dois eixos não são aceitos.

Os últimos três valores de evento do sensor relatados pelo sensor representam se o valor de velocidade angular para os eixos x, y e z é compatível. Um valor de 1.0 indica que o eixo tem suporte, e um valor de 0 indica que ele não tem suporte. Os fabricantes de dispositivos identificam os eixos compatíveis no momento da criação, e os valores não mudam durante a execução.

Os fabricantes de dispositivos precisam definir os valores de velocidade angular para eixos não usados como 0.

Eixos limitados do acelerômetro não calibrados

Sensores físicos subjacentes: acelerômetro

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED) retorna um sensor que não é ativado.

Um sensor não calibrado de eixos limitados do acelerômetro é equivalente a TYPE_ACCELEROMETER_UNCALIBRATED, mas oferece suporte a casos em que um ou dois eixos não são compatíveis.

Os três últimos valores de evento do sensor informados pelo sensor representam se os valores de aceleração e viés para os eixos x, y e z são aceitos. Um valor de 1.0 indica que o eixo tem suporte, e um valor de 0 indica que ele não tem suporte. Os fabricantes de dispositivos identificam os eixos compatíveis no momento da criação, e os valores não mudam durante a execução.

Os fabricantes de dispositivos precisam definir os valores de aceleração e viés para eixos não usados como 0.

Giroscópio com eixos limitados não calibrados

Sensores físicos subjacentes: giroscópio

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED) retorna um sensor que não é ativado.

Um sensor não calibrado com eixos limitados do giroscópio é equivalente a TYPE_GYROSCOPE_UNCALIBRATED, mas oferece suporte a casos em que um ou dois eixos não são compatíveis.

Os últimos três valores de evento relatados pelo sensor representam se os valores de velocidade angular e deslocamento para os eixos x, y e z são compatíveis. Um valor de 1.0 indica que o eixo tem suporte, e um valor de 0 indica que ele não tem suporte. Os fabricantes de dispositivos identificam os eixos compatíveis no momento da criação, e os valores não mudam durante a execução.

Os fabricantes de dispositivos precisam definir os valores de velocidade angular e deriva para eixos não usados como 0.

IMU de eixos limitados compostos

Sensores físicos subjacentes: qualquer combinação de acelerômetro de três eixos, giroscópio de três eixos, acelerômetro de três eixos não calibrado e giroscópio de três eixos não calibrado.

Modo de relatório: Contínuo

Um sensor de IMU de eixos limitados composto é equivalente a um sensor de IMU de eixos limitados, mas em vez de ser compatível com a HAL, ele converte os dados do sensor de três eixos em variantes equivalentes de eixos limitados. Esses sensores compostos são ativados apenas para dispositivos automotivos.

A tabela a seguir mostra um exemplo de conversão de um acelerômetro padrão de três eixos para um acelerômetro composto de eixos limitados.

Valores de SensorEvent para SENSOR_TYPE_ACCELEROMETER	Exemplo de SensorEvent SENSOR_TYPE_ACCELEROMETER	SensorEvent composto SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES
values[0]	-0,065	-0,065
valores[1]	0,078	0,078
values[2]	9,808	9,808
valores[3]	N/A	1.0
values[4]	N/A	1.0
values[5]	N/A	1.0

Sensores automotivos

Sensores para casos de uso automotivo.

Título

Sensores físicos subjacentes: qualquer combinação de GPS, magnetômetro, acelerômetro e giroscópio.

Modo de relatórios: contínuo

getDefaultSensor(SENSOR_TYPE_HEADING) retorna um sensor de não ativação

Disponível no Android 13, um sensor de orientação mede a direção em que o dispositivo está apontando em relação ao norte verdadeiro em graus. O sensor de direção inclui dois valores SensorEvent. Uma para a direção do dispositivo medida e outra para a precisão do valor de direção fornecido.

Os valores de direção informados por esse sensor precisam estar entre 0.0 (inclusivo) e 360.0 (exclusivo), com 0 indicando norte, 90 leste, 180 sul e 270 oeste.

A precisão desse sensor é definida com 68% de confiança. No caso em que a distribuição subjacente é normal gaussiana, a precisão é um desvio padrão. Por exemplo, se o sensor de direção retornar um valor de direção de 60 graus e um valor de precisão de 10 graus, há uma probabilidade de 68% de a direção verdadeira estar entre 50 e 70 graus.