Hearing accessibility on Android — the platform map in 2026

Roughly 1.5 billion people worldwide live with some degree of hearing loss. Around 430 million have disabling hearing loss. The over-50 cohort is the fastest-growing consumer-tech segment in most markets, and hearing-loss prevalence rises sharply with age — about 1 in 3 people aged 65–74 have disabling hearing loss.

Android is the platform 70 % of those users are on. In 2026, the platform-level capability for hearing accessibility is genuinely good — and the application-level adoption is still mostly absent.

This is the platform map. Fourth of AudioLab.tools’s pillar pieces, following What is audio AI?, AI voice infrastructure in 2026, and Android audio development guide. It’s the cornerstone for HearLab.

The platform layer

What Android natively provides in 2026:

Capability	Status
Live Caption (media + browser tabs)	Stable, mainstream
Sound notifications (doorbell, baby cry)	Stable, opt-in
Real-time text (RTT) for calls	Mainstream
Bluetooth LE Audio for hearing aids	Mainstream on flagships, mid-tier rolling out
ASHA for hearing aids (legacy)	Still required, still working
Auracast (broadcast LE Audio)	Hardware ready, venue rollout early
Audio routing API (MediaRouter)	Stable, underused by apps
Hearing aid presets via Settings	Stable
Personal sound amplifier mode	Available in some markets
Captions in third-party apps	Inconsistent — depends on the app

The story breaks cleanly: the platform is ready, the apps are not.

Live Caption

The biggest single accessibility ship of the last decade. System-wide captions on any audio playing on the device — videos, podcasts, voice messages, video calls. On-device, sub-second latency, no network round-trip required.

What it covers

• Audio routed through STREAM_MUSIC and STREAM_VOICE_CALL
• System sounds, browser tabs (Chrome and Edge)
• Most video and music apps automatically

What it doesn’t

• The microphone. Live Caption captions what your phone is playing, not what is happening around you. To caption the room, you need a separate flow.
• Spatial / source cues. Music gets [Music]. Applause gets [Applause]. The detailed audio-environment cues that matter to deaf users in some contexts are absent.
• Caller identity in group calls. It transcribes; it does not diarise. You see text, not who said it.
• Some locales. Coverage has expanded but is still a fraction of the world’s languages.

The microphone gap is the gap most worth filling. A third-party app that captions the room around the user — meetings, restaurants, dinner conversations — is consistently the most-requested feature among hearing-aid users we’ve talked to.

Bluetooth LE Audio

The platform shift of 2024–2026. Built on Bluetooth 5.2+, includes the LC3 codec, supports multi-stream (binaural) and Auracast broadcast.

What changes for hearing accessibility

• Direct streaming to hearing aids at sub-30ms latency. Phone call audio, music, system sounds — all stream natively without an intermediary device or proprietary protocol.
• Auracast — public broadcast audio. Airports, theatres, conference rooms can broadcast audio that any nearby LE-Audio-equipped device (including hearing aids) can tune to.
• Better battery life on both phone and hearing aid.
• Multi-stream for binaural pairs — coordinated stereo to two hearing aids without manufacturer-specific glue.

Adoption status

• Phone side: mainstream on flagships (Pixel 7+, Galaxy S22+), rolling out on mid-tier.
• Hearing aid side: Phonak, Oticon, Signia, ReSound all shipping LE Audio models; legacy models still require ASHA.
• Venue side (Auracast): early. Notable rollouts in Heathrow, Schiphol, Copenhagen Royal Theatre, several US universities. The 2026 story is “infrastructure ahead of applications.”

What app developers should do

For any new Android audio app touching hearing-device-relevant content:

1. Don’t hardcode A2DP assumptions. Use the AudioAttributes and MediaRouter APIs and let the platform handle routing.
2. Set USAGE_VOICE_COMMUNICATION or USAGE_ASSISTANCE_ACCESSIBILITY when appropriate. These trigger the right routing decisions for hearing aids.
3. Surface the routing. Show the user where their audio is going. The 20 lines of code that everyone else skips.

ASHA — the legacy story still in production

Audio Streaming for Hearing Aids — Google’s 2018-era proprietary-style profile for direct streaming to hearing aids. Pre-LE-Audio hearing aids use it. As of 2026 it’s still essential coverage — many users in the field have ASHA-only devices.

For an app that wants to be inclusive in 2026: support both LE Audio and ASHA. Falling back gracefully is the right pattern; assuming one or the other will leave users behind.

The good news: the platform handles routing transparently. You set USAGE correctly; the OS routes via ASHA or LE Audio depending on the connected device. Your code rarely needs to know which.

Auracast — the venue story

Public broadcast LE Audio. A single source streams to many devices. The hearing-aid relevance:

• A theatre can broadcast its main audio mix; hearing-aid users tune in via their hearing aids.
• An airport gate can broadcast announcements directly to nearby devices.
• A meeting room can broadcast a conference loop without the loop coil.
• A bilingual venue can broadcast multiple language streams; listeners pick theirs.

Adoption is early. The hearing-aid manufacturers are pushing it (their incentive structure aligns); the venue side is slower. The 2026 prediction: meaningful Auracast presence in major public-transport hubs and large venues by 2027; mainstream by 2028–2029.

What apps can do today:

