Claude 84c6dba81b feat: justify and document the Health Connect permissions ...

Google rejected the Health Connect declaration for "Insufficient Information
to Determine App Functionality": neither the store listing, the privacy
policy, nor the in-app experience explained what Amethyst does with the seven
read permissions it asks for.

All seven are used by HealthConnectManager, so none can be dropped. What was
missing was the explanation, on every surface a reviewer looks at:

- The rationale intents the manifest declares
  (ACTION_SHOW_PERMISSIONS_RATIONALE, ACTION_VIEW_PERMISSION_USAGE +
  CATEGORY_HEALTH_PERMISSIONS) pointed at MainActivity, which handles neither
  — tapping "privacy policy" in Health Connect just opened the feed. They now
  land on HealthConnectRationaleActivity, a static, account-free screen that
  lists each data type, what it fills in, and what the app never does. It is
  also reachable from a "What Amethyst reads" link on the Connect card, so
  the rationale is available before the permission request, not only after.
- PRIVACY.md gains a "Health and fitness data (Health Connect)" section: a
  per-type purpose table plus the limits (read-only, foreground-only, 7-day
  window, no route/background/history permissions, no secondary use).
- The Play listing description now covers the app's features and the
  Workouts flow, so the listing reflects what the permissions are for.
- docs/health-connect-play-declaration.md holds the paste-ready Play Console
  text: app functionality, a reviewer walkthrough, and a per-permission
  justification — including that CyclingPedalingCadence and StepsCadence come
  bundled with READ_EXERCISE and READ_STEPS and are never read.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019egdJyBHnrATZHjs86up8f

2026-09-12 01:11:46 +00:00

..

metadata/android

feat: justify and document the Health Connect permissions

2026-09-12 01:11:46 +00:00