Visão geral dos sensores

A maioria dos dispositivos Android tem sensores integrados que medem movimento, orientação e várias condições ambientais. Esses sensores geram dados brutos com alta precisão e são úteis para monitorar o movimento ou o posicionamento tridimensional do dispositivo ou para acompanhar as mudanças no ambiente ao redor. Por exemplo, um jogo pode rastrear leituras do sensor de gravidade de um dispositivo para inferir gestos e movimentos complexos do usuário, como inclinação, vibração, rotação ou oscilação. Da maneira semelhante, um aplicativo de previsão do tempo pode usar os sensores de temperatura e de umidade para calcular e informar o ponto de condensação ou um aplicativo de viagem pode usar o sensor de campo geomagnético e o acelerômetro para informar um ponto cardinal.

Confira os seguintes recursos relacionados:

Sensores
Sensores de movimento
Sensores de posição
Sensores de ambiente
Accelerometer Play (em inglês)
Demonstrações de APIs (SO - RotationVectorDemo) (em inglês)

A plataforma Android é compatível com três categorias amplas de sensores:

Sensores de movimento
Esses sensores medem forças rotacionais e de aceleração em três eixos. Essa categoria inclui acelerômetros, sensores de gravidade, giroscópios e sensores vetoriais de rotação.
Sensores ambientais
Esses sensores medem vários parâmetros ambientais, como temperatura e pressão do ar ambiente, iluminação e umidade. Essa categoria inclui barômetros, fotômetros e termômetros.
Sensores de posição
Esses sensores medem a posição física de um dispositivo. Essa categoria inclui sensores de orientação e magnetômetros.

É possível acessar os sensores disponíveis no dispositivo e coletar dados brutos por meio do framework de sensor do Android. Esse framework oferece várias classes e interfaces que ajudam a realizar uma grande variedade de tarefas relacionadas ao sensor. Por exemplo, você pode usar o framework para as seguintes ações:

Determinar quais sensores estão disponíveis em um dispositivo.
Determinar os recursos de um sensor individual, como alcance máximo, fabricante, requisitos de energia e resolução.
Coletar dados brutos do sensor e definir a taxa mínima de velocidade dessa coleta.
Registrar e cancelar o registro dos listeners de eventos que monitoram mudanças do sensor.

Esse tópico traz uma visão geral dos sensores disponíveis na plataforma Android. Ele também oferece uma introdução ao framework de sensor.

Introdução aos sensores

O framework de sensor do Android permite acessar vários tipos de sensores. Alguns deles são baseados em hardware, enquanto outros são baseados em software. Sensores baseados em hardware são componentes físicos incorporados em um dispositivo móvel ou tablet. Eles derivam os dados medindo de forma direta propriedades ambientais específicas, como aceleração, intensidade do campo geomagnético ou alteração angular. Sensores baseados em software não são dispositivos físicos, embora imitem sensores baseados em hardware. Os sensores baseados em software derivam os dados de um ou mais sensores baseados em hardware e também são conhecidos como sensores virtuais ou sintéticos. O sensor de aceleração linear e o sensor de gravidade são exemplos de sensores baseados em software. A Tabela 1 resume os sensores compatíveis com a plataforma Android.

Alguns dispositivos Android têm todos os tipos de sensores. Por exemplo, a maioria dos dispositivos móveis e tablets tem um acelerômetro e um magnetômetro, mas o número daqueles que têm barômetros ou termômetros é menor. Além disso, um dispositivo pode ter mais de um sensor de um determinado tipo. Por exemplo, um dispositivo pode ter dois sensores de gravidade, cada um com um alcance diferente.

Tabela 1. Tipos de sensor compatíveis com a plataforma Android.

