react-native-step-tracker-pro 1.0.0

package/docs/INSTALLATION.md

@@ -0,0 +1,175 @@
+# Installation
+
+## Requirements
+
+| | |
+|---|---|
+| React Native | ≥ 0.74 (old and new architecture both supported) |
+| `minSdkVersion` | 26 — `java.time` and the Health Connect client both need it |
+| `compileSdkVersion` / `targetSdkVersion` | 35 |
+| Java | 17 |
+| Kotlin | 1.9.24 by default; see below for 2.x |
+
+## 1. Install
+
+```sh
+npm install react-native-step-tracker-pro
+# or
+yarn add react-native-step-tracker-pro
+```
+
+Autolinking picks the package up. No manual `MainApplication` edit is needed.
+
+## 2. Set the SDK levels
+
+`android/build.gradle` in your app:
+
+```gradle
+buildscript {
+    ext {
+        minSdkVersion = 26
+        compileSdkVersion = 35
+        targetSdkVersion = 35
+    }
+}
+```
+
+## 3. Kotlin 2.x (only if your app is already on it)
+
+The library ships Room via KSP and defaults to Kotlin 1.9.24. KSP versions are
+pinned to an exact Kotlin version, so if your app uses Kotlin 2.x you must say
+so, or the build fails with a KSP/Kotlin mismatch.
+
+```gradle
+buildscript {
+    ext {
+        kotlinVersion = "2.0.21"
+        kspVersion = "2.0.21-1.0.25"   // must match kotlinVersion exactly
+        roomVersion = "2.7.1"
+    }
+}
+```
+
+Other overridable properties: `healthConnectVersion` (default `1.1.0-beta01`),
+`workVersion` (default `2.9.1`).
+
+`healthConnectVersion` is held at `1.1.0-beta01` on purpose: `1.1.0` stable
+requires `compileSdk 36` and Android Gradle Plugin 8.9.1+, which React Native
+did not ship until well after 0.76, so depending on it would fail
+`checkDebugAarMetadata` in every app inside the `react-native >= 0.74` range
+this package claims to support. `1.1.0-beta01` is the newest release that still
+builds against `compileSdk 35` and exposes the same `Metadata` API. If your app
+is already on `compileSdk 36` and AGP 8.9.1+, opt up with:
+
+```groovy
+ext {
+    healthConnectVersion = "1.1.0"
+}
+```
+
+
+If Gradle warns that the Kotlin plugin is loaded twice with different versions,
+that is this mismatch — set `kotlinVersion` and `kspVersion` as above.
+
+## 4. Manifest entries your app must add
+
+The library manifest already merges in the service, the boot receiver, the
+sensor permissions and the Health Connect permissions. Two things cannot be
+merged and have to live in your app:
+
+### Health Connect rationale screen
+
+Play rejects apps that request Health Connect permissions without a screen
+explaining what the data is used for. Add both the intent filter (Android 13 and
+below) and the alias (Android 14+) to whichever activity shows your privacy
+policy:
+
+```xml
+<activity android:name=".MainActivity" android:exported="true">
+    <intent-filter>
+        <action android:name="androidx.health.ACTION_SHOW_PERMISSIONS_RATIONALE" />
+    </intent-filter>
+</activity>
+
+<activity-alias
+    android:name="ViewPermissionUsageActivity"
+    android:exported="true"
+    android:permission="android.permission.START_VIEW_PERMISSION_USAGE"
+    android:targetActivity=".MainActivity">
+    <intent-filter>
+        <action android:name="android.intent.action.VIEW_PERMISSION_USAGE" />
+        <category android:name="android.intent.category.HEALTH_PERMISSIONS" />
+    </intent-filter>
+</activity-alias>
+```
+
+### Trimming permissions you do not use
+
+The library declares read and write for steps, distance and calories. Remove
+any pair you will not use — Play asks you to justify every declared health
+permission:
+
+```xml
+<uses-permission
+    android:name="android.permission.health.WRITE_TOTAL_CALORIES_BURNED"
+    tools:node="remove" />
+```
+
+Same for `REQUEST_IGNORE_BATTERY_OPTIMIZATIONS` if you only ever call
+`openBatteryOptimizationSettings()`:
+
+```xml
+<uses-permission
+    android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"
+    tools:node="remove" />
+```
+
+## 5. Custom notification icon (recommended)
+
+The bundled icon is a generic footprint. Drop a white-on-transparent
+`ic_stat_steps.xml` into `android/app/src/main/res/drawable/` and pass the name:
+
+```ts
+await StepTracker.initialize({ notificationIcon: 'ic_stat_steps' });
+```
+
+## 6. Build
+
+```sh
+cd android && ./gradlew clean && cd ..
+npx react-native run-android
+```
+
+The step counter does not exist on most emulators. Use a physical device, or
+inject values on an emulator with:
+
+```sh
+adb shell run-as <applicationId> \
+  sed -i 's/steps_today" value="[0-9]*"/steps_today" value="5000"/' \
+  shared_prefs/StepTrackerProState.xml
+```
+
+## 7. Minimum working setup
+
+```ts
+import { useEffect } from 'react';
+import StepTracker from 'react-native-step-tracker-pro';
+
+useEffect(() => {
+  (async () => {
+    await StepTracker.initialize({ height: 175, weight: 75, dailyGoal: 10000 });
+    const perms = await StepTracker.requestPermissions();
+    if (perms.allGranted) await StepTracker.startTracking();
+  })();
+
+  const sub = StepTracker.addListener('stepsChanged', ({ steps }) => {
+    console.log(steps);
+  });
+  return () => sub.remove();
+}, []);
+```
+
+## ProGuard / R8
+
+`consumer-rules.pro` ships with the library and is applied automatically. No
+app-side rules are needed.

