You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Privacy: split Health Connect import permissions by data category #645
The Android Health Connect import flow requests the full importer permission set at once. The importer can handle partial grants later, but the first permission prompt still asks for a broad set that includes body composition, VO2 max, exercise, distance, sleep, heart rate, HRV, calories, and more.
Why this matters
Health data permission prompts should be as narrow and explainable as possible. Requesting every supported Health Connect read scope at once increases consent friction and asks for data the user may not expect when they only want a core import.
Evidence
android/app/src/main/java/com/noop/ingest/HealthConnectImporter.kt:91 defines one READ_RECORDS list for all imported record types.
android/app/src/main/java/com/noop/ingest/HealthConnectImporter.kt:114 derives PERMISSIONS from the entire list.
android/app/src/main/java/com/noop/ui/DataSourcesScreen.kt:294 launches HealthConnectImporter.PERMISSIONS when no matching grants exist.
android/app/src/main/java/com/noop/ingest/HealthConnectImporter.kt:159 already supports partial permissions after the grant, so the import logic is close to supporting a narrower UX.
Suggested fix
Split Health Connect read permissions into categories, for example:
Checked against what this issue actually asked for rather than against the title. HealthConnectImporter now carries an ImportCategory enum splitting the read scopes into RECOVERY and ACTIVITY, which is the split suggested above. permissionsFor(categories) derives the ask from the selected set instead of the whole record list, and DEFAULT_CATEGORIES is RECOVERY alone, so a first prompt no longer reaches for body composition, VO2 max, exercise and distance. HealthConnectCategorySelector is the picker, and categoriesFromGrantedPermissions keeps partial grants working, which the evidence above had already noted the importer was close to supporting.
Both call sites cited in the evidence have moved: the single READ_RECORDS list is now derived per category, and the screen launches the selected set rather than everything.
One thing worth recording, because it cost three weeks. On 2026-09-01 I edited the description of #1509 so it would not auto-retire this issue on merge, and kept it open on the reasoning that the HealthKit work in #959 still had to land. That was a misreading of scope: this issue is Health Connect throughout, and the HealthKit side is tracked by #653, which stays open and is what #959 is for. Nothing was wrong with #1509; I held this open by mistake.
Activity
Privacy: split Health Connect and HealthKit permissions into staged c…
Privacy: split HealthKit permissions into staged categories (Apple-on…
ryanbr commentedon Sep 21, 2026
Retiring this: #1509 delivered it on 2026-09-01.
Checked against what this issue actually asked for rather than against the title.
HealthConnectImporternow carries anImportCategoryenum splitting the read scopes into RECOVERY and ACTIVITY, which is the split suggested above.permissionsFor(categories)derives the ask from the selected set instead of the whole record list, andDEFAULT_CATEGORIESis RECOVERY alone, so a first prompt no longer reaches for body composition, VO2 max, exercise and distance.HealthConnectCategorySelectoris the picker, andcategoriesFromGrantedPermissionskeeps partial grants working, which the evidence above had already noted the importer was close to supporting.Both call sites cited in the evidence have moved: the single
READ_RECORDSlist is now derived per category, and the screen launches the selected set rather than everything.One thing worth recording, because it cost three weeks. On 2026-09-01 I edited the description of #1509 so it would not auto-retire this issue on merge, and kept it open on the reasoning that the HealthKit work in #959 still had to land. That was a misreading of scope: this issue is Health Connect throughout, and the HealthKit side is tracked by #653, which stays open and is what #959 is for. Nothing was wrong with #1509; I held this open by mistake.