Sensor	Tipo	Descrição	Usos comuns
`TYPE_ACCELEROMETER`	Hardware	Mede a força de aceleração em m/s² que é aplicada a um dispositivo nos três eixos físicos (x, y, z), incluindo a força da gravidade.	Detecção de movimento (agitação, inclinação etc.).
`TYPE_AMBIENT_TEMPERATURE`	Hardware	Mede a temperatura ambiente em graus Celsius (°C). Veja a observação abaixo.	Monitoramento das temperaturas do ar.
`TYPE_GRAVITY`	Software ou hardware	Mede a força da gravidade em m/s² que é aplicada a um dispositivo nos três eixos físicos (x, y, z).	Detecção de movimento (agitação, inclinação etc.).
`TYPE_GYROSCOPE`	Hardware	Mede a taxa de rotação de um dispositivo em rad/s em torno de cada um dos três eixos físicos (x, y, z).	Detecção de rotação (giro, volta etc.).
`TYPE_LIGHT`	Hardware	Mede o nível de luz ambiente (iluminação) em lx.	Controle do brilho da tela.
`TYPE_LINEAR_ACCELERATION`	Software ou hardware	Mede a força de aceleração em m/s² que é aplicada a um dispositivo nos três eixos físicos (x, y, z), exceto a força da gravidade.	Monitoramento da aceleração em um único eixo.
`TYPE_MAGNETIC_FIELD`	Hardware	Mede o campo geomagnético do ambiente para os três eixos físicos (x, y, z) em μT.	Criação de uma bússola.
`TYPE_ORIENTATION`	Software	Mede os graus de rotação que um dispositivo faz em torno dos três eixos físicos (x, y, z). A partir do nível 3 da API, é possível encontrar as matrizes de inclinação e de rotação de um dispositivo usando o sensor de gravidade e o sensor de campo geomagnético combinados com o método `getRotationMatrix()`.	Determinação da posição do dispositivo.
`TYPE_PRESSURE`	Hardware	Mede a pressão do ar ambiente em hPa ou mbar.	Monitoramento das mudanças na pressão do ar.
`TYPE_PROXIMITY`	Hardware	Mede a proximidade de um objeto em cm com relação à tela de um dispositivo. Em geral, esse sensor é usado para determinar se um dispositivo móvel está próximo do ouvido de uma pessoa.	Posição do smartphone durante uma chamada.
`TYPE_RELATIVE_HUMIDITY`	Hardware	Mede a umidade relativa do ar em porcentagem (%).	Monitoramento de ponto de condensação, umidade absoluta e relativa.
`TYPE_ROTATION_VECTOR`	Software ou hardware	Mede a orientação de um dispositivo informando os três elementos do vetor de rotação do dispositivo.	Detecção de movimento e de rotação.
`TYPE_TEMPERATURE`	Hardware	Mede a temperatura do dispositivo em graus Celsius (°C). A implementação deste sensor varia de um dispositivo para outro, e ele foi substituído pelo sensor `TYPE_AMBIENT_TEMPERATURE` na API nível 14.	Monitoramento de temperaturas.

Framework de sensor

É possível acessar esses sensores e coletar dados brutos por meio do framework de sensor do Android. Esse framework faz parte do pacote android.hardware e inclui as seguintes classes e interfaces:

SensorManager: Use esta classe para criar uma instância do serviço do sensor. Ela oferece vários métodos para acessar e listar sensores, registrar e cancelar o registro de listeners de eventos do sensor e coletar informações de orientação. Essa classe também disponibiliza diversas constantes usadas para informar a precisão do sensor, definir taxas de aquisição de dados e calibrar os sensores.
Sensor: Use esta classe para criar uma instância de um sensor específico. Ela oferece vários métodos que permitem determinar os recursos de um sensor.
SensorEvent: O sistema usa esta classe para criar um objeto de evento do sensor, que disponibiliza informações relacionadas a esse tipo de evento. Um objeto de evento do sensor inclui as seguintes informações: dados brutos do sensor, tipo de sensor que gerou o evento, precisão dos dados e carimbo de data/hora do evento.
SensorEventListener: Use esta interface para criar dois métodos de callback que receberão notificações (eventos de sensor) quando os valores do sensor ou a precisão dele mudarem.

Em um aplicativo normal, essas APIs relacionadas ao sensor são usadas para realizar duas tarefas básicas:

