Split Health Connect import permissions by category - #1509
Conversation
|
Nice piece of work — the decomposition is clean, all seven locales are covered, and every one of the 16 The migration misses a real cohort
preferences.contains(PERMISSION_SIGNATURE_KEY)That key arrived on 2026-07-30 with #949. For them this PR silently stops importing steps, calories, VO₂max, exercise sessions, distance, weight, The signal that doesn't have this problemWhat Android has already granted. Someone holding a granted I built and tested the change rather than sketching it, because two details only show up if you compile it. 1. The derivation, and a guarded one-time writeinternal fun categoriesFromGrantedPermissions(granted: Set<String>): Set<ImportCategory> =
ImportCategory.entries.filterTo(linkedSetOf()) { category ->
permissionsFor(setOf(category)).any { it in granted }
}
fun migrateSelectionFromGrants(context: Context, granted: Set<String>) {
if (prefs(context).getStringSet(CATEGORY_SELECTION_KEY, null) != null) return
val inferred = categoriesFromGrantedPermissions(granted)
if (inferred.isNotEmpty()) setSelectedCategories(context, inferred)
}It only writes when nothing is stored, so someone who deliberately narrows to Recovery is never 2.
|
…ly rebase) Rebases ryanbr#959 down to the Apple side per ryanbr's request on the PR: Android is dropped because ryanbr#1509 already shipped the category split there (HealthConnectImporter.kt, DataSourcesScreen.kt, values*/strings.xml are byte-identical to upstream/main again). ryanbr#645 (Android) stays closed by that PR; this is scoped to ryanbr#653 (iOS) only. Also resolves the HealthKitBridge.swift conflict with ryanbr#1024 the way ryanbr suggested in the same comment: refreshAuthIfPreviouslyGranted() keeps the nightlyVitalsWriteTypesGranted() status read that ryanbr#1024's writeBackAfterNewData() depends on to resume `auth` for a backgrounded offload, but drops the silent auto-reprompt branch for newly-added share types -- the one behavior ryanbr#653's own review objected to. That was the only actual behavioral disagreement between the two PRs; everything else conflicted only textually. requestNewReadTypesIfNeeded()/readTypeSignature (ryanbr#949) is rewired from the pre-staging quantityReadIds/writeTypes/readTypes symbols (removed by ryanbr#653) to the new .coreRead-scoped accessors, keeping it scoped to core reads only so it can never re-request body composition or either write-back stage -- those already have their own explicit opt-in paths. Not done here: an actual Xcode build. No macOS toolchain in this environment, matching the limitation ryanbr#959's own description already discloses. Verified instead: - cherry-picked ryanbr#959's single commit, resolved conflicts by hand, reviewed line by line - grepped this file and every other .swift file in the repo for dangling references to symbols ryanbr#653 renamed/removed (quantityReadIds/quantityWriteIds/highResQuantityWriteIds/bare writeTypes/readTypes) -- none found - no leftover git conflict markers anywhere in the tree - Localizable.xcstrings re-validated as parseable JSON with no duplicate keys after the merge - Android files (HealthConnectImporter.kt, DataSourcesScreen.kt, values*/strings.xml) diffed byte-for-byte against upstream/main -- zero drift, confirming the Android half was fully dropped and not silently reintroduced
Part of issue 645 — the Android half. Deliberately NOT a closing keyword: PR #959 also targets that issue and carries the HealthKit side, so 645 stays open until both platforms have it. Closing it here would leave that PR pointing at a closed issue and reading as redundant when it is the only one covering Apple.
Summary
Tests