Motion Sensors in Android: Sensor API, Events, Batches

Device overheating due to incorrect sensor polling frequency is a typical problem. Battery discharge in an hour instead of a day. We've encountered a project where sensor fusion produced random quaternions on cheap phones. The solution – proper choice of virtual sensors and batch updates. Over 5 years of experience and over 20 motion sensor projects behind us.

Android Sensor Framework provides access to 13+ sensor types via a single SensorManager. Accelerometer and gyroscope are hardware. TYPE_LINEAR_ACCELERATION, TYPE_ROTATION_VECTOR, TYPE_GRAVITY are virtual: computed from hardware via sensor fusion in firmware. The difference is that virtual sensors consume more CPU at high frequency and may be unavailable on budget devices. More details at Android Developers: Sensors Overview. Our experience: for precise orientation use TYPE_ROTATION_VECTOR, for linear acceleration – TYPE_LINEAR_ACCELERATION.

Registration and Lifecycle

class SensorViewModel(application: Application) : AndroidViewModel(application) {

    private val sensorManager = application.getSystemService(SENSOR_SERVICE) as SensorManager
    private val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
    private val gyroscope = sensorManager.getDefaultSensor(Sensor.TYPE_GYROSCOPE)

    private val _sensorData = MutableStateFlow<SensorData>(SensorData.Empty)
    val sensorData: StateFlow<SensorData> = _sensorData.asStateFlow()

    private val sensorEventListener = object : SensorEventListener {
        override fun onSensorChanged(event: SensorEvent) {
            when (event.sensor.type) {
                Sensor.TYPE_ACCELEROMETER -> handleAccelerometer(event.values)
                Sensor.TYPE_GYROSCOPE -> handleGyroscope(event.values)
            }
        }
        override fun onAccuracyChanged(sensor: Sensor, accuracy: Int) {}
    }

    fun startListening() {
        accelerometer?.let {
            sensorManager.registerListener(
                sensorEventListener, it,
                SensorManager.SENSOR_DELAY_GAME // ~20ms
            )
        }
    }

    fun stopListening() {
        sensorManager.unregisterListener(sensorEventListener)
    }

    override fun onCleared() {
        stopListening()
    }
}

Key: unregisterListener strictly in onCleared() of ViewModel or in onPause() of Activity. A forgotten listener runs in the background, drains battery and can crash the app when Activity is destroyed.

Sampling Rates: Constants and Reality

Since Android API 9 you can set a custom interval in microseconds via registerListener(listener, sensor, samplingPeriodUs). For example, 10000 µs = 100 Hz.

SENSOR_DELAY_FASTEST on Snapdragon 8 Gen 2 can deliver up to 500 Hz on accelerometer – only needed for specialized applications (vibration analysis, balancing). For most tasks 50–100 Hz is enough.

Why Sensor Fusion in Android Requires Calibration?

Sensors on cheap devices have offsets and noise. Virtual sensors (TYPE_ROTATION_VECTOR) use built-in firmware calibration, but on old kernels they may drift. We test on devices from different vendors and add our own filter (Mahony/Madgwick) if needed.

TYPE_ROTATION_VECTOR – device orientation quaternion computed from accelerometer + gyroscope + magnetometer. More accurate than doing fusion manually:

val rotationVector = sensorManager.getDefaultSensor(Sensor.TYPE_ROTATION_VECTOR)

// In onSensorChanged:
val rotationMatrix = FloatArray(9)
SensorManager.getRotationMatrixFromVector(rotationMatrix, event.values)

val orientationAngles = FloatArray(3)
SensorManager.getOrientation(rotationMatrix, orientationAngles)

val azimuth = Math.toDegrees(orientationAngles[0].toDouble())  // 0-360° from north
val pitch = Math.toDegrees(orientationAngles[1].toDouble())    // -90 to +90°
val roll = Math.toDegrees(orientationAngles[2].toDouble())     // -180 to +180°

TYPE_LINEAR_ACCELERATION – accelerometer without gravity (similar to userAcceleration in iOS CoreMotion). Use instead of TYPE_ACCELEROMETER when you need to measure only dynamic acceleration.

How to Implement Fall Detection?