Identificar sensores e recursos do sensor
Identificar sensores e recursos do sensor durante a execução é útil quando seu aplicativo tem funções que dependem de tipos de sensor ou recursos relacionados específicos. Por exemplo, quando você quer identificar todos os sensores presentes em um dispositivo e desativar qualquer recurso do aplicativo que dependa de sensores ausentes. De maneira semelhante, essa tarefa também é usada para identificar todos os sensores de um determinado tipo para escolher a implementação que oferece o desempenho ideal para seu aplicativo.
Monitorar eventos do sensor
Para coletar dados brutos, você monitora os eventos do sensor. Esse tipo de evento ocorre sempre que um sensor detecta uma mudança nos parâmetros que está medindo. Um evento do sensor oferece quatro informações: nome do sensor que acionou o evento, carimbo de data/hora do evento, precisão do evento e os dados brutos que acionaram o evento.

Disponibilidade do sensor

Embora a disponibilidade do sensor varie de acordo com o dispositivo, ela também pode variar entre as versões do Android. Isso ocorre porque os sensores do Android foram introduzidos ao longo de várias versões da plataforma. Por exemplo, muitos sensores foram introduzidos no Android 1.5 (API nível 3), mas alguns não foram implementados e não estavam disponíveis para uso até o Android 2.3 (API nível 9). Da mesma forma, vários sensores foram introduzidos no Android 2.3 (API nível 9) e no Android 4.0 (API nível 14). Dois sensores tiveram o uso suspenso e foram substituídos por outros novos e melhores.

A Tabela 2 resume a disponibilidade de cada sensor de acordo com a plataforma. Apenas as quatro plataformas que passaram por mudanças de sensores foram listadas. Se estiverem presentes em um dispositivo, os sensores listados como obsoletos continuarão disponíveis nas plataformas subsequentes, o que está de acordo com a política de compatibilidade com versões futuras do Android.

Tabela 2. Disponibilidade do sensor por plataforma.

Sensor	Android 4.0 (API nível 14)	Android 2.3 (API nível 9)	Android 2.2 (API nível 8)	Android 1.5 (API nível 3)
`TYPE_ACCELEROMETER`	Sim	Sim	Sim	Sim
`TYPE_AMBIENT_TEMPERATURE`	Sim	n/d	n/d	n/d
`TYPE_GRAVITY`	Sim	Sim	n/d	n/d
`TYPE_GYROSCOPE`	Sim	Sim	n/d¹	n/d¹
`TYPE_LIGHT`	Sim	Sim	Sim	Sim
`TYPE_LINEAR_ACCELERATION`	Sim	Sim	n/d	n/d
`TYPE_MAGNETIC_FIELD`	Sim	Sim	Sim	Sim
`TYPE_ORIENTATION`	Sim²	Sim²	Sim²	Sim
`TYPE_PRESSURE`	Sim	Sim	n/d¹	n/d¹
`TYPE_PROXIMITY`	Sim	Sim	Sim	Sim
`TYPE_RELATIVE_HUMIDITY`	Sim	n/d	n/d	n/d
`TYPE_ROTATION_VECTOR`	Sim	Sim	n/d	n/d
`TYPE_TEMPERATURE`	Sim²	Sim	Sim	Sim

¹ Esse tipo de sensor foi adicionado no Android 1.5 (API nível 3), mas não estava disponível para uso até o Android 2.3 (API nível 9).

² Esse sensor está disponível, mas teve o uso suspenso.

Identificar sensores e recursos do sensor

O framework de sensor do Android oferece vários métodos que facilitam determinar durante a execução quais sensores estão em um dispositivo. A API também disponibiliza métodos que permitem determinar os recursos de cada sensor, como alcance máximo, resolução e requisitos de energia.

Para identificar os sensores presentes em um dispositivo, primeiro é preciso acessar uma referência ao serviço do sensor. Para fazer isso, crie uma instância da classe SensorManager chamando o método getSystemService() e passando o argumento SENSOR_SERVICE. Por exemplo:

Kotlin

    private lateinit var sensorManager: SensorManager
    ...
    sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager

Java

    private SensorManager sensorManager;
    ...
    sensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);

Em seguida, é possível acessar uma lista de cada sensor no dispositivo chamando o método getSensorList() e usando a constante TYPE_ALL. Por exemplo:

Kotlin

    val deviceSensors: List<Sensor> = sensorManager.getSensorList(Sensor.TYPE_ALL)

Java

    List<Sensor> deviceSensors = sensorManager.getSensorList(Sensor.TYPE_ALL);

