Now Android may be poised to bring life-saving medical hardware a seat at the table. Code in recent beta builds hints at a new “Medical” companion device profile coming with Android 17, which could potentially improve the connection reliability and setup process of glucose monitors, insulin pumps, smart inhalers, and similar connected devices on phones.
The stakes are high. According to the International Diabetes Federation, in excess of 500 million adults have diabetes globally, and a growing number rely on continuous monitoring and regular alerts. But today, for all practical purposes Android treats those peripherals the same as any other Bluetooth device — wonderful for battery, not so good for an alarm that must never fail.
What the new “Medical” profile does change
Since Android 12, companion device profiles enable apps for accessories, such as watches or smart glasses, to request a bundled set of permissions all at once and receive priority treatment when the accessory is in proximity. The Medical profile looks like it extrapolates that idea to health hardware.
The Medical profile, according to references in Android 16 QPR2 beta code that describes SDK level 37 (typically associated with the next major release of the OS), would provide a “predefined set of permissions” — including urgent alert notifications and Bluetooth permissions like scan, connect, and advertise that help keep a stable connection between devices — as well as fixed alarms for executing time-critical tasks.
It’s nonexclusive, which is to say that multiple health apps can serve as the intermediary between Apple’s health record data and the world, and it’s requestable by third-party developers. A feature flag implies it’s not yet live.
Like with current profiles, Android can raise the companion app’s process priority whenever you’re connected or near it. That lowers the chances that the system will go ahead and kill a background service during memory pressure — an important defense when your app needs to deliver alarms or sync readings at specific intervals.
Why this is important for safety‑critical care
Health apps routinely struggle against the OS to keep running in the background. Developers frequently ask you to turn off battery optimizations, give them do-not-disturb access and approve a laundry list of permissions — things that are confusing at best and actually dangerous at worst. A simple Medical profile would smooth onboarding and tell the system, “this app’s work matters.”
The advantage is clearest for devices that dose or dispense on schedules: insulin pumps, connected medication dispensers, and respiratory aids. Precise on-time alerts and solid Bluetooth connections can mean the difference between adherence and a negative event. Regulatory agencies such as the U.S. Food and Drug Administration (FDA) prioritize the reliability of alarm behaviors in guidance, and lessening OS-induced interruptions is consistent with this demand.
It also helps to solve a long-running malfunction: Android fragmentation in background limits. Some smartphone manufacturers have notoriously aggressive power-saving policies that accidentally block or delay alerts from the CGM. An OS-wide, level-one (“medical companions”) recognition of good apps (as a measure) is the only way — unlike per-model good-app pursuing.
Gaps to watch: alarms, DND, OEM policies
The early code suggests a promising beginning, but there are open questions. A lot of CGMs and cardiac monitors require constant operation, instant alerts that penetrate sleep hours, and lack of susceptibility to too-aggressive battery management. Today, some apps still want do-not-disturb override and exceptions to battery optimizations so that warnings arrive on time — the kinds of permissions which are being sought here but have not been called out in the references to the Medical profile that we’ve seen yet.
Consider, for instance, the glucose-monitoring apps that are often so widespread; they request to override DND and run at full throttle in the background to never have hypoglycemia or hyperglycemia alerts go unanswered. If what Android 17’s discovery profile needs is not covered by Medical, Google might also need an additional carve-out in the way that critical or accessibility services get one to ensure medical alarms are always delivered on time.
Consistency between manufacturers is another key. Even with a new responsibility, those OEM-specific power policies can still get in the way. Clear guidance from Google, adherence to best practices established by Bluetooth SIG for low-energy medical peripherals, and CTS tests that emulate safety-related alert paths would help a lot to make this more universally reliable.
What this means for developers and patients
For developers, a Medical profile is a single, understandable permission prompt away, less brittle background behavior to implement, and fewer support tickets associated with missed alarms. It could also shorten regulatory approval timelines by minimizing OS-related variability.
For patients and caregivers, the upside is simple: faster setup, less confusing steps, and more reliable alerts. If Android 17 does come with the role — and OEMs consistently honor it — it’d be the most significant step the platform’s taken to date in treating medical companions as a first-class use case.
The direction is right. Now it’s just a matter of scope: will the Android 17 Medical profile bring in the entire alarm pathway, including DND and background exceptions, or is that still going to be manual per-add-on? For hundreds of millions who rely on health tools that are connected to the internet, the answer might be life-altering.