Sensoren auf Android: Überblick für die Praxis

Moderne Smartphones stecken voller Hardware-Sensoren, die Bewegung, Lage, Luftdruck, Temperatur und Licht messen. Als Android-Entwickler hast du über das Sensor-Framework Zugriff auf all diese Daten – doch mit diesem Zugriff kommt Verantwortung: Falsch eingesetzt, leeren Sensoren den Akku schneller als fast jede andere App-Aktivität und öffnen Datenschutzlücken, die Nutzerinnen und Nutzer nicht erwarten.

Was ist das?

Das Android Sensor-Framework ist eine SDK-Schicht, die deiner App einheitlichen Zugang zu allen physikalischen und virtuellen Sensoren eines Geräts bietet. Physikalische Sensoren sind direkte Hardware-Komponenten – etwa der Beschleunigungsmesser (Accelerometer) oder das Gyroskop. Virtuelle Sensoren kombinieren mehrere physikalische Quellen zu einem neuen Datenstrom; der Rotationsvektor fusioniert intern Beschleunigungsmesser, Gyroskop und Magnetometer zu einer einheitlichen Lageangabe.

Das Framework teilt Sensoren in drei Kategorien ein:

• Bewegungssensoren (Motion): Accelerometer, Gyroskop, Step Detector. Sie messen Beschleunigung und Drehung und eignen sich für Fitness-Tracking, Spielsteuerung und Handgesten.
• Positionssensoren (Position): Magnetometer, Näherungssensor. Sie bestimmen die Ausrichtung des Geräts im Raum oder erkennen, ob das Gerät ans Ohr gehalten wird.
• Umgebungssensoren (Environment): Barometer, Thermometer, Lichtsensor, Feuchtigkeitssensor. Sie messen physikalische Größen der Umgebung, unabhängig vom Gerät selbst.

Diese Kategorisierung hilft dabei, schnell einzuschätzen, welcher Sensor für welchen Anwendungsfall sinnvoll ist – und welche Geräte ihn überhaupt mitbringen.

Wie funktioniert es?

Der Einstiegspunkt ist der SensorManager, den du über getSystemService erhältst. Damit kannst du verfügbare Sensoren auflisten, einen konkreten Sensor-Handle holen und einen SensorEventListener registrieren, der bei jedem neuen Messwert aufgerufen wird.

class MovementActivity : AppCompatActivity(), SensorEventListener {

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

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        sensorManager = getSystemService(SENSOR_SERVICE) as SensorManager
        accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
    }

    override fun onResume() {
        super.onResume()
        accelerometer?.let {
            sensorManager.registerListener(this, it, SensorManager.SENSOR_DELAY_NORMAL)
        }
    }

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

    override fun onSensorChanged(event: SensorEvent) {
        val x = event.values[0]
        val y = event.values[1]
        val z = event.values[2]
        // Verarbeite Beschleunigungsdaten in m/s²
    }

    override fun onAccuracyChanged(sensor: Sensor, accuracy: Int) = Unit
}

Beachte das Muster: Registrieren in onResume, Deregistrieren in onPause. Das ist keine Konvention, sondern ein hartes Gebot – wird der Listener nicht deregistriert, läuft er weiter, wenn die Activity nicht mehr sichtbar ist, und verbraucht Akku und CPU ohne jeden Nutzen.

Abtastraten

Android bietet vier vordefinierte Verzögerungsstufen: SENSOR_DELAY_NORMAL (~200 ms), SENSOR_DELAY_UI (~60 ms), SENSOR_DELAY_GAME (~20 ms) und SENSOR_DELAY_FASTEST (~0 ms). Diese Werte sind Richtwerte – das Betriebssystem liefert Daten mit mindestens dieser Rate, kann aber auch häufiger liefern. Wähle immer die langsamste Rate, die für deinen Anwendungsfall noch ausreicht.

In der Praxis

Verfügbarkeit prüfen

Nicht jedes Android-Gerät besitzt jeden Sensor. Günstige Einstiegsgeräte verzichten häufig auf Barometer oder Gyroskop. Prüfe daher immer, ob der Sensor vorhanden ist:

val hasBaro = sensorManager.getDefaultSensor(Sensor.TYPE_PRESSURE) != null
if (!hasBaro) {
    // Fallback-Logik oder Feature für dieses Gerät deaktivieren
}

Wenn deine App einen bestimmten Sensor zwingend benötigt, deklariere das im Manifest:

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

Dadurch schließt der Play Store Geräte ohne diesen Sensor automatisch aus dem Angebot aus – eine einfache Maßnahme, die Runtime-Crashes durch null-Sensoren verhindert.

Rauschen glätten

Sensor-Rohdaten schwanken stark. Ein einfacher Tiefpassfilter reicht oft aus, um Messrauschen deutlich zu reduzieren:

private val alpha = 0.8f
private val smoothed = FloatArray(3)

fun lowPass(input: FloatArray): FloatArray {
    for (i in input.indices) {
        smoothed[i] = alpha * smoothed[i] + (1 - alpha) * input[i]
    }
    return smoothed
}

Typische Stolperfalle: Ein zu hoher Alpha-Wert (nahe 1,0) macht den Filter träge und verpasst echte schnelle Bewegungen; ein zu niedriger Wert (nahe 0,0) filtert kaum etwas und gibt das Rauschen unverändert weiter. Experimentiere mit Werten zwischen 0,7 und 0,9 und validiere mit echten Gerätebewegungen.

Datenschutz und Berechtigungen

Bewegungs- und Positionssensoren erfordern ab Android 12 (API 31) bei bestimmten Nutzungsszenarien ausdrückliche Berechtigungen. Das BODY_SENSORS-Permission ist für Herzfrequenzsensoren nötig. Hohe Abtastraten des Gyroskops können theoretisch zur Nutzeridentifikation missbraucht werden – Android schränkt dies seit API 31 für Apps im Hintergrund ein. Nutze Sensordaten ausschließlich für den in der Datenschutzerklärung deklarierten Zweck, und beachte die Play-Store-Richtlinien deiner App-Kategorie.

Fazit

Das Android Sensor-Framework ist mächtig und vergleichsweise einfach zu bedienen, bestraft nachlässige Integration aber mit Akkuproblemen und Datenschutzrisiken. Das wichtigste Prinzip ist Zurückhaltung: Registriere nur die Sensoren, die du wirklich brauchst, mit der langsamsten ausreichenden Rate, und nur so lange die App im Vordergrund ist. Schreibe jetzt eine kleine Test-App, die den Accelerometer ausliest, einen Tiefpassfilter anwendet und die gefilterten Werte in einer Compose-UI anzeigt – das festigt das Registrierungs-Muster, den Umgang mit Rauschen und die Lifecycle-Konvention in einer einzigen, überprüfbaren Übung.