Se você quiser listar todos os sensores de um determinado tipo, poderá usar outra constante em vez de TYPE_ALL, como TYPE_GYROSCOPE, TYPE_LINEAR_ACCELERATION ou TYPE_GRAVITY.

Você também pode determinar se um tipo específico de sensor existe em um dispositivo usando o método getDefaultSensor() e passando a constante de tipo para um sensor específico. Se um dispositivo tiver mais de um sensor de um determinado tipo, um dos sensores precisará ser designado como padrão. Se não existir um padrão para um determinado tipo de sensor, a chamada do método retornará nulo, o que significa que o dispositivo não tem esse tipo de sensor. Por exemplo, o código a seguir verifica se há um magnetômetro em um dispositivo:

Kotlin

    private lateinit var sensorManager: SensorManager
    ...
    sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
    if (sensorManager.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD) != null) {
        // Success! There's a magnetometer.
    } else {
        // Failure! No magnetometer.
    }

Java

    private SensorManager sensorManager;
    ...
    sensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
    if (sensorManager.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD) != null){
        // Success! There's a magnetometer.
    } else {
        // Failure! No magnetometer.
    }

Observação: para que os dispositivos tenham acesso a uma grande variedade de configurações de sensores, o Android não requer que fabricantes criem nenhum tipo específico de sensor.

Além de listar os sensores presentes em um dispositivo, você pode usar os métodos públicos da classe Sensor para determinar os recursos e atributos de sensores individuais. Isso será útil se você quiser que o aplicativo se comporte de outra forma com base nos sensores ou recursos do sensor disponíveis no dispositivo. Por exemplo, use os métodos getResolution() e getMaximumRange() para acessar a resolução de um sensor e o intervalo máximo de medição. Você também pode usar o método getPower() para saber os requisitos de energia de um sensor.

Dois dos métodos públicos são particularmente úteis para otimizar o aplicativo para diferentes sensores do fabricante ou versões distintas de um sensor. Por exemplo, se o aplicativo precisar monitorar gestos do usuário, como inclinação e agitação, crie um conjunto de regras de filtragem de dados e otimizações para dispositivos mais recentes que têm sensor de gravidade de um fornecedor específico e outro conjunto de regras de filtragem de dados e otimizações para dispositivos que não têm sensor de gravidade, apenas acelerômetro. Veja na amostra de código a seguir como usar os métodos getVendor() e getVersion() para fazer isso. Nessa amostra, estamos procurando por um sensor de gravidade que liste a Google LLC como fornecedor e tenha o número de versão 3. Se esse sensor específico não estiver presente no dispositivo, tentaremos usar o acelerômetro.

Kotlin

    private lateinit var sensorManager: SensorManager
    private var mSensor: Sensor? = null

    ...

    sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager

    if (sensorManager.getDefaultSensor(Sensor.TYPE_GRAVITY) != null) {
        val gravSensors: List<Sensor> = sensorManager.getSensorList(Sensor.TYPE_GRAVITY)
        // Use the version 3 gravity sensor.
        mSensor = gravSensors.firstOrNull { it.vendor.contains("Google LLC") && it.version == 3 }
    }
    if (mSensor == null) {
        // Use the accelerometer.
        mSensor = if (sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER) != null) {
            sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
        } else {
            // Sorry, there are no accelerometers on your device.
            // You can't play this game.
            null
        }
    }

Java

    private SensorManager sensorManager;
    private Sensor mSensor;

    ...

    sensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
    mSensor = null;

    if (sensorManager.getDefaultSensor(Sensor.TYPE_GRAVITY) != null){
        List<Sensor> gravSensors = sensorManager.getSensorList(Sensor.TYPE_GRAVITY);
        for(int i=0; i<gravSensors.size(); i++) {
            if ((gravSensors.get(i).getVendor().contains("Google LLC")) &&
               (gravSensors.get(i).getVersion() == 3)){
                // Use the version 3 gravity sensor.
                mSensor = gravSensors.get(i);
            }
        }
    }
    if (mSensor == null){
        // Use the accelerometer.
        if (sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER) != null){
            mSensor = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
        } else{
            // Sorry, there are no accelerometers on your device.
            // You can't play this game.
        }
    }