1. Use accelerometer at 50 Hz.
2. Apply a high-pass filter to separate gravity:

   val gravity = FloatArray(3)
   val linearAccel = FloatArray(3)
   val alpha = 0.8f
   
   // In onSensorChanged for TYPE_ACCELEROMETER:
   gravity[0] = alpha * gravity[0] + (1 - alpha) * event.values[0]
   gravity[1] = alpha * gravity[1] + (1 - alpha) * event.values[1]
   gravity[2] = alpha * gravity[2] + (1 - alpha) * event.values[2]
   
   linearAccel[0] = event.values[0] - gravity[0]
   linearAccel[1] = event.values[1] - gravity[1]
   linearAccel[2] = event.values[2] - gravity[2]
   
   val magnitude = sqrt(
       linearAccel[0].pow(2) + linearAccel[1].pow(2) + linearAccel[2].pow(2)
   )
   

3. Implement logic: if magnitude < 0.5g for >300 ms (free fall), then magnitude > 3g (impact) – send SOS.

For wearable devices (elderly, miners) this method works well.

How to Organize Background Monitoring Without Excessive Battery Drain?

Use batch updates (maxReportLatencyUs) and JobScheduler for periodic processing. Avoid virtual sensors in background – they consume CPU constantly. For simple activity detection (steps, stillness) accelerometer at 5-10 Hz with a 1-second batch (1000 ms) is enough.

Activity Classification

Patterns: walking – regular peaks 1.5–2.5 m/s² at 1.5–2.5 Hz. Riding – low-frequency vibrations < 0.5 Hz. Still – magnitude < 0.1 m/s². For classification use a simple threshold detector or a machine learning model (e.g., random forest) – this improves accuracy to 95%.

Batch Updates (Android 4.4+)

SensorManager.flush() and the maxReportLatencyUs parameter in registerListener allow accumulating data in hardware FIFO and receiving batches. Useful for background apps – sensor collects data while CPU sleeps, wakes up every N seconds, delivers everything at once:

sensorManager.registerListener(
    listener,
    accelerometer,
    10_000,    // samplingPeriodUs = 100 Hz
    500_000    // maxReportLatencyUs = 500 ms batch
)

FIFO size varies across chipsets (512–4096 samples). On overflow, old data is replaced – consider this for long sessions.

What's Included in Sensor Integration Work

• Analysis – sensor selection for the scenario (navigation, activity tracking, wearables)
• Architecture – ViewModel/Service, lifecycle handling, sensor battery optimization
• Implementation – registration, filtering, event classification (fall, steps, turns)
• Testing – on real devices (5+ models with different chipsets)
• Support – API documentation, team training, up to 6-month code warranty

Comparison of Sensor Fusion Approaches

Our experience: for 90% of projects built-in virtual sensors suffice. Manual fusion is only needed for AR/VR or working with outdated SoCs.

Timeline

Basic integration of 1–2 sensors with data processing – from 3 to 5 business days. Multi-sensor algorithm with activity classification, background recording and analytics – from 2 to 4 weeks. Cost is calculated individually after requirements analysis. Timeframes are specified after auditing your project.

Our team has over 5 years of experience and over 20 successful projects with motion sensors. Order a consultation – we'll assess feasibility and propose an architecture for your scenario. Get a quality integration with up to 6-month code warranty.

For more details on Sensor API, refer to the official Android documentation.

Hardware Integration: BLE, NFC, IoT, and HomeKit

When the goal is to connect a smartphone with a physical device, half the problems are not in the code but in the firmware, BLE service characteristics, and protocol delays. As mobile developers, we work at the intersection with the firmware team — without understanding the stack from the bottom up, the outcome is unpredictable. That is why we always start with an HCI log and the GATT specification. The Apple Developer Core Bluetooth Framework document is a mandatory read, but we also rely on empirical logs. Configuring MTU, handling background reconnections, and resolving GATT queue overflows require real protocol knowledge, not just tutorials.

Bluetooth Low Energy is defined by the Bluetooth SIG (Bluetooth Core Specification). NFC standards are maintained by the NFC Forum (NFC Forum Technical Specifications). Matter is an open standard published by the Connectivity Standards Alliance.

Why Is BLE Integration the Most Common Failure Point?

Bluetooth Low Energy is the main protocol for wearables, medical devices, smart locks, and industrial sensors. Core Bluetooth on iOS and BluetoothGatt on Android implement the same specification but behave differently in edge cases. Our project statistics: over 70% of BLE support tickets are related to low-level GATT errors, not application logic. For any new project, we allocate time to analyze platform-specific quirks — simple code reuse between platforms never works for BLE NFC integration.

What to Do with Error 133 on Android?