package/docs/PLAY_STORE_COMPLIANCE.md

@@ -0,0 +1,122 @@
+# Play Store compliance
+
+Read this before your first upload. A step tracker touches three of Play's
+sensitive areas at once — foreground services, health data and battery
+exemptions — and each has its own declaration form.
+
+## 1. Foreground service type
+
+Play requires a declared type and a justification for every foreground service.
+This package uses `health`.
+
+**Play Console → App content → Foreground service permissions.**
+
+- **Permission:** `FOREGROUND_SERVICE_HEALTH`
+- **Purpose:** continuous step counting for a fitness feature
+- **Why a foreground service is required:** the app must keep reading the step
+  sensor while the screen is off and the app is not in the foreground; deferred
+  work such as WorkManager cannot sample a sensor continuously
+- **Video:** record a screen capture showing the notification appearing when
+  tracking starts, and the count updating while walking with the app closed.
+  Reviewers reject text-only submissions here.
+
+The notification must be visible and honest. Do not hide it, do not make it
+dismissible, and do not use a title that misrepresents what is running.
+
+## 2. Health Connect
+
+**Play Console → Health apps declaration form.** Every permission declared in
+the merged manifest has to be justified, so remove the ones you do not use
+(see [INSTALLATION.md](INSTALLATION.md#trimming-permissions-you-do-not-use)).
+
+Requirements:
+
+- A privacy policy that specifically names the Health Connect data types you
+  read and write, states that data is stored on-device, and explains any
+  transmission off-device. Link it from both the Play listing and in-app.
+- The `ACTION_SHOW_PERMISSIONS_RATIONALE` intent filter and the
+  `VIEW_PERMISSION_USAGE` activity alias. Missing these is the most common
+  rejection.
+- No advertising, no selling health data, and no sharing it with third parties
+  for anything unrelated to the feature the user asked for.
+- Data deletion must be possible from inside your app. `clearHistory()` covers
+  your local store; Health Connect data is deleted from the Health Connect app.
+
+### On duplicate step data
+
+From Android 14 with SDK Extension 20 or higher, Health Connect records
+on-device steps by itself once any app holds `READ_STEPS`. If you also write
+steps, users can see the same walk twice in the Health Connect UI. Two sane
+options:
+
+- **Read-only** — leave `healthConnectEnabled: true` but never call the write
+  path. Use Health Connect as a source, your Room database as the record.
+- **Write with attribution** — keep writing. Records carry a stable
+  `clientRecordId` so re-syncing does not stack duplicates, but they still sit
+  alongside the platform's own entries.
+
+Pick one deliberately and say which in your privacy policy. Also note that as of
+the June 2026 Health Connect update, on-device steps are attributed to a
+device-specific synthetic package name rather than the generic `android` package,
+which changes how you filter by source.
+
+## 3. Battery optimisation exemption
+
+`REQUEST_IGNORE_BATTERY_OPTIMIZATIONS` is a restricted permission. Play allows
+it only for a short list of use cases, and "our fitness app works better" is not
+one of them. An app rejected here usually has to strip the permission and
+resubmit.
+
+Recommendation: **remove the permission** and use
+`openBatteryOptimizationSettings()`, which opens the system list and lets the
+user grant the exemption themselves. That path needs no declaration.
+
+```xml
+<uses-permission
+    android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"
+    tools:node="remove" />
+```
+
+If you keep it, submit the **Permissions declaration form** and expect to argue
+the case.
+
+## 4. ACTIVITY_RECOGNITION
+
+A runtime permission from Android 10. Request it in context — after the user has
+tapped something that clearly starts tracking — not on first launch. Play's data
+safety form must list it under "Health and fitness → Fitness info".
+
+## 5. Data safety form
+
+Declare, at minimum:
+
+| Data type | Collected | Shared | Purpose |
+|---|---|---|---|
+| Fitness info (steps, distance, calories) | Yes | Only if you set `remoteSyncUrl` | App functionality |
+
+If `remoteSyncUrl` is set, you are transmitting health data off-device: declare
+it as shared, state the recipient, confirm encryption in transit (use HTTPS —
+the worker will happily post to `http://`, and you should not), and offer a
+deletion path.
+
+## 6. Notification content
+
+Android 13+ makes notifications a runtime permission. Denying it hides the
+notification but does not stop the service, and `allGranted` in
+`checkPermissions()` reflects that deliberately. Do not block your onboarding on
+`POST_NOTIFICATIONS`.
+
+## 7. Pre-launch checklist
+
+- [ ] Foreground service declaration submitted, with a video
+- [ ] Health apps declaration submitted, only for permissions you actually use
+- [ ] Privacy policy names each Health Connect data type
+- [ ] `ACTION_SHOW_PERMISSIONS_RATIONALE` filter and `VIEW_PERMISSION_USAGE`
+      alias present in the app manifest
+- [ ] `REQUEST_IGNORE_BATTERY_OPTIMIZATIONS` removed, or declared and justified
+- [ ] Unused `android.permission.health.*` entries removed with `tools:node="remove"`
+- [ ] Data safety form matches whether `remoteSyncUrl` is configured
+- [ ] `ACTIVITY_RECOGNITION` requested in context, with an explanation on screen
+- [ ] In-app data deletion available
+- [ ] Tested on a Xiaomi or Oppo device, where autostart restrictions kill
+      services that survive fine on Pixel

package/docs/TESTING.md

@@ -0,0 +1,312 @@
+# Testing the package
+
+Two layers. The engine logic — reboot, midnight, pause, counter resets — is
+covered by instrumented tests that feed samples directly, so no walking is
+needed. Everything that involves the OS keeping your process alive has to be
+verified on a real device.
+
+---
+
+## 1. Link the package into a test app
+
+It is not published yet, so point an app at the folder.
+
+```sh
+# in the package
+npm pack                      # → react-native-step-tracker-pro-1.0.0.tgz
+
+# in your test app
+npm install ../react-native-step-tracker-pro/react-native-step-tracker-pro-1.0.0.tgz
+```
+
+`npm pack` is better than `file:` or `yarn link` here: Metro follows symlinks
+badly, and `file:` installs a symlink on npm 7+. Re-run `npm pack` + install
+after every change to the package.
+
+Then set the SDK levels in the app's `android/build.gradle`:
+
+```gradle
+buildscript {
+    ext {
+        minSdkVersion = 26
+        compileSdkVersion = 35
+        targetSdkVersion = 35
+    }
+}
+```
+
+```sh
+cd android && ./gradlew clean && cd ..
+npx react-native run-android
+```
+
+---
+
+## 2. Run the engine tests
+
+```sh
+cd android
+./gradlew :react-native-step-tracker-pro:connectedAndroidTest
+```
+
+Runs fine on an emulator — the tests never touch the sensor. Eleven cases
+covering:
+
+| Test | What breaks if it fails |
+|---|---|
+| `accumulatesCounterDeltas` | basic counting |
+| `sensorResetWithoutRebootDoesNotDoubleCount` | OEM HAL restarts inflate the total |
+| `rebootOnSameDayClaimsStepsTakenSinceBoot` | steps between boot and service start are lost |
+| `rebootOnPreviousDayDropsPreServiceSteps` | yesterday's steps land in today |
+| `midnightRolloverFinalisesPreviousDay` | day totals never close, or leak forward |
+| `pausedStepsAreDiscardedAndResumeDoesNotBackfill` | pause does nothing, or resume dumps a backlog |
+| `detectorFallbackIncrementsDirectly` | no-step-counter devices count nothing |
+| `commitThresholdControlsDatabaseWrites` | a write per step, or no writes at all |
+| `resetTodayClearsTotalButKeepsCountingAfterwards` | QA reset replays the old count |
+| `metricsDeriveStrideFromHeightWhenNotOverridden` | distance/calories maths |
+| `calendarWeekIsMondayAnchoredAndSevenDaysLong` | weekly stats window |
+
+Run one case:
+
+```sh
+./gradlew :react-native-step-tracker-pro:connectedAndroidTest \
+  -Pandroid.testInstrumentationRunnerArguments.class=com.steptrackerpro.StepCounterEngineTest#rebootOnSameDayClaimsStepsTakenSinceBoot
+```
+
+---
+
+## 3. Device check before anything else
+
+Most emulators have no step hardware, so live counting can only be tested on a
+phone.
+
+```sh
+adb shell dumpsys sensorservice | grep -i step
+```
+
+Or from JS:
+
+```ts
+console.log(await StepTracker.getDeviceCapabilities());
+// { hasStepCounter: true, hasStepDetector: true, supported: true, ... }
+```
+
+If `supported` is false, everything below is untestable on that device.
+
+---
+
+## 4. Manual matrix
+
+Set `PKG` to your app's applicationId first: `PKG=com.yourapp`
+
+### App open
+
+Start tracking, walk 20–30 steps. Sensor hubs often buffer the first few, so
+walk properly rather than shaking the phone.
+
+- [ ] `stepsChanged` fires in JS
+- [ ] notification shows steps, km, kcal and the progress bar
+- [ ] numbers in the notification and the UI agree
+
+### Background and screen locked
+
+```sh
+adb shell input keyevent KEYCODE_HOME
+adb shell input keyevent KEYCODE_POWER      # screen off
+# walk 50 steps
+adb shell input keyevent KEYCODE_POWER
+```
+
+- [ ] lock screen notification shows an updated count
+- [ ] reopening the app shows the same total, not a stale one
+
+### App swiped away
+
+Swipe the app out of recents.
+
+- [ ] notification stays
+- [ ] count still rises while walking
+- [ ] `adb shell dumpsys activity services $PKG | grep StepTrackerService` shows it running
+
+### Process killed
+
+```sh
+adb shell am force-stop $PKG
+# walk 100 steps with the app dead
+adb shell monkey -p $PKG -c android.intent.category.LAUNCHER 1
+```
+
+- [ ] the 100 steps appear after relaunch
+
+This is the single most valuable test. `TYPE_STEP_COUNTER` kept counting in the
+sensor hub while your process was gone; the first sample after restart should
+reconcile them in. If they are missing, the anchor logic is wrong.
+
+### Boot recovery
+
+Real reboot:
+
+```sh
+adb reboot
+# wait for the lock screen, do not open the app
+```
+
+- [ ] notification reappears on its own within a few seconds of unlock
+- [ ] yesterday's / today's total is intact
+
+Faster loop while iterating — fires the receiver without rebooting:
+
+```sh
+adb shell am broadcast -a android.intent.action.BOOT_COMPLETED \
+  -n $PKG/com.steptrackerpro.service.BootReceiver
+```
+
+This exercises the receiver's guard rails (initialised, `autoStartOnBoot`,
+`shouldAutoStart`, permissions) but not the counter reset — only a real reboot
+zeroes the hardware counter.
+
+### Midnight rollover
+
+No root needed. Settings → System → Date & time → turn off automatic, set the
+date forward one day. Then take a few steps.
+
+- [ ] `dayChanged` fires with yesterday's total
+- [ ] today starts at 0, not at yesterday's number
+- [ ] yesterday's row is in the database with its final count
+
+Set the date back afterwards. On an emulator you can do it from the shell:
+
+```sh
+adb root && adb shell date $(date -v+1d +%m%d%H%M%Y.%S)   # macOS date syntax
+adb shell am broadcast -a android.intent.action.TIME_SET
+```
+
+### Doze
+
+```sh
+adb shell dumpsys battery unplug
+adb shell dumpsys deviceidle force-idle
+# walk
+adb shell dumpsys deviceidle unforce && adb shell dumpsys battery reset
+```
+
+- [ ] steps taken during forced idle are present afterwards
+
+### OEM battery management
+
+Test on a Xiaomi, Oppo, Vivo or Realme device if you have one. They kill
+foreground services that survive fine on a Pixel.
+
+- [ ] with autostart off: counting stops (expected)
+- [ ] `openManufacturerAutoStartSettings()` lands on the right screen
+- [ ] with autostart on: counting survives an hour with the screen off
+
+### Health Connect
+
+Android 14+ has it built in. Android 13 and below need the app from Play.
+
+```sh
+adb shell am start -a android.health.connect.action.HEALTH_HOME_SETTINGS
+```
+
+- [ ] `getHealthConnectStatus()` reports `available: true`
+- [ ] `requestHealthConnectPermissions()` opens the sheet (needs the rationale
+      intent filter in your app manifest, or it silently does nothing)
+- [ ] after `syncNow()`, today's steps appear in the Health Connect app
+- [ ] syncing twice does **not** create two entries for the same day
+- [ ] `readHealthConnectSteps()` returns data written by other apps too
+
+### Offline
+
+```sh
+adb shell svc wifi disable && adb shell svc data disable
+```
+
+- [ ] counting, notification, stats and history all work unchanged
+- [ ] `getPendingSyncCount()` rises if `remoteSyncUrl` is set
+- [ ] after re-enabling the network, `syncCompleted` fires for `target: 'remote'`
+      within the hour, and pending drops to 0
+
+### Goals
+
+Set `dailyGoal: 20` temporarily.
+
+- [ ] `goalProgressChanged` fires as the percentage climbs
+- [ ] `goalReached` fires once, not on every step after the goal
+- [ ] killing and relaunching the app does not re-fire it for the same day
+
+### Retention
+
+Set `historyRetentionDays: 2`, then `pruneHistory()`.
+
+- [ ] rows older than 2 days are gone
+- [ ] `getMonthlyStats()` still returns a zero-filled range without crashing
+
+---
+
+## 5. Inspection
+
+```sh
+# counter state — the file to look at when a number seems wrong
+adb shell run-as $PKG cat shared_prefs/StepTrackerProState.xml
+
+# config
+adb shell run-as $PKG cat shared_prefs/StepTrackerProConfig.xml
+
+# service alive?
+adb shell dumpsys activity services $PKG
+
+# scheduled sync work
+adb shell dumpsys jobscheduler | grep -A 8 $PKG
+
+# logs
+adb logcat -s StepTrackerService:V StepTrackerBoot:V
+```
+
+For the Room tables use Android Studio → **View → Tool Windows → App
+Inspection → Database Inspector**. It reads a live database, which is far less
+painful than pulling the file.
+
+Reading `StepTrackerProState.xml`:
+
+| Key | Meaning |
+|---|---|
+| `steps_today` | current total |
+| `anchor_steps` / `anchor_value` | the pin — `steps_today = anchor_steps + (raw − anchor_value)` |
+| `last_raw_value` | last cumulative reading from the sensor |
+| `boot_id` | approximate boot epoch; a jump here means a reboot was detected |
+| `active_date` | the day the total belongs to |
+| `should_auto_start` | whether the boot receiver will restart the service |
+
+### Injecting a fake count for UI work
+
+Only for screenshots — set `anchor_steps` too, or the next sensor sample
+recomputes the total and wipes your edit.
+
+```sh
+adb shell am force-stop $PKG
+adb shell run-as $PKG sh -c \
+  "sed -i -e 's/\"steps_today\" value=\"[0-9]*\"/\"steps_today\" value=\"7500\"/' \
+          -e 's/\"anchor_steps\" value=\"[0-9]*\"/\"anchor_steps\" value=\"7500\"/' \
+   shared_prefs/StepTrackerProState.xml"
+adb shell monkey -p $PKG -c android.intent.category.LAUNCHER 1
+```
+
+The force-stop matters: SharedPreferences caches in memory, so an edit made
+while the process is alive gets overwritten on the next write.
+
+---
+
+## 6. Order to test in
+
+1. Instrumented tests on an emulator — catches logic regressions in a minute
+2. Physical device: capabilities → permissions → live counting
+3. Background, lock, swipe away
+4. Force-stop recovery
+5. Real reboot
+6. Date rollover
+7. Health Connect
+8. OEM device, if you have one
+
+Steps 1–4 catch almost everything. Steps 5–8 are where devices disagree with
+each other, so they need real hardware rather than an emulator.

package/docs/TROUBLESHOOTING.md

@@ -0,0 +1,96 @@
+# Troubleshooting
+
+## Steps stay at zero
+
+1. `getDeviceCapabilities()` — if `supported` is false the device has no step
+   hardware. Most emulators do not.
+2. `checkPermissions()` — `ACTIVITY_RECOGNITION` must be granted.
+3. `getTrackingState()` — `idle` or `stopped` means the service was never
+   started or was stopped.
+4. Some sensor hubs need 5–10 actual steps before the first event fires.
+   Shaking the phone does nothing; walk.
+
+## Counting stops when the screen goes off
+
+Almost always OEM battery management, not Doze.
+
+```ts
+if (await StepTracker.isBatteryOptimizationEnabled()) {
+  await StepTracker.openBatteryOptimizationSettings();
+}
+await StepTracker.openManufacturerAutoStartSettings(); // Xiaomi, Oppo, Vivo, Huawei
+```
+
+On Xiaomi, "Autostart" and "No restrictions" under battery saver both have to be
+set. On Samsung, remove the app from "Sleeping apps". There is no API for either;
+you have to walk the user there.
+
+## Notification does not appear
+
+- Android 13+: `POST_NOTIFICATIONS` denied. Counting continues, the notification
+  does not show.
+- The channel is created at `IMPORTANCE_LOW`; if the user turned the channel off
+  it stays off. Send them to app notification settings.
+
+## Steps jumped after a reboot
+
+Expected on the boundary. Steps taken between boot and the service restarting
+are counted if the boot happened on the same day, and dropped if it happened
+before midnight. See [ARCHITECTURE.md](ARCHITECTURE.md#reboot).
+
+## Steps reset when I reinstalled
+
+SharedPreferences and the Room database are cleared on uninstall. If you need
+history to survive reinstalls, sync to Health Connect or set `remoteSyncUrl`.
+
+## Build fails: KSP version mismatch
+
+Your app is on Kotlin 2.x and the library defaults to 1.9.24. Set `kotlinVersion`
+and a matching `kspVersion` in the app's root `build.gradle` — see
+[INSTALLATION.md](INSTALLATION.md#3-kotlin-2x-only-if-your-app-is-already-on-it).
+
+## Build fails: `minSdkVersion 24 cannot be smaller than 26`
+
+Set `minSdkVersion = 26` in the app's root `build.gradle`. Health Connect and
+`java.time` both need it.
+
+## `ForegroundServiceDidNotStartInTimeException`
+
+Something in your app is delaying the service start past the 5-second window,
+usually a heavy `Application.onCreate`. The service calls `startForeground`
+first thing, so the delay is upstream.
+
+## Health Connect permission sheet never opens
+
+- `getHealthConnectStatus().available` is false → the provider is not installed
+  (Android 13 and below) or needs an update (`requiresUpdate`).
+- The user permanently denied. The sheet will not reappear; use
+  `openHealthConnectSettings()`.
+- Your app manifest is missing the rationale intent filter. Health Connect
+  refuses to show the sheet without it.
+
+## Events fire in dev but not after a JS reload
+
+`invalidate()` unsubscribes the module from the event bus on teardown. If you
+hold a listener across a reload, re-register in a `useEffect` — the bundled
+hooks already do.
+
+## Numbers do not match Google Fit or Samsung Health
+
+They will not, exactly. Those apps fuse the step counter with accelerometer and
+GPS data and apply their own filtering; neither publishes its model. Steps
+should land within a few percent. Distance and calories will differ more,
+because both are estimates from height and weight here. Tune `strideLength` and
+`calorieCoefficient` if you have better data.
+
+## Inspecting state during QA
+
+```sh
+adb shell run-as <applicationId> cat shared_prefs/StepTrackerProState.xml
+adb shell dumpsys activity services com.steptrackerpro.service.StepTrackerService
+adb logcat -s StepTrackerService StepTrackerBoot
+```
+
+Simulating a reboot without rebooting: force-stop the app, then start it again.
+The boot ID is unchanged, so the counter reconciles rather than re-anchoring —
+which is exactly the process-death path you want to test.