Outro método útil é o getMinDelay(), que retorna o intervalo de tempo mínimo (em microssegundos) que um sensor pode usar para detectar dados. Qualquer sensor que retorne um valor diferente de zero para o método getMinDelay() é um sensor de streaming. Sensores de streaming detectam dados em intervalos regulares e foram introduzidos no Android 2.3 (API nível 9). Se um sensor retorna zero quando você chama o método getMinDelay(), significa que o sensor não é de streaming, já que ele só informa dados quando há uma mudança nos parâmetros que está detectando.

O método getMinDelay() é útil porque permite determinar a taxa de velocidade máxima a que um sensor pode coletar dados. Se determinados recursos do seu aplicativo exigirem taxas altas de aquisição de dados ou um sensor de streaming, você poderá usar esse método para determinar se um sensor atende a esses requisitos e ativar ou desativar os recursos relevantes no aplicativo.

Cuidado: a taxa máxima de aquisição de dados de um sensor não é necessariamente a taxa em que o framework de sensor entrega dados para o aplicativo. O framework informa os dados por meio de eventos do sensor, e vários fatores influenciam a taxa em que o aplicativo recebe esses eventos. Para saber mais, consulte Monitorar eventos do sensor.

Monitorar eventos do sensor

Para monitorar os dados brutos do sensor, é preciso implementar dois métodos de callback que são expostos por meio da interface SensorEventListener: onAccuracyChanged() e onSensorChanged(). O sistema Android chama esses métodos sempre que ocorre o seguinte:

A precisão de um sensor muda.
Nesse caso, o sistema invoca o método onAccuracyChanged(), fornecendo uma referência ao objeto Sensor que mudou e a nova precisão do sensor. A precisão é representada por uma de quatro constantes de estado: SENSOR_STATUS_ACCURACY_LOW, SENSOR_STATUS_ACCURACY_MEDIUM, SENSOR_STATUS_ACCURACY_HIGH ou SENSOR_STATUS_UNRELIABLE.
Um sensor informa um novo valor.
Nesse caso, o sistema invoca o método onSensorChanged(), fornecendo um objeto SensorEvent. Um objeto SensorEvent contém informações sobre os novos dados do sensor, incluindo: precisão dos dados, sensor que gerou os dados, carimbo de data/hora em que os dados foram gerados e novos dados registrados pelo sensor.

O código a seguir mostra como usar o método onSensorChanged() para monitorar dados do sensor de luz. Este exemplo mostra os dados brutos do sensor em um TextView que é definido no arquivo main.xml como sensor_data.

Kotlin

    class SensorActivity : Activity(), SensorEventListener {
        private lateinit var sensorManager: SensorManager
        private var mLight: Sensor? = null

        public override fun onCreate(savedInstanceState: Bundle?) {
            super.onCreate(savedInstanceState)
            setContentView(R.layout.main)

            sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
            mLight = sensorManager.getDefaultSensor(Sensor.TYPE_LIGHT)
        }

        override fun onAccuracyChanged(sensor: Sensor, accuracy: Int) {
            // Do something here if sensor accuracy changes.
        }

        override fun onSensorChanged(event: SensorEvent) {
            // The light sensor returns a single value.
            // Many sensors return 3 values, one for each axis.
            val lux = event.values[0]
            // Do something with this sensor value.
        }

        override fun onResume() {
            super.onResume()
            mLight?.also { light ->
                sensorManager.registerListener(this, light, SensorManager.SENSOR_DELAY_NORMAL)
            }
        }

        override fun onPause() {
            super.onPause()
            sensorManager.unregisterListener(this)
        }
    }

Java

    public class SensorActivity extends Activity implements SensorEventListener {
        private SensorManager sensorManager;
        private Sensor mLight;

        @Override
        public final void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.main);

            sensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
            mLight = sensorManager.getDefaultSensor(Sensor.TYPE_LIGHT);
        }

        @Override
        public final void onAccuracyChanged(Sensor sensor, int accuracy) {
            // Do something here if sensor accuracy changes.
        }

        @Override
        public final void onSensorChanged(SensorEvent event) {
            // The light sensor returns a single value.
            // Many sensors return 3 values, one for each axis.
            float lux = event.values[0];
            // Do something with this sensor value.
        }

        @Override
        protected void onResume() {
            super.onResume();
            sensorManager.registerListener(this, mLight, SensorManager.SENSOR_DELAY_NORMAL);
        }

        @Override
        protected void onPause() {
            super.onPause();
            sensorManager.unregisterListener(this);
        }
    }