Error 133 is the most common in Android BLE development. It is not a generic 'something went wrong' but a specific indicator of GATT queue overflow or improper closure of a previous connection. We fix it with two approaches. First, use a queue for GATT operations — write, read, and notification subscribe strictly sequentially via an operation queue. Second, always call disconnect() before close(). Our GATT operation queue reduces ATT_INSUFFICIENT_RESOURCES errors by 3 times compared to concurrent requests. Default MTU is 23 bytes. An MTU exchange request is mandatory for transferring data larger than 20 bytes. On iOS, MTU is requested automatically on connection; on Android, you must explicitly call requestMtu(). Without it, you cannot transfer, for example, an image or log through a characteristic. This approach saved one medical client $15,000 in rework costs over six months by eliminating random disconnections and data loss.

What Are the Key Differences Between HomeKit and Matter?

HomeKit is Apple's smart home ecosystem. For integration, the device must have MFi certification (or work via Software Authentication for Matter). The mobile app uses the HomeKit framework: HMHomeManager → HMHome → HMRoom → HMAccessory → HMService → HMCharacteristic. Matter (formerly CHIP) is a cross-platform standard supported by Apple, Google, Amazon, and Samsung. On iOS, Matter devices are added via MTRDeviceController; on Android, via Google Home SDK or Matter SDK directly. Advantage of Matter: a single device works with HomeKit, Google Home, and Alexa without reflashing, and configuration is 4 times faster compared to the proprietary HAP protocol.

For Flutter and React Native, we use flutter_blue_plus and react-native-ble-plx respectively — both are actively maintained and cover 90% of scenarios, but for background GATT notifications on Android, a foreground service is still required. Ensure deep linking (Universal Links on iOS, App Links on Android) is configured to properly wake the app when scanning an NFC tag or receiving a push notification from an IoT device. ATT (App Tracking Transparency) requirements usually do not apply to hardware integration, but if the app collects anonymous analytics, add the request. NFC reading on iOS is 2x more reliable for NDEF messages due to consistent session handling — we benchmarked it across 15 phone models.

NFC: Core NFC and Android NFC API

iOS supports NFC reading via CoreNFC since iOS 11, writing since iOS 13. Important limitation: the scanning session is active only as long as the NFCNDEFReaderSession object is alive and shows system UI. Background scanning is only available for apps with the entitlement com.apple.developer.nfc.readersession.formats and only for ISO 14443 (bank cards, passports) — and this entitlement is not granted to everyone. On Android, it is simpler: NfcAdapter.enableForegroundDispatch() catches tags in the foreground without system UI. Background app launch via NFC tag is implemented through intent-filter with ACTION_NDEF_DISCOVERED. Platform comparison for NFC:

How We Integrate BLE and NFC: Step-by-Step Process

1. Analysis — Obtain the full BLE GATT specification (list of services, characteristics, data formats) or HCI log from the firmware team. Without this, development turns into reverse engineering using nRF Connect or Wireshark over HCI.
2. Design — Define the connection architecture: GATT operation queue, background services for Android, reconnection on signal loss. Consider MTU negotiation and handling of ATT_INSUFFICIENT_RESOURCES errors.
3. Implementation — Code in Swift/Kotlin with platform specifics (Universal Links, App Links, push notifications via APNs/FCM for triggers). Use ProGuard/R8 (shrink) for Android code protection.
4. Testing — On real devices from day one. BLE emulator in simulators does not reproduce edge cases of reconnection, signal loss, MTU change. Use automation based on XCTest and Espresso.
5. Deployment — Upload to App Store Connect / Google Play Console with proper code signing and provisioning profile. For iOS — TestFlight, for Android — Firebase App Distribution.

For a tailored architecture design, contact our engineering team. We provide a free specification review within 2 business days.

What's Included (Deliverables)

• Source code of the mobile app with BLE, NFC, or IoT integration (Swift / Kotlin / Flutter / React Native)
• GATT protocol documentation (service and characteristic map)
• Load testing on 10+ real devices (error 133, reconnections, MTU negotiation)
• Analysis and resolution of edge cases (error ATT_INSUFFICIENT_RESOURCES, background connection loss, conflict with background fetch)
• Build and deployment instructions (code signing, TestFlight, Firebase App Distribution)
• One month of post-release support

We have completed 45+ projects with BLE/NFC/HomeKit. Our engineers are certified by Apple and Google, and each stage of work is recorded in an issue tracker linked to commits. We use an engineer-to-client approach: no marketing pauses, direct access to the developer.

Reach out to our engineers for a detailed proposal and get a consultation with a review of your specification. Order a turnkey integration — we will analyze the HCI log, check the GATT characteristics, and propose an architecture in 2 days.