• Support Auracast in your sound-receiver apps and creator tools.
• For accessibility-focused apps, expose Auracast as a first-class source alongside the device microphone.

Routing surfacing — the missing UI

Every modern app talks to the audio routing layer whether it realises it or not. Most apps do not show the user what the routing layer says. This is the easiest accessibility win available to Android developers in 2026.

The pattern:

val router = MediaRouter.getInstance(context)
val selected = router.selectedRoute

val routeName = selected.name
val routeType = selected.deviceType
// deviceType: TYPE_BLUETOOTH, TYPE_HEARING_AID, TYPE_USB_DEVICE, TYPE_WIRED_HEADSET, ...

Surface this in your app:

Now streaming to: Phonak Audéo via LE Audio

This is one banner row. It costs nothing to render. It changes whether the user trusts your app to handle their accessibility flow properly. We surface it by default in HearLab Companion and we believe every consumer app touching audio should do the same.

Live Transcribe and accessibility-first ASR

Live Transcribe is Google’s accessibility-flagship companion app for room-side captioning. As of 2026, it’s the best free option for “caption the room around me” — runs on-device for short utterances, cloud-routed for longer sessions, supports many languages.

For app developers building hearing accessibility:

• Don’t try to compete with Live Transcribe head-on. It’s a strong baseline.
• Differentiate on workflow: per-session logs, context tagging, summary for clinical follow-up, multi-device coordination.
• Use the Web Speech API if you’re building a hybrid app — it’s mostly Google STT under the hood and gives you a low-friction path to room captioning.

HearLab Companion sits explicitly to the side of Live Transcribe: it logs and summarises hearing experience over time, not just transcribes-in-the-moment.

Hearing-aid presets and personal sound amplifier

Android has shipped hearing-aid presets in Settings since Android 12. Personal sound amplifier mode is available in some markets. Both are platform-level features that apps don’t need to integrate with directly — but should be aware of.

The relevance: if your app does any audio enhancement (boost, EQ, noise suppression), check whether the user already has the OS-level presets active. Stacking enhancement on enhancement degrades quality.

Captions in third-party apps — the gap

Live Caption handles audio playing on the device. Captions within third-party apps — embedded video, in-app voice messages, podcast players that don’t leverage the system caption path — are inconsistent.

For developers shipping audio content in any third-party app:

1. Use the system media APIs. ExoPlayer + MediaSession routes audio through paths Live Caption can intercept.
2. Ship caption tracks alongside audio. WebVTT for streaming, embedded for downloaded content.
3. Honour the OS caption settings. Users have system-wide preferences for caption style; respect them.

The marketing pitch for caption support is “accessibility”. The actual reason most app developers should care is “your app works for the next decade of consumer demographics.” Both are valid.

What we built

HearLab Companion is the explicitly non-medical Android companion app for hearing-aid and CI users. The browser-side preview demonstrates the live captions mode, environment audio meter, context tagging, and check-in log. The Android-native version is on the roadmap (private beta, design partners welcome).

The framing — non-medical — is deliberate. See Designing hearing support without medicalising it for the regulatory and product reasoning.

Roadmap:

• Android-native companion app (private beta this quarter)
• LE Audio + ASHA routing visualisation
• B2B2C audiologist dashboard layer
• Iterative summary export tuned for audiological follow-up

The unbuilt opportunities

Five places where the platform is ready and the products aren’t:

1. Mic-side captioning, persistent

Live Caption handles media. Live Transcribe handles real-time room captioning. A persistent, low-friction “always available room captioning” companion that logs context and respects power budget is mostly missing.

2. Routing visibility, surfaced by every audio app

Twenty lines of code per app. Pays back as cumulative platform trust.

3. Audiologist-facing summary layer

Patients use companion apps; audiologists use clinical software. The bridge between them — an at-clinic-visit summary of the patient’s last two weeks of hearing experience, generated from companion-app data — is a B2B2C opportunity that nobody has nailed.

4. Accessibility-first voice assistants

Voice assistants (Assistant, Bixby, Siri) optimise for voice-first interaction. Multi-modal accessibility — visual response by default for hearing-loss users, voice optional — is uneven across platforms.

5. Captions everywhere, including third-party video

Live Caption handles native playback. The in-app embedded-video story is still inconsistent. A horizontal caption-injection SDK that works across video frameworks would have meaningful adoption.

Where hearing accessibility on Android is going

Three predictions for 2027:

1. LE Audio + Auracast adoption hits an inflection point. Hearing-aid users stop having to ask whether a venue or app supports them; it becomes the default.
2. Mid-tier devices catch up. The LE Audio rollout on mid-tier hardware becomes mainstream, expanding the accessible user base by 100M+.
3. Companion-app + clinical-dashboard B2B2C products consolidate. The handful of small companies in this space today either consolidate or get acquired into hearing-aid manufacturer suites.

Related

• Designing hearing support without medicalising it
• The accessibility audio market is bigger than people think
• Android audio development guide
• Live Caption on Android — what it does and doesn’t do
• Hearing-aid routing through Android Audio Framework

Get involved

HearLab is onboarding design partners across the patient, audiologist, and hearing-centre tiers. The Android-native companion app is in private beta. If you work in audiological care or hearing-device manufacturing, or you live with hearing loss and want to shape what we build — get in touch.