Nesse exemplo, o atraso de dados padrão (SENSOR_DELAY_NORMAL) é especificado quando o método registerListener() é invocado. O atraso de dados (ou taxa de amostragem) controla o intervalo em que os eventos do sensor são enviados para o aplicativo por meio do método de callback onSensorChanged(). O atraso de dados padrão é adequado para monitorar mudanças comuns de orientação da tela e usa o valor de 200.000 microssegundos. Você pode especificar outros atrasos de dados, como SENSOR_DELAY_GAME (atraso de 20.000 microssegundos), SENSOR_DELAY_UI (atraso de 60.000 microssegundos) ou SENSOR_DELAY_FASTEST (atraso de 0 microssegundo). A partir do Android 3.0 (API nível 11), também é possível especificar o atraso como um valor absoluto (em microssegundos).

O atraso especificado é apenas uma sugestão. O sistema Android e outros aplicativos podem mudá-lo. Especifique o maior atraso possível, já que o sistema normalmente usa um atraso menor do que o especificado, ou seja, escolha a taxa de amostragem mais lenta que ainda atenda às necessidades do aplicativo. O uso de um atraso maior impõe uma carga menor no processador e, portanto, consome menos energia.

Não existe um método público para determinar a taxa em que o framework de sensor envia eventos para o aplicativo. No entanto, você pode usar os carimbos de data/hora associados a cada evento para calcular a taxa de amostragem ao longo de vários eventos. Não deve ser necessário mudar a taxa de amostragem (atraso) depois de defini-la. Se por algum motivo você precisar mudar o atraso, será necessário cancelar o registro do listener do sensor e registrá-lo novamente.

Também é importante observar que esse exemplo usa os métodos de callback onResume() e onPause() para registrar e cancelar o registro do listener de eventos do sensor. Desative sempre os sensores desnecessários, principalmente quando a atividade estiver pausada. Caso contrário, a bateria poderá acabar em poucas horas, uma vez que alguns sensores têm requisitos de energia significativos e podem consumir a bateria rapidamente. O sistema não desativará os sensores automaticamente quando a tela for desligada.

Gerenciar diferentes configurações de sensores

O Android não especifica uma configuração de sensor padrão para dispositivos, o que significa que os fabricantes podem incorporar a configuração que quiserem nos dispositivos Android. Dessa forma, os dispositivos podem incluir diversos sensores em uma grande variedade de configurações. Se seu aplicativo depende de um tipo específico de sensor, é preciso verificar se o sensor está presente no dispositivo para que o app seja executado.

Há duas opções para verificar se um determinado sensor está presente em um dispositivo:

Detectar os sensores durante a execução e ativar ou desativar os recursos do aplicativo conforme apropriado.
Usar os filtros do Google Play para segmentar os dispositivos que têm configurações de sensor específicas.

Cada opção é discutida nas seções a seguir.

Detectar sensores durante a execução

Se seu aplicativo usar um tipo específico de sensor, mas não depender dele, você poderá usar o framework para detectar o sensor durante a execução e desativar ou ativar recursos do aplicativo conforme apropriado. Por exemplo, um aplicativo de navegação pode usar o sensor de temperatura, de pressão, de GPS e de campo geomagnético para exibir temperatura, pressão barométrica, localização e orientação da bússola. Se o dispositivo não tiver um sensor de pressão, você poderá usar o framework para detectar a ausência do sensor de pressão durante a execução e desativar a parte da IU do aplicativo que exibe a pressão. Por exemplo, o código a seguir verifica se há um sensor de pressão em um dispositivo:

Kotlin

    private lateinit var sensorManager: SensorManager
    ...
    sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager

    if (sensorManager.getDefaultSensor(Sensor.TYPE_PRESSURE) != null) {
        // Success! There's a pressure sensor.
    } else {
        // Failure! No pressure sensor.
    }

