Privacy Policy

Last updated: 2026-06-20

Readylytics is an offline-first fitness and training analytics app for Android. This policy explains what data Readylytics processes and how that data is handled.

Who operates Readylytics

Readylytics operates the app and this website. For privacy questions, contact readylytics@gmail.com.

Data Readylytics reads

Readylytics reads health and fitness data from Android Health Connect after you grant permission. Depending on enabled permissions and available data sources, this can include:

• Sleep sessions and sleep stages
• Heart rate and resting heart rate
• Heart rate variability
• Exercise sessions
• Steps
• Optional body metrics, such as weight, body fat, blood pressure, or oxygen saturation, if supported and permitted
• Exercise route locations (latitude/longitude/altitude points of a workout) when Health Connect exposes them and route access is permitted
• Workout distance and elevation gained, when Health Connect exposes them and access is permitted. These are read so a workout shows the same distance and elevation as the app that recorded it, rather than a value re-derived from the GPS track

Readylytics reads this data to calculate fitness and training load trends, sleep insights, readiness, and recovery context, including a daily morning workout recommendation (e.g. suggesting an easier or harder session, or rest) derived entirely from your own locally stored history. This recommendation, and the past workouts it may reference as examples, are computed and stored on-device only — never uploaded, and never require a network request to produce.

Local storage

Readylytics stores app data locally on your device using its private app storage. Health data, preferences, and computed summaries are not uploaded by Readylytics to a cloud service.

Readylytics may create encrypted local backup files when you use the backup feature. These backup files are controlled by you and remain local to your device or the storage location you choose. Prior valid backups are retained until any replacement archive is fully published and verified; temporary plaintext staging files in private app cache are cleaned up on process startup. If password rotation is interrupted after saving the new credential, recovery retains the verified archives encrypted with that credential. Interrupted restores keep recovery state until local maintenance is released; startup retries unfinished recovery before admitting sync.

Local encryption keys are stored through Android Keystore. On devices that support StrongBox, Readylytics attempts to use StrongBox-backed key protection and falls back to standard Keystore when StrongBox is unavailable. Backup passwords and database keys remain local to the device.

A local restore replaces local health data from the selected backup after validating the complete schema inventory and declared record counts. If parsing, count verification, or database integrity checks fail, no data is modified and the database is rolled back. If settings restoration fails after health data is restored, Readylytics reports a partial restore and asks you to restart and rerun restore. An older backup made before workout recommendations existed, or one otherwise missing that computed data, still restores successfully; Readylytics detects the gap from the restored data itself and quietly recomputes those recommendations locally afterward, entirely on-device.

The production app does not request the Android INTERNET permission. It does not include analytics, advertising, telemetry uploads, or any Readylytics-run network service for your health data.

Data sharing

Readylytics does not sell health data, does not use advertising trackers, and does not upload Health Connect data to third-party sign-in, cloud backup, or Readylytics-hosted services.

Diagnostic logging stays on-device. Production diagnostics and crash reports route through strict sanitization that emits only structured reason codes, exception class names, and bounded stack frames — raw exception messages, source/device IDs, GPS coordinates, and private health payloads are never logged or stored.

What a diagnostic log entry contains

Each entry in the on-device diagnostic log contains only:

• a reason code — operation failed, permission denied, backup failed, restore failed, or log write failed;
• the names of the error types involved and up to 32 code locations per error (file positions in Readylytics’ own code, never your data);
• optionally, for sync and recalculation problems: which Health Connect data type was involved (for example heart rate), which step was running (ingest, prune, reconcile, or recompute), how many days before today the affected day is (for example “3 days ago” — never the calendar date), and a coarse record-count range (none, 1–10, 11–100, or more than 100).

It never contains message text, dates or timestamps, record IDs, device or app names, health values, or exact counts.

A logcat export you choose to share contains the same entries, but Android adds its own date and time to every logcat line. Combined with the “days before today” value, that timestamp can reveal the calendar date of the affected day.

Diagnostic, crash, logcat export, and backup staging files are written to the app’s internal cache and are excluded from Android auto-backup and device-to-device transfer. The app prunes these cache directories on startup, so transient staging and diagnostic files do not accumulate on your device.

If Readylytics crashes, it stores a local, plain-text crash report on your device containing only structured reason codes, sanitized stack frames, app version, Android version, and device model — never health data or raw exception messages. This report is never sent automatically. You can choose to share it, either from the prompt shown after a crash or from Settings: by emailing it to readylytics@gmail.com through your own email app (private, only seen by the developer), or by filing it as an issue on the project’s public GitHub repository through your own browser (publicly visible to anyone). If you don’t send it, it stays local to your device.

If Readylytics unexpectedly recalculates a larger part of your history in the background, it keeps a similar local log of those events (the most recent 20), containing only the trigger name, the affected date range and day count, pending recalculation reasons, and app version. It never contains health values. The next time you open the app, the same prompt offers to share it by email or GitHub issue. Nothing is sent automatically, and choosing “Clear” deletes it.

Settings also has “Report Bug or Crash” and “Request Feature” buttons you can use at any time, independent of whether the app has crashed. These share only your device manufacturer/model, Android version and SDK level, and app version — never health data — through the same email or public GitHub issue choice described above.

Your controls

You can revoke Health Connect permissions in Android Health Connect settings. If permissions are revoked, Readylytics preserves your existing local data and suspends synchronization for the revoked types without data loss or blanket deletions. When permissions are re-granted, data synchronization resumes safely. You can delete local app data through Android system settings. You can also delete local backup files from their storage location.

Readylytics limits locally stored history using a retention setting. By default, retention is enabled at 365 days, and you can adjust it in Settings to any value between 180 days and 3 years (1095 days). State retention applies to every imported health-record table. If you turn retention limiting off, Readylytics disables periodic age-based cleanup and keeps existing local history without a time limit. The separate 10-year (3650-day) Health Connect import horizon only bounds how far a resync attempts to read; it is not an automatic deletion ceiling for data already stored locally. Backups contain only records present in the local database at backup time. Since heart-rate history older than 90 days is stored as one-minute summaries rather than individual samples, an encrypted local backup now also includes the per-minute coverage records that say which device or app each summarised minute came from, so a restore reproduces the same history. This is the same on-device health data you already had; no new data is collected and nothing is uploaded. Files staged for an in-progress data refresh are working state and are not included in backups. Retention cleanup removes expired minute coverage and per-source heart-rate evidence together with their summaries. Changing the selected heart-rate device also removes discarded devices’ contributions from the affected range before rebuilding summaries.

To protect your privacy and prevent decryption or data corruption issues on new devices (since cryptographic keys are hardware-bound and do not transfer), all local app data—including databases, preferences, encryption keys, and local backup files—is explicitly excluded from standard Android Auto Backup (cloud backup) and device-to-device transfers.

Age requirement

Readylytics is intended for users aged 18 and older and is not directed at children. Readylytics does not knowingly collect data from children.

Medical disclaimer

Readylytics is a fitness and training analytics app, not medical or health guidance. It does not diagnose, treat, prevent, or cure any disease or medical condition. Wearable metrics can be incomplete or inaccurate, and any health concern should be discussed with a qualified clinician.

Changes

This policy may be updated as Readylytics changes. Updates will be published on this page.