How a step-counter tells walking from a boda ride — using Android Health Connect and the Activity Recognition API to subtract vehicle movement on-device, the way we built Stride.
Every team step-challenge runs into the same credibility problem: someone "wins" by leaving their phone in a boda. A pedometer reads the vibration of a vehicle on a rough road as walking, and a leaderboard built on that is one nobody believes twice. When we built Stride — a team step-challenge app now live on Google Play — the entire product rested on solving exactly this. Here is how.
A phone's step counter is an accelerometer with a rhythm detector on top. Walking has a signature rhythm — but so does a car on a murram road, or a boda over speed bumps. Naïve step apps count all of it. In a workplace challenge where there's bragging rights (or a prize) on the line, that's fatal: the leaderboard stops meaning anything the first time someone's commute out-walks the people who actually walked.
On modern Android, the right source of truth for step data is Health Connect — the platform layer that aggregates fitness data with the user's explicit permission. Instead of each app reinventing step counting, you request the READ_STEPS permission and read a clean daily total, with READ_DISTANCE and READ_EXERCISE for showing distance alongside it.
The key discipline: individual step records stay on the device. The app reads them locally and only ever sends a daily total to the server.
To tell walking from riding, Stride uses Google's Activity Recognition Transition API. It emits transitions — "entered vehicle", "exited vehicle", "started walking" — that let the app know, in the background, when the user is travelling rather than on foot. This is the same permission (ACTIVITY_RECOGNITION) a serious fitness app declares, and it must be justified to Play with a clear, specific reason.
Here's the part that makes the leaderboard trustworthy: the steps recorded during a "vehicle" window are subtracted on the device, before any total leaves the phone. The server never sees the inflated number and then corrects it — the correction happens first, locally. The user can see exactly what was removed and why, on the same screen as their total.
Two engineering consequences follow:
Doing the hard work on-device isn't just about accuracy — it's the privacy story too, and in a workplace app that story is what gets adoption. Stride can say, truthfully, that it sends one number a day: your steps. Not your location, not your heart rate, not a timeline. An employer running a group sees exactly what every member sees — names and step counts — and there's no hidden report anyone can pull. That honesty is only possible because the computation happens before the sync, not after.
It also sails through Play's health-app review: every permission maps to a feature, no movement data leaves the device, and the app makes no medical claims — it counts steps and ranks them, nothing more.
Why Health Connect instead of the raw step sensor? Health Connect gives a permissioned, aggregated, platform-maintained source of step data instead of each app reinventing (and mis-reading) raw sensor streams.
How does the app know I'm in a vehicle? Google's Activity Recognition Transition API reports when you enter and exit a vehicle; steps during that window are removed before syncing.
Does my employer see where I walked? No. Only a daily step total is sent — no location, no route, no timeline. That's a direct result of doing the vehicle subtraction on-device.
Can you build a fitness or health app for us? Yes — we build Android/iOS health apps on Expo with a Go backend, and we know what Play's health-app review requires.
Building a fitness, wellness or health app and want it to be both accurate and Play-approved? Request a quote — we've shipped it.