Java

    private SensorManager sensorManager;
    ...
    sensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
    if (sensorManager.getDefaultSensor(Sensor.TYPE_PRESSURE) != null){
        // Success! There's a pressure sensor.
    } else {
        // Failure! No pressure sensor.
    }

Usar os filtros do Google Play para segmentar configurações de sensor específicas

Se você publicar o aplicativo no Google Play, poderá usar o elemento <uses-feature> no arquivo de manifesto para filtrar seu aplicativo dos dispositivos que não têm a configuração de sensor apropriada. O elemento <uses-feature> tem vários descritores de hardware que permitem filtrar aplicativos com base na presença de sensores específicos. Os sensores que você pode listar incluem: acelerômetro, barômetro, bússola (campo geomagnético), giroscópio, luz e proximidade. Veja a seguir um exemplo de entrada de manifesto que filtra apps que não têm um acelerômetro:

    <uses-feature android:name="android.hardware.sensor.accelerometer"
                  android:required="true" />

Se você adicionar esse elemento e o descritor ao manifesto do aplicativo, os usuários só verão seu aplicativo no Google Play se o dispositivo tiver um acelerômetro.

Defina o descritor como android:required="true" apenas se o aplicativo depende inteiramente de um sensor específico. Se seu aplicativo usa um sensor para algum recurso, mas ainda funciona sem o sensor, liste o sensor no elemento <uses-feature>, mas defina o descritor como android:required="false". Isso ajuda a garantir que os dispositivos possam instalar seu app mesmo que não tenham o sensor específico. Essa também é uma prática recomendada de gerenciamento de projetos que ajuda a acompanhar os recursos que seu aplicativo usa. Se seu aplicativo usa um sensor específico, mas ainda funciona sem ele, detecte o sensor durante a execução e desative ou ative os recursos do aplicativo conforme apropriado.

Sistema de coordenadas do sensor

Em geral, o framework do sensor usa um sistema de coordenadas padrão de três eixos para expressar valores de dados. Para a maioria dos sensores, o sistema de coordenadas é definido em relação à tela do dispositivo quando o aparelho é mantido na orientação padrão (consulte a Figura 1). Quando um dispositivo é mantido na orientação padrão, o eixo X é horizontal e aponta para a direita, o eixo Y é vertical e aponta para cima, e o eixo Z aponta para fora da tela. Nesse sistema, as coordenadas atrás da tela têm valores negativos de Z. Esse sistema de coordenadas é usado pelos seguintes sensores:

Figura 1. Sistema de coordenadas (de um dispositivo) usado pela API Sensor.

A característica mais importante a compreender sobre esse sistema de coordenadas é que os eixos não são trocados quando a orientação da tela do dispositivo muda, ou seja, o sistema de coordenadas do sensor nunca muda conforme o dispositivo é movido. Esse comportamento é igual ao do sistema de coordenadas do OpenGL.

Também é preciso entender que seu aplicativo não pode presumir que a orientação natural (padrão) do dispositivo é a retrato. A orientação natural de muitos tablets é a paisagem. E o sistema de coordenadas do sensor sempre se baseia na orientação natural do dispositivo.

Por fim, se seu aplicativo relacionar os dados do sensor à exibição na tela, você precisará usar o método getRotation() para determinar a rotação da tela, e o método remapCoordinateSystem() para mapear coordenadas do sensor em coordenadas da tela. Essa ação é necessária mesmo que o manifesto especifique exibição exclusiva no modo retrato.

Observação: alguns sensores e métodos usam um sistema de coordenadas relacionado ao referencial mundial, não ao referencial do dispositivo. Esses sensores e métodos retornam dados que representam o movimento ou a posição do dispositivo em relação à Terra. Para saber mais, consulte os métodos getOrientation() e getRotationMatrix(), bem como Sensor de orientação e Sensor vetorial de rotação.

Práticas recomendadas para acessar e usar sensores

Ao criar a implementação do sensor, siga as diretrizes abordadas nesta seção. Elas são práticas recomendadas para quem usa o framework do sensor para acessar sensores e coletar dados.

Coletar dados do sensor apenas no primeiro plano

Em dispositivos com o Android 9 (API nível 28) ou versões posteriores, os apps executados em segundo plano têm as seguintes restrições:

