Why Consent Breaks at the Boundary
Health Connect's visible controls and Google Play's health-data policy give users and developers a language for permission, purpose, and revocation. The harder question is whether that language survives the full life of a record after a user grants a type-level capability. This chapter traces that lifecycle—from the permission rationale and synchronization toggle through cross-app access, background or historical reads, network export, and revocation—so readers can distinguish a useful control from a complete purpose-specific authorization.
What the interface and policy promise
The documented Android experience begins with a recognizable user decision. An app's Settings screen should let a person manage its connection to Health Connect. The synchronization toggle is meant to pause or resume the app's reading and writing. When the toggle is off, the app should stop synchronizing. A Manage access button should link directly to the Health Connect application, where the person can manage the app's permissions. If access is insufficient, the app should show a corresponding state rather than silently behaving as though the feature is available; if the user cancels a permission request twice, the guidance calls for an explanation that permissions must be re-enabled in Health Connect Settings.
These controls solve real problems. They make the connection visible, give the user a place to pause it, and turn an abstract permission into a navigable setting. They also establish a useful division of responsibility. The app explains its feature and responds when access is absent; Health Connect presents the platform permission state; the user can change that state. This is better than a system in which synchronization continues with no obvious control surface.
But the documented controls are mostly about whether the app is connected and whether the app has permission. They do not, on the cited page, specify an authorization question for each originating app, a separate purpose for each cross-app flow, or a timeframe attached to each purpose. A synchronization toggle is not the same thing as “allow records from this source for this feature until Friday.” A Manage access link is not the same thing as “show me every use that this app can make of another app's records.” The controls are useful, but their semantic scope is narrower than the full data-flow problem.
Google Play policy supplies the missing vocabulary, at least at the level of rules. Its health-permission guidance says access must be directly tied to a clear benefit within an approved use case. Apps should request only the data types needed for the specific health feature they provide, not a broader collection simply because a wider range of data might be useful later. Developers are expected to maintain an accurate privacy policy that describes what health and fitness data the app accesses, how it is used and stored, whether it is shared, how long it is retained, how it can be deleted, and what security measures protect it. Permission requests require a detailed justification rather than a generic statement that data is “needed for app functionality.”
The policy also draws hard boundaries around purpose.