The Permission Is Not the Decision
The central question of this series is why Android Health Connect can offer fine-grained permissions and still need stronger origin and purpose binding. The answer is now clear enough to state directly: a record type identifies what kind of information an app may request, but it does not by itself identify whose record is in scope, why the app may use it, how long the access should last, what metadata may be revealed, or what happens when the value leaves the device. This final synthesis connects those dimensions into one test for meaningful control while keeping the study's evidence limits and Health Connect's legitimate interoperability goal in view.
The category is not the decision
Health Connect's design starts from a defensible premise. Health and fitness data are fragmented across wearables and applications, and a shared on-device platform can reduce integration costs and let users see more coherent patterns. Permissions associated with record types and read or write operations are more selective than an unrestricted health-data grant. Android's settings guidance adds a synchronization toggle and a direct path to Manage access. Google Play policy asks developers to request only what a feature needs, explain the user benefit, disclose collection and sharing, and avoid prohibited uses such as advertising with health data.
None of those premises is defeated by saying that a type-level permission is incomplete. The issue is the difference between a category and a relationship. “Exercise data” is a category. “Records created by this wearable, read by this coaching app, to calculate this recovery feature, during this period” is a relationship. Both descriptions may refer to the same technical record type, but they do not authorize the same data flow.
The distinction becomes consequential because Health Connect puts records from different producers into one shared collection. The study reports that a type-level permission can reach all instances of that type, regardless of which app created them. The record's origin may be available as metadata, but origin is not used to narrow the authorization decision. A user can therefore make a reasonable type-level choice while the runtime capability reaches a wider population than the feature's explanation appears to require.
The empirical results show why this is more than a philosophical distinction. In the study's constructed database, 100 analyzed apps accessed 2,334 records created by other apps. Some of that cross-app access may have been consistent with user-authorized sharing; the authors and Google's reported response do not treat every cross-app read as a violation. But the frequency of the behavior shows that provenance is not an edge case. It is part of the ordinary meaning of what a type permission can reach.
The same problem appears after the read. The study found 69 of 351 analyzed apps transmitting Health Connect data over the network under the authors' strict definition of a leak. The observed values included exercise, nutrition, sleep, weight, blood pressure, body temperature, and location-related information. Some transmissions combined health values with names, email addresses, Advertising IDs, phone numbers, or other device and account context. The health value, the receiver's identity, and the stated purpose cannot be evaluated separately once they travel together.
Transparency failures make the gap harder for a user to detect. The study reports that 60.96 percent of the measured apps failed the tested UI data-transparency requirement because the privacy-policy link in the permission rationale did not lead to a valid policy. It also reports that 90 of 351 apps did not disclose collecting or sharing health records in the relevant Data Safety analysis. These numbers do not prove that every omission was malicious, and they belong to the study's defined sample.