What the Apps Actually Did
The privacy risks in Android Health Connect are not only an architectural possibility; they were tested against real applications. This chapter explains what the USENIX study measured, how its 351-app dataset was constructed, and what its reported percentages do and do not mean. The goal is to connect observed disclosure failures, cross-app reads, and network transmissions to the missing authorization dimensions—origin, purpose, and time—without treating the results as a census or assuming that every form of sharing was unauthorized.
What the study actually measured
The researchers began with a very large pool: 2,348,217 unique Android applications collected through daily snapshots. They identified 1,068 apps whose manifests declared at least one Android Health Connect permission. That declaration was only a screening signal. The researchers then installed and exercised those apps and excluded cases that did not actually issue Health Connect API calls, as well as apps whose relevant behavior could not be meaningfully reached because it required a paid subscription, membership, a compatible external device, or special account identifiers. The final dataset contained 351 health-related apps that invoked Health Connect APIs and could be analyzed in the study's environment.
That sequence matters because each number answers a different question. The millions describe the starting universe of candidate applications, not apps proven to use Health Connect. The 1,068 describe applications that announced a capability in their manifests, not applications shown to exercise it. The 351 are the apps from which the study's detailed runtime measurements were obtained. A percentage such as 19.60 percent therefore has a denominator of 351 analyzed apps, not all Android applications and not all apps that appear in an app store.
The testbed was designed to make cross-app behavior visible. The researchers used a physical Pixel 6 running AOSP Android 14, populated the Health Connect database with synthetic but plausible records, and used a toy app so that available record types were represented even when the apps under test had not created them themselves. They then manually interacted with the applications, monitored Health Connect API behavior and system-level flows, and compared network traffic with the known record values and metadata. Manual interaction was a deliberate choice. Health applications often require a particular sequence of sign-in, setup, data entry, exercise, or feature use before a read or write path appears. A generic automated tap sequence can miss those paths or produce a misleading result.
The design also favors coverage of meaningful behaviors over a neat laboratory abstraction. An app might request access, read records only after a user starts a workout, or retrieve recent data only when a screen is opened. The researchers' priming and probing process tried to make those paths observable by first creating records and then exercising the apps in context. This does not reproduce every user's device, record history, or choice of permissions. It creates a consistent environment for asking a narrower question: when an app has the opportunity to use Health Connect, what data does it access and where does that data go?
The study's analysis combines several kinds of observation. It watches calls into Health Connect and inspects the values and metadata moving through those calls. It correlates those observations with the device database so that a value seen in network traffic can be tied to a particular record. It also examines the app's Data Safety disclosure and privacy policy. That combination is essential. A network transmission alone says something about behavior; a comparison with the app's disclosure says whether the behavior was visible to the user; a comparison with Google policy says whether the declared or observed use crossed a stated rule.
The measured path can be summarized as follows:
The result is stronger than a survey of what developers say they do because it observes runtime behavior. It is also narrower than a universal audit because manual testing cannot cover every feature and network analysis cannot guarantee detection of encrypted or otherwise concealed flows. The method gives the reader a way to interpret the results: the findings are observations under defined conditions, not a claim that every Android health app behaves in exactly the same way.
What the apps exposed
The first finding concerns transparency rather than exfiltration. Among the 351 analyzed apps, 54, or 15.38 percent, did not disclose collecting Health Connect records in the relevant Data Safety section. Forty-seven, or 13.39 percent, did not disclose sharing them. Taken together, 90 apps—25.64 percent—failed to report collection or sharing of health records. These categories are not a judgment that every omission was deliberate. They are a measurement of whether an app's user-facing declaration contained the disclosure the study's method required.
The study also reports a broader UI transparency failure: 60.96 percent of the apps did not meet Health Connect's guidance because the privacy-policy link shown in the permission rationale did not lead to a valid policy. Six apps did not provide a privacy policy at all, and 17 more had policies that failed to describe access to health data. This is a different failure from a network leak. An app can have a broken or incomplete explanation even if the researchers do not observe a prohibited transmission, and an app can transmit data even when it has a policy. The two failures matter together because a user cannot make an informed decision when the permission explanation is defective and the runtime behavior is opaque.
The second finding makes provenance operationally important. In the test database, 11,504 records had been created by 91 apps. The researchers found 100 analyzed apps accessing 2,334 records created by other apps. Fifteen-point-six-seven percent of apps accessed at least five such records, and 10 percent accessed at least twenty. This is not a claim that every one of those reads violated a user's choice. A user may authorize an app to combine records from several sources. It is evidence that the type-level permission regularly reaches records whose relationship to the requesting app is not captured by the category name.
The study then follows some of those cross-app reads off the device. It identifies 29 apps that accessed records belonging to other apps and leaked those values to 42 domains. The cross-app material included vital signs, exercise routes and location information, nutrition, sleep, weight, record identifiers, and package names that revealed other health-related applications. The sequence matters: the risk is not simply that a second app can see a record in the shared database. It is that the second app may be able to send the record, its origin, or its surrounding context beyond the device.
Using a strict definition, the researchers found 69 of the 351 apps—19.60 percent—transmitting Health Connect data over the network. They counted any observed off-device transmission as a leak, including a transmission to an app's own backend, because the user's visibility and control change once the data leaves the device. The study reports that 5.98 percent of apps produced at least five such leaks, while one app was responsible for 481 leaked Health Connect values. Values from 20 record types appeared in the observed transmissions; exercise sessions, nutrition, sleep, and weight were among the most frequently exposed, while some cases included blood pressure, body temperature, and location.
The label “leak” needs to be read in the study's technical sense. It does not mean that every receiving domain was malicious or that a first-party backend is automatically forbidden. It means the Health Connect value was observed crossing the device boundary, which defeats a simple assurance that on-device storage by itself keeps the user in control. The study could not reliably identify every encrypted or obfuscated flow, so the authors characterize the measured number as a lower bound on privacy violations rather than a complete total.
Identity context made some of the observed flows more consequential. The researchers report 56 apps transmitting combinations of names, email addresses, Advertising IDs, phone numbers, build or carrier information, and Health Connect values. In one class of examples, nutrition or exercise information traveled with a full name or email. In others, exercise titles or nutrition information went to analytics or advertising-related destinations. The study also identifies three apps that shared or sold health information in aggregated, anonymized form for advertising. Under Google's health-permission guidance, transferring or selling health data to advertising platforms, data brokers, or information resellers, or using it to serve ads, is prohibited.
The point is not that every analytics endpoint has the same role or that every observed first-party transmission proves a policy breach. The point is that a type-level permission does not determine purpose. Once an app receives a record, the same technical capability can support a user-facing feature, internal analytics, personalization, advertising, or a use the platform explicitly forbids. Purpose has to be declared accurately and enforced closely enough that the user is not asked to approve one story while the system permits another.
Time and operating context produce another widening of scope. The study examined background access and permission to read historical records. In one case, a weight-tracking app accessed information from 50 other apps and transmitted it with the user's email, age, mobile carrier, body measurements, and timestamps. It also sent a screenshot containing health information to a third-party service. The researchers observed that normal swipe-up termination did not stop the app's background collection; force-stopping it through system settings was required in their test. This is a case study, not evidence that every background-capable app behaves the same way. It shows why a permission granted during onboarding cannot automatically be assumed to describe every later operating context.
The study's responsible-disclosure account adds an important qualification. Google reportedly maintained that many cross-application flows can be consistent with Health Connect's intended user-authorized sharing. At the same time, the company confirmed violations involving health-related data sent to advertising domains, non-consented capture of screen content by analytics SDKs, and inconsistencies between declared and actual collection or sharing. Cross-app access therefore cannot be used as a shortcut for “unauthorized.” The stronger analysis separates four questions: what the platform permits, what the user authorized, what the app disclosed, and what purpose the app actually served.
The method's limits do not erase the architectural finding, but they set the confidence boundary. The researchers used synthetic data and a clean research device, not real users' records. Manual interaction limited scalability. Paid or hardware-dependent features and special-identifier flows were excluded or only partly exercised, five apps resisted full analysis, and encrypted traffic could hide additional transmissions. Those constraints mean the percentages should remain attached to the study's sample and definitions. They do not turn observed cross-app access, disclosure gaps, or off-device flows into speculation.
The more durable conclusion is that the same missing dimensions recur across the results. Origin matters when an app reads records made by other apps. Purpose matters when a value travels to a backend, analytics service, or advertising destination. Time matters when background or historical access continues beyond the moment a user imagined they were using a feature. A permission can be accepted in good faith and still be too coarse for the runtime path it enables.
That brings the evidence back to the user-facing boundary. Android documents synchronization and permission-management controls, and Google Play policy describes clear benefit, minimum necessary access, disclosure, and prohibited uses. The study shows that those promises can diverge from what apps actually access and transmit. The next question is therefore not only what the platform can do, but what a user can reasonably see, revoke, and constrain from the first permission rationale through background use and export.