Android’s Health Connect Tightens Data Privacy but Leaves Encryption Gaps

Android’s handling of sensitive health data has undergone a quiet but consequential transformation, and a new peer-reviewed analysis now quantifies exactly how far the platform has come — and where it still falls short. Researchers at the University of Valladolid in Spain and NIC Chile Research Labs in Santiago systematically compared three generations of Android health data management solutions: the Android Sensor API introduced in 2009, Google Fit launched in 2012, and Health Connect, which arrived with Android 14 in October 2023 after being announced at Google I/O in 2022. Their verdict, published in Frontiers in Digital Health, is that Health Connect represents a substantial architectural advance in both security and privacy, yet a critical weakness in runtime encryption leaves health records exposed in plaintext on the device itself.

The stakes of this question are considerable. Android is the most widely used mobile operating system in the world, and both wearables and health applications run on it, meaning the security of sensitive health information ultimately depends on how the operating system manages that data. Users constantly share personal medical and biometric information across applications, and if this data is not adequately protected it can be exposed to misuse. The study’s authors frame the problem through the European General Data Protection Regulation’s distinction between data controllers, which determine the purpose and means of processing personal data, and data processors, which process data on the controller’s behalf. In the interaction between mobile applications and health APIs, the apps act as controllers while the APIs act as processors of health data — so the robustness of the entire privacy chain depends on the APIs’ capacity to provide protective mechanisms.

To evaluate whether Health Connect genuinely improves on its predecessors, the team designed a structured, technology-agnostic assessment framework grounded in European regulation. On the security side, they drew on the NIS2 Directive, which defines cybersecurity through the characteristics of availability, authenticity, integrity and confidentiality, and the Cyber Resilience Act, which requires developers and distributors of digital products to implement security by design and security by default. On the privacy side, they applied principles from Articles 5 and 6 of the GDPR: data minimisation, consent, transparency, accuracy and storage limitation. The researchers deliberately excluded criteria such as purpose limitation and accountability because those depend on the governance policies of the end-user application rather than on technical features the health data management APIs themselves can support.

The methodology proceeded in four phases. First, the researchers defined a threat model based on the flow of health data through the Android ecosystem, identifying two principal adversaries: network-level eavesdroppers who exploit unencrypted channels to intercept or tamper with data in transit, and unauthorised third parties who engage in excessive data harvesting, user profiling or secondary processing without valid consent. The model assumes the local device is trustworthy — that the operating system and inter-process communication mechanisms are intact and no malicious applications are present — while compromised-device scenarios such as local malware remain outside the scope. Second, they selected the APIs to compare through a historical review of the Android ecosystem, excluding proprietary SDKs such as Samsung Health or the Fitbit SDK. Third, they analysed how each API handles health information across four technical features: storage and operating system interaction, storage encryption, operational model, and data granularity and permissions. Finally, they compared the solutions against the defined criteria.

A four-tier evaluation scale structured the comparison. Native support means the API neutralises a threat architecturally or automatically without relying on developer intervention. Partial support means built-in safeguards exist but leave verifiable gaps. Developer-dependent means the API delegates the entire responsibility for implementing safeguards such as encryption to the application developer. Not supported means the API fundamentally lacks the necessary tools or architecture. For Health Connect, the researchers went beyond documentation review and conducted empirical verification using the OWASP Mobile Application Security Testing Guide, working in a controlled Android 13 environment with Health Connect build 2026.02.19.00.release and populating synthetic health records through the official Health Connect Toolbox developer client to eliminate third-party implementation bias.

The empirical results revealed both the strengths and the central weakness of the new platform. Tests targeting storage isolation confirmed that Health Connect completely avoids shared external storage and requests zero storage permissions, confining all records strictly to its private sandbox — a container architecture that centralises health information locally and requires a two-stage access model. A further test verified that Health Connect’s backup configuration explicitly excludes all database files from cloud backups, permitting only direct device-to-device transfers, which keeps data retention and user revocation confined to the local device. However, the test evaluating local storage and runtime encryption failed: all inserted health records in the internal database, healthcore.db, were found in plaintext. While the operating system provides file-based encryption at rest, Health Connect lacks database-level encryption, meaning that rooted devices or physical data extractions would fully expose health records in readable form.

The comparative scoring against the predecessors was stark. On security, Health Connect achieved native support for integrity, availability and authenticity, but only partial support for confidentiality because of the runtime encryption failure. Google Fit, being cloud-based, was rated not supported for confidentiality, integrity and availability, since its architecture exposes data in transit and remote storage to external vulnerabilities and depends on network connectivity. The Android Sensor API, which offers direct access to hardware sensors through the SensorManager class with no intermediate storage layer, was classified as developer-dependent for confidentiality and integrity, leaving all protective implementation to the app creator. On the privacy side, Health Connect earned native support across all five evaluated criteria — data minimisation, user consent management, transparency, accuracy and storage limitation — while Google Fit and the Sensor API relied on general, coarse-grained permissions that prevented true minimisation and obscured the specific scope of collected data.

The most substantial evolution lies in permission granularity. Under the older models, the BODY_SENSORS permission introduced with Android 5 in 2014 granted access to all health sensors simultaneously — heart rate, blood pressure and more — even when an application needed only one specific measurement, and Google Fit similarly required broad permissions to access health data categories. This all-or-nothing approach raised significant privacy and security concerns. Health Connect radically shifts the model: access is requested for specific pieces of data such as READ_HEART_RATE, and through a new management application users can control read and write permissions independently for each app. A fitness app, for example, could be granted permission to write calories consumed while being permitted only to read calories burned. Empirical tests of this permission mechanism passed, confirming the robustness of the fine-grained control.

The authors are careful to attribute the improvements correctly. In their view, the gains that can be exclusively credited to Health Connect are the increased granularity of health data permissions and the two-phase access control enabled by its container architecture, which advances privacy but does not directly affect data security. The security improvements, by contrast, stem partly from better utilisation of capabilities the Android operating system already offers, particularly encryption, rather than from an innovative contribution of Health Connect itself. They also acknowledge limitations of the analysis: the study centred on the intrinsic architectural capabilities of the APIs rather than a full audit of real-world applications, the cloud-based security of Google Fit was assessed from documentation rather than experimental penetration testing, and the official documentation offers limited granularity about the cryptographic protocols Health Connect actually employs.

The timing of these findings matters for the ecosystem’s future. Google Fit is scheduled for deprecation in 2026, and Health Connect became mandatory for developers starting from 28 May 2025, though the authors note that Google has a history of delays in implementing scheduled changes, which could hinder adoption. The researchers argue that addressing the runtime encryption gap and improving implementation transparency are essential to consolidate user and developer trust across the digital health ecosystem. Because their methodology was deliberately built on universal threat modelling principles and broad regulatory requirements rather than operating-system-specific code, they say it can be readily adapted to evaluate health data management in other mobile ecosystems such as Apple’s HealthKit, with the OWASP testing framework providing platform-specific tests for iOS environments — a logical next step toward comprehensive cross-platform security and privacy benchmarks for the health data that our pocket devices increasingly hold.

Subject of Research: Comparative security and privacy evaluation of Android health data management APIs, including Health Connect, Google Fit and the Android Sensor API

Article Title: On the evolution of security and privacy in Android health APIs

Article References: Pérez-Fuente, A., Martínez-González, M. M., & Bustos-Jiménez, J. (2026). On the evolution of security and privacy in Android health APIs. Frontiers in Digital Health, 8, Article 1818536. https://doi.org/10.3389/fdgth.2026.1818536

Image Credits: AI Generated

DOI: 10.3389/fdgth.2026.1818536

Keywords: Android, Health Connect, mobile health, data privacy, data security, encryption, GDPR, NIS2 Directive, Cyber Resilience Act, OWASP MASTG, Google Fit, permissions