/docs · HearLab · Deep

Hörgeräte-Routing durch das Android Audio Framework

Wie AAudio, ASHA und LE Audio Audio auf modernem Android tatsächlich an Hörgeräte ausliefern.

Audio von einem Telefon an ein Hörgerät zu streamen, klingt nach einem längst gelösten Problem. Wir schreiben das Jahr 2026; Bluetooth gibt es seit einer Ewigkeit. Trotzdem ist die Routing-Schicht einer der überraschendsten Teile des Android-Stacks, und gerade die Teile, die gut funktionieren, blendet keine Consumer-App ein.

Dies ist eine praxisnahe Landkarte davon, wie das Android Audio Framework an Hörgeräte routet, wofür jede Schicht gut ist und wo du tatsächlich Code schreiben musst, wenn du Apps zur Hörunterstützung baust.

Die Schichten, von oben nach unten

App
 ↓
AudioManager / AudioAttributes
 ↓
AAudio / OpenSL ES        ← realtime path
 ↓
Audio HAL
 ↓
Android Bluetooth stack   ← ASHA, LE Audio, Classic A2DP/HFP
 ↓
Hearing device

Jede Schicht hat ihre eigenen Eigenheiten. Zu wissen, wo du deinen Code schreiben musst, ist die halbe Miete.

ASHA: der beständige Platzhirsch

ASHA (Audio Streaming for Hearing Aids) war Googles 2018er-Ergänzung des Bluetooth-Stacks für direktes Streaming an Hörgeräte. Es ist ein Profil mit proprietärem Charakter, aber gut dokumentiert, und es bildet die Grundlage für die meisten derzeit erhältlichen “Made for Android”-Hörgeräte.

Was funktioniert:

Latenzarme Mono-Streams mit 16 kHz (Sprachqualität) oder Stereo mit höheren Samplerates.
Direkt vom Telefon zum Hörgerät, kein zwischengeschaltetes Gerät erforderlich.
Zuverlässige Akkulaufzeit auf der Hörgeräteseite (das Profil ist auf einen niedrigen Duty-Cycle optimiert).
Integration in Medien- und Anruf-Streams über AudioAttributes.USAGE_VOICE_COMMUNICATION oder USAGE_MEDIA.

Was nicht funktioniert:

Die Qualität ist auf Sprache ausgelegt, nicht auf Musik. Ein Podcast über ASHA klingt großartig; eine Filmmusik klingt komprimiert.
Nur ein Gerät gleichzeitig pro Stream. Binaurale Paare werden auf der Seite des Hörgeräteherstellers gehandhabt, nicht vom OS.
Eine Steuerung von Codec oder Stream-Profil durch die App fehlt praktisch vollständig.

LE Audio: die Zukunft, größtenteils angekommen

LE Audio (Bluetooth 5.2+, LC3-Codec, BAP-Profil) ist der neue Standard. Es steckt in ausgelieferter Hardware der meisten Android-Flaggschiffe und in einem wachsenden Anteil der Mittelklasse. Seit Ende 2025 ist es mainstream genug, dass ein ernstzunehmendes Produkt zur Hörunterstützung es einplanen muss.

Was sich ändert:

Der LC3-Codec ist deutlich besser als SBC und bei der Musikqualität konkurrenzfähig mit AAC, dabei aber effizienter.
Multi-Stream-Unterstützung: Stereo an ein binaurales Paar ohne den herstellerspezifischen Kleber.
Broadcast Audio (Auracast) erlaubt es einer einzigen Quelle, an viele Geräte zu streamen. Das ist die Grundlage für assistive listening in öffentlichen Räumen.
Bessere Akkulaufzeit auf beiden Seiten.

Was immer noch hakt:

Die Hardware-Unterstützung ist uneinheitlich. Ältere Geräte erhalten LE Audio nicht per OS-Update.
Die Routing-UI auf OS-Ebene reift noch.
Die Auracast-Verbreitung in öffentlichen Räumen steckt in den Anfängen.

Wo du tatsächlich Code schreibst

Für eine App zur Hörunterstützung ist die Integrationsfläche kleiner, als es scheint. Drei Punkte:

1. `AudioAttributes.USAGE`

Setze dies korrekt auf deinen Medien- oder Anruf-Streams. Das OS routet anhand der Usage:

val attrs = AudioAttributes.Builder()
    .setUsage(AudioAttributes.USAGE_VOICE_COMMUNICATION)
    .setContentType(AudioAttributes.CONTENT_TYPE_SPEECH)
    .build()

Für den Untertitelmodus von HearLab ist USAGE_ASSISTANCE_ACCESSIBILITY die richtige Wahl, das ist der Kanal, den das OS für Barrierefreiheits-Audio nutzt.

2. `MediaRouter` zur Erkennung von Ausgabegeräten

Wenn du wissen willst, ob der Nutzer ein Hörgerät gekoppelt hat und welche Fähigkeiten es besitzt:

val router = MediaRouter.getInstance(context)
val info = router.selectedRoute
// info.deviceType tells you if it's a hearing aid
// info.supportedTypes tells you what the device can do

Geh nicht von Annahmen aus, prüfe es. Eine überraschende Zahl von Apps streamt an den Standardausgang, ohne das Hörgerät des Nutzers zu berücksichtigen.

3. AAudio für niedrige Latenz, wo du sie brauchst

Für Echtzeit-Untertitelung, Verarbeitung auf Audio-Rate oder alles, bei dem die Round-Trip-Latenz zählt, nutze AAudio direkt (oder Oboe als Wrapper). Der System-Audiostack fügt eine Pufferung hinzu, die AAudio umgeht.

AAudioStreamBuilder *builder = nullptr;
AAudio_createStreamBuilder(&builder);
AAudioStreamBuilder_setDirection(builder, AAUDIO_DIRECTION_OUTPUT);
AAudioStreamBuilder_setSharingMode(builder, AAUDIO_SHARING_MODE_EXCLUSIVE);
AAudioStreamBuilder_setPerformanceMode(builder, AAUDIO_PERFORMANCE_MODE_LOW_LATENCY);

Dies routet nicht direkt an ein Hörgerät (das Routing wird eine Schicht höher entschieden), aber es verschafft dir das Audio-Thread-Budget, das du für Echtzeitarbeit brauchst.

Das, was niemand einblendet

Die mit Abstand nützlichste UI für eine Hörgeräteträgerin lautet: “Wohin geht mein Audio gerade eigentlich?” Das Android-OS hat diese Information; niemand zeigt sie an.

Wenn du die einfachste Version eines Banners zum Routing-Status baust (“Streamt an: [Gerätename] über [LE Audio / ASHA / kabelgebunden / Lautsprecher]”) und ihn einblendest, sobald die App im Vordergrund ist, bist du sofort jeder Consumer-App voraus, die ich getestet habe.

Genau das zeigt HearLab Companion standardmäßig an. Technisch ist es nicht schwierig. Der Rest der Branche macht sich nur nicht die Mühe.