Identify the API and data
Step detection, activity transitions, fitness records and health-platform data can have different access models. Read the documentation for the exact API rather than assuming that one “physical activity” switch covers them all.
The permission reference documents ACTIVITY_RECOGNITION and its platform availability. Supporting older Android releases may also involve a library-specific compatibility path; keep that separate from current platform declarations.
Ask when the feature starts
Use the runtime-permission flow for applicable versions. Explain the concrete purpose, such as counting steps for a user-enabled activity feature. Avoid requesting it on first launch when the person has not selected that feature.
User opens activity feature
→ check applicable permission state
→ explain the feature if access is missing
→ request through the platform flow
→ start only after a grant
→ provide a non-tracking state after denial
This is a behavior model, not a promise that a grant makes every sensor or provider available.
Handle missing and changed data
A device may lack the expected sensor, return no useful readings or restrict background execution. Treat “no data” separately from “permission denied.” Do not fabricate steps or activity states to fill gaps.
Recheck access when the protected operation begins and stop or degrade safely after revocation. Persist user intent separately from permission state so the app does not resume collection unexpectedly.
Test privacy and lifecycle behavior
Test denial, later grant, revocation, device restart and feature disablement. Confirm that collection stops when the feature is disabled and that logs or analytics do not retain unnecessary activity details.
Audit the declaration
APKLint's permission checker can help identify activity-recognition declarations and unexpected SDK additions. It cannot verify the sensor data stream or determine whether collection matches your privacy disclosures. Those conclusions need runtime evidence and a review of the exact feature and SDK configuration.
Distinguish a sensor reading from a daily total
Suppose a step-tracking feature displays a daily count. Before implementing the counter, inspect the chosen sensor or provider's semantics. A cumulative sensor reading and a sequence of individual step events need different aggregation logic. Permission approval does not convert either stream into a correctly bounded calendar-day total.
The motion sensor guide explains step-related sensors and access requirements. Confirm the sensor exists on the device and keep its data model separate from activity classification or a health-record API. Similar fitness features can rely on different capabilities.
Handle restart and missing readings without inventing activity
Use a controlled test session with a known approximate number of steps, then stop and restart the feature. Verify that the app does not add the entire previous cumulative reading again. If the underlying counter resets, reconcile the new baseline according to the API's semantics instead of displaying a negative count or a huge artificial increase.
Test crossing the application's day boundary and changing the device's time zone. Decide how historical activity is attributed and label that policy consistently. A local date change should not silently duplicate the same events into two days. Keep the source timestamp and aggregation rules available for diagnosis without storing unnecessary detailed movement history.
When permission is denied, show that tracking is unavailable or offer an explicitly manual feature if the product supports one. Do not generate plausible step values to fill the gap. If access is granted but the sensor is absent or no readings arrive, distinguish that condition from denial so the user is not sent through an irrelevant permission loop.
Disable the feature and verify that its collection work stops. Re-enable it deliberately and check that the UI separates any previously saved total from the new live session. Test revocation while the feature exists and confirm that an old success state does not continue implying active measurement.
Review background execution separately if tracking is intended outside a visible screen. The activity grant does not remove scheduling or service restrictions. Keep sensor availability, permission, collection lifecycle and aggregation correctness as four distinct pieces of evidence. Together they establish whether the displayed activity result represents the data actually observed under the application's documented limits.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