Os sensores que usam o modo de relatório contínuo, como acelerômetros e giroscópios, não recebem eventos.
Os sensores que usam os modos de relatório on-change ou one-shot não recebem eventos.

Com essas restrições, é melhor detectar eventos de sensor quando o app está no primeiro plano ou como parte de um serviço de primeiro plano.

Cancelar o registro de listeners de sensor

Cancele o registro do listener de um sensor quando terminar de usar o sensor ou quando a atividade for pausada. Se um listener de sensor for registrado e a atividade dele for pausada, o sensor continuará coletando dados e usando recursos da bateria, a menos que você cancele o registro do sensor. O código a seguir mostra como usar o método onPause() para cancelar o registro de um listener:

Kotlin

    private lateinit var sensorManager: SensorManager
    ...
    override fun onPause() {
        super.onPause()
        sensorManager.unregisterListener(this)
    }

Java

    private SensorManager sensorManager;
    ...
    @Override
    protected void onPause() {
        super.onPause();
        sensorManager.unregisterListener(this);
    }

Para mais informações, consulte unregisterListener(SensorEventListener).

Testar com o Android Emulator

O Android Emulator inclui um conjunto de controles virtuais de sensor que permitem testar sensores como acelerômetro, temperatura ambiente, magnetômetro, proximidade, luz e muito mais.

O emulador usa uma conexão com um dispositivo Android que executando o app SdkControllerSensor. Esse app está disponível apenas para dispositivos com o Android 4.0 (API nível 14) ou versões posteriores. Se o dispositivo estiver executando o Android 4.0, ele precisará ter a Revisão 2 instalada. O app SdkControllerSensor monitora mudanças nos sensores do dispositivo e as transmite ao emulador. Em seguida, o emulador é transformado com base nos novos valores recebidos dos sensores do dispositivo.

Veja o código-fonte do app SdkControllerSensor no seguinte local:

    $ your-android-sdk-directory/tools/apps/SdkController

Para transferir dados entre o dispositivo e o emulador, siga estas etapas:

Verifique se a depuração USB está ativada no dispositivo.
Conecte o dispositivo à máquina de desenvolvimento por meio de um cabo USB.
Abra o app SdkControllerSensor no dispositivo.
No app, selecione os sensores que você quer emular.
Execute este comando do adb:

    $ adb forward tcp:1968 tcp:1968

Inicie o emulador. Agora você deve conseguir aplicar transformações ao emulador movendo o dispositivo.

Observação: se os movimentos feitos com o dispositivo físico não transformarem o emulador, execute o comando do adb da etapa 5 novamente.

Para saber mais, consulte o guia do Android Emulator.

Não bloqueie o método onSensorChanged()

Os dados do sensor podem mudar a uma taxa alta, o que significa que o sistema pode chamar o método onSensorChanged(SensorEvent) com bastante frequência. Trabalhe o mínimo possível dentro do método onSensorChanged(SensorEvent) para não bloqueá-lo. Se seu aplicativo exigir que você faça alguma filtragem de dados ou redução dos dados do sensor, faça isso fora do método onSensorChanged(SensorEvent).

Evite usar métodos ou tipos de sensores obsoletos

Vários métodos e constantes tiveram o uso suspenso. Especificamente, o tipo de sensor TYPE_ORIENTATION teve o uso suspenso. Para coletar dados de orientação, use o método getOrientation(). Da mesma forma, o tipo de sensor TYPE_TEMPERATURE teve o uso suspenso. Use o tipo de sensor TYPE_AMBIENT_TEMPERATURE em dispositivos com o Android 4.0.

Verifique os sensores antes de usá-los

Sempre verifique se o sensor existe no dispositivo antes de tentar coletar dados dele. Não presuma a existência de um sensor apenas por ele ser usado com frequência. Os fabricantes de dispositivos não têm a obrigação disponibilizar qualquer sensor específico.

Tenha cuidado ao escolher os atrasos do sensor

Ao registrar um sensor com o método registerListener(), escolha uma taxa de exibição adequada para seu aplicativo ou caso de uso. Os sensores podem fornecer dados a taxas muito altas. Permitir que o sistema envie dados extras desnecessários desperdiça os recursos do sistema e consome energia da bateria.

Sensores de movimento