Android-Audioentwicklung im Jahr 2026: der Leitfaden für Entwickler

Audio auf Android zu bauen bedeutete früher, um die Plattform herum zu entwerfen. Im Jahr 2026 bedeutet es vor allem, die Plattform zu nutzen, und zu wissen, welche Ecken noch defensive Arbeit erfordern. Dies ist der praxisnahe Entwicklerleitfaden dazu, wo Android-Audio heute steht, wozu man zuerst greift und wo die Überraschungen noch lauern.

Es ist das dritte Säulenstück von AudioLab.tools, nach Was ist Audio-KI? und KI-Sprachinfrastruktur im Jahr 2026. Der Aufbau: Schichten von niedrig nach hoch, was funktioniert, was beißt, worauf man aufbaut.

Der Stack, von Grund auf

Your code
  ↓
AAudio / Oboe (recommended)         OR  OpenSL ES (legacy, not recommended)
  ↓
Audio HAL / Audio Server
  ↓
Audio drivers + DSP firmware
  ↓
Speaker / headphones / Bluetooth / hearing device

Über AAudio liegen Frameworks höherer Ebene: JUCE, Superpowered, Tarsos, Oboe-direct und das zunehmend leistungsfähige WebAudio-via-WebView für Hybrid-Apps. Unterhalb der HAL übernimmt die Audio-Routing-Matrix von Android die Zielauswahl (Speaker, BT, USB, Hörgerät via ASHA/LE Audio).

Die wichtigste Botschaft dieses Leitfadens: Nutze AAudio (über Oboe), nicht OpenSL ES. OpenSL ES funktioniert noch, wird aber nicht unterstützt und gibt dir nichts, was AAudio nicht bereits bietet.

AAudio: was es ist, was es dir gibt

AAudio ist Googles native API für Audio mit niedriger Latenz. Eingeführt in Android 8.0, deutlich gereift ab 12+. Im Jahr 2026 ist es die einzige Echtzeit-Audio-API, die du für neue Android-Arbeit in Betracht ziehen solltest.

Was du bekommst

• Exklusiver Modus: ein direkter Pfad zur Audio-HAL mit der geringstmöglichen Latenz. Die Round-Trip-Latenz auf Flaggschiffgeräten liegt jetzt bei 3–8 ms.
• Geteilter Modus: der Standard. Höhere Latenz (15–40 ms), funktioniert aber überall und erfordert keinen exklusiven Zugriff.
• Hinweise zum Performance-Modus: LOW_LATENCY, NONE, POWER_SAVING. Die Plattform wählt die Puffergrößen entsprechend.
• Aushandlung der Sample-Rate: du kannst eine Rate anfordern; die Plattform kann dir eine andere geben. Immer prüfen.
• Audio-Attribute: usage, content type, source. Steuert Routing, Ducking und Barrierefreiheitsverhalten.

Was noch beißt

• Die Round-Trip-Latenz schwankt stark zwischen Geräten. Pixel- und Galaxy-Flaggschiffe sind exzellent; manche Mid-Tier-Geräte liegen noch im Bereich von 30–80 ms.
• Der Performance-Modus ist nicht garantiert. Nach LOW_LATENCY zu fragen ist ein Hinweis, kein Versprechen. Verifiziere immer, dass die erhaltene Puffergröße dem entspricht, was du angefordert hast.
• Bluetooth-Routing ist immer noch langsamer als kabelgebunden. LE Audio hat die Lücke spürbar verkleinert; Geräte aus der Zeit vor LE Audio zahlen noch 60–120 ms BT-Latenz.
• Doze-Modus und Energiesparmodi werden deinen Audio-Thread töten oder pausieren. Teste mit aktiviertem Energiesparmodus. Immer.

Oboe: der richtige Wrapper

Nutze Oboe. Es ist der von Google gesegnete C++-Wrapper um AAudio (mit OpenSL-ES-Fallback für sehr alte Geräte, den du 2026 ignorieren kannst).

#include <oboe/Oboe.h>

class AudioCallback : public oboe::AudioStreamCallback {
  oboe::DataCallbackResult onAudioReady(
      oboe::AudioStream *stream,
      void *audioData,
      int32_t numFrames) override {
    auto *out = static_cast<float*>(audioData);
    // Fill buffer. No allocations, no locks, no JNI calls in this thread.
    return oboe::DataCallbackResult::Continue;
  }
};

oboe::AudioStreamBuilder builder;
builder.setDirection(oboe::Direction::Output)
       ->setPerformanceMode(oboe::PerformanceMode::LowLatency)
       ->setSharingMode(oboe::SharingMode::Exclusive)
       ->setFormat(oboe::AudioFormat::Float)
       ->setChannelCount(oboe::ChannelCount::Stereo)
       ->setCallback(&callback);

oboe::AudioStream *stream;
oboe::Result result = builder.openStream(&stream);
stream->requestStart();

Ein paar Regeln, die in der Dokumentation nicht so klar stehen, wie sie sollten:

Der Audio-Thread erledigt nur die Aufgabe des Audio-Threads

Keine Allokationen. Keine Mutex-Locks. Keine JNI-Calls nach Java. Kein Logging im heißen Pfad. Keine Datei-I/O. Das Lesen gemeinsam genutzten Zustands erfordert lock-free Queues. Das Schreiben gemeinsam genutzten Zustands erfordert dasselbe auf der anderen Seite. Der Audio-Thread läuft mit Echtzeit-Priorität; alles, was ihn blockiert, verursacht Glitches.

Hot Reload von Parametern über lock-free Queues

Das Muster, das skaliert: ein triple-buffered oder ring-buffered Parameter-Struct, in das der UI-Thread schreibt und aus dem der Audio-Thread liest. Wenn der Nutzer einen Regler bewegt, schreibt der UI-Thread den neuen Wert; der Audio-Thread greift ihn beim nächsten Callback auf. Keine Locks, keine Allokationen.

Wiederherstellung liegt in deiner Verantwortung

Der Audio-Thread kann jederzeit vom OS gestoppt, pausiert oder neu gestartet werden. Bluetooth-Handoff, Bildschirm aus, Kopfhörer getrennt, Doze-Modus, Verdrängung aus dem exklusiven Modus: all das beendet oder unterbricht deinen Stream. Dein Code muss dies erkennen und sauber neu starten.

oboe::DataCallbackResult onAudioReady(...) {
  // ...
  return shouldContinue ? Continue : Stop;
}

void onErrorAfterClose(oboe::AudioStream *stream, oboe::Result error) {
  // Re-open and resume — your reconnect logic lives here.
}

JUCE: wenn plattformübergreifend zählt

Für eine App, die auf Android und iOS und macOS und Windows ausliefern muss, ist JUCE der Weg des geringsten Widerstands. Der DSP-Code ist derselbe; JUCE übernimmt das plattformspezifische Audio-Bring-up.

Im Jahr 2026 setzt JUCE auf Android unter der Haube auf Oboe. Die Performance ist gut, die plattformübergreifende Abstraktion hält für die meisten Anwendungsfälle, und die Geschichte rund um das Authoring von Audio-Plugins (VST/AU/AAX) ist ausgereift.

Wann du JUCE auf Android nicht nutzen solltest:

• Du zielst nur auf Android ab.
• Du willst eine minimale Binärgröße (JUCE fügt mehrere MB hinzu).
• Du musst tief in Android-spezifische APIs integrieren (MIDI 2.0 auf Android, USB-Audio-Class-Treiber, eigene Audio-HAL-Features). JUCEs Abstraktionen sind hier undicht.

Für eine fokussierte, ausschließlich auf Android ausgerichtete Audio-App ist Oboe + dein eigenes minimales C++-Gerüst schneller, kleiner und flexibler.

Latenzbudgets

Echte Zahlen von Flaggschiff-Hardware im Jahr 2026:

Path	Round-trip latency
Wired headphones + LowLatency + Exclusive	3–8 ms
Wired headphones + LowLatency + Shared	15–25 ms
Bluetooth A2DP (legacy)	60–250 ms
Bluetooth LE Audio	10–30 ms
USB-C wired DAC	8–18 ms
Built-in speaker	30–60 ms
AVB / Dante via USB	5–15 ms

Das sind Flaggschiffzahlen; Mid-Tier-Hardware fügt durchweg 10–20 ms hinzu. Teste auf deiner tatsächlichen Matrix von Zielgeräten.

Die Regel für Echtzeit-Audio-Apps: Latenz zählt nur dort, wo der Nutzer sie bemerkt. Ein Gitarrenstimmgerät braucht unter 15 ms. Ein Drum-Pad unter 30 ms. Ein Musikplayer kann 150 ms akzeptieren. Eine Meditations-App akzeptiert 500 ms. Entwirf für dein tatsächliches Budget, nicht für die niedrigste theoretische Zahl.

Bluetooth-Audio im Jahr 2026

Die Geschichte von Bluetooth-Audio hat sich seit dem Rollout von LE Audio im Jahr 2024 wesentlich verändert.

Klassisches Bluetooth (A2DP)

Noch überall im Einsatz. Der SBC-Codec ist die Basis; AAC wird von den meisten Geräten unterstützt; aptX HD und LDAC bieten höhere Qualität. Latenz ist das ewige Problem: A2DP hat keinen echten Modus mit niedriger Latenz.

LE Audio (Bluetooth 5.2+)

Die Geschichte von 2024–2026. LC3-Codec, niedrige Latenz (~10–30 ms), Broadcast-Unterstützung (Auracast), direktes Streaming an Hörgeräte. Die Verbreitung ist auf Flaggschiffen Mainstream; der Rollout über die Mid-Tier läuft.

Entwirf für neue Entwicklung unter der Annahme, dass LE Audio verfügbar ist, falle aber elegant auf A2DP zurück.

Auracast

Öffentliches Broadcast-Audio über LE. Eine einzelne Quelle streamt an viele Geräte, einschließlich Hörgeräten. Die Infrastruktur wird an Flughäfen, in Kongresszentren und an Orten mit Höranlagen ausgerollt. Noch frühe Tage, aber eine bedeutsame Fähigkeit für barrierefreiheitsbewusste Anwendungen.

ASHA (Audio Streaming for Hearing Aids)

Das Profil im Proprietary-Stil, das Google für direktes Streaming an Hörgeräte gebaut hat. Noch im Einsatz für Hörgeräte aus der Zeit vor LE Audio. Sollte in den nächsten Jahren in jeder App zur Hörunterstützung neben LE Audio vorausgesetzt werden.

Siehe Barrierefreiheit beim Hören auf Android für den tieferen Einstieg ins Routing zu Hörgeräten.

Das Audio-Framework in Java/Kotlin

Über der nativen Schicht geben dir Androids Java/Kotlin AudioManager + MediaRouter die Routing-Oberfläche. Die wichtigen APIs:

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

val routerInfo = MediaRouter.getInstance(context).selectedRoute
// routerInfo.deviceType — speaker, headset, BT, hearing aid

USAGE steuert Routing-Entscheidungen und Ducking-Verhalten. Das korrekt einzustellen ist der Unterschied zwischen deinem Audio, das über ASHA an das Hörgerät des Nutzers geroutet wird, und deinem Audio, das an den Telefonlautsprecher geht. Mach das richtig.

Der vollständige Satz: USAGE_MEDIA, USAGE_VOICE_COMMUNICATION, USAGE_ASSISTANCE_ACCESSIBILITY, USAGE_NOTIFICATION_RINGTONE, USAGE_ALARM usw. Nutze das spezifischste.

Mikrofon, Aufnahme und Effekte

Für Audioaufnahme:

• Nutze AAudioStream mit Direction::Input und denselben Hinweisen zum Performance-Modus wie bei der Ausgabe.
• Für Bedürfnisse höherer Ebene (Aufnahme in eine Datei mit eingebauten Effekten) ist MediaRecorder + AudioEffect der Java-Pfad. Weniger flexibel, deckt aber die gängigen Fälle ab.
• AcousticEchoCanceler, NoiseSuppressor, AutomaticGainControl existieren als Systemeffekte. Die Qualität variiert je nach Gerät; verlass dich für ernsthafte Arbeit nicht darauf und nutze eine Drittanbieter-Bibliothek.

Für Echtzeiteffekte auf aufgenommenem Audio:

• Capture → AAudio-Input → dein DSP → AAudio-Output
• Zielwerte für die Round-Trip-Latenz: unter 20 ms ist für Monitoring akzeptabel, unter 10 ms für Tracking.

MIDI 2.0

Android übernahm MIDI 2.0 in 13. Bis 2026 ist es der empfohlene Pfad für neue MIDI-Arbeit. JUCE unterstützt es; die Plattform-APIs sind stabil.

Für die meisten Audio-Apps ist MIDI 1.0 in Ordnung. Für moderne Hardware-Controller ist USB-MIDI 2.0 die richtige Wahl.

Power, Doze und Hintergrund-Audio

Echtzeit-Audio + Hintergrund = ein Rinnsal an Footguns:

• Ein Foreground Service mit FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK hält den Audio-Thread am Leben.
• Ohne ihn wird der Audio-Thread im Hintergrund pausiert oder getötet.
• Doze-Modus und Energiesparmodus sind aggressiv. Teste mit beiden eingeschaltet.
• App Standby Buckets: deine App kann in einen eingeschränkten Zustand fallen, wenn sie tagelang nicht genutzt wird. Hintergrund-Audio verschlechtert sich in diesen Zuständen.

Für das Abspielen von Hintergrundmusik ist MediaSession + ExoPlayer der richtige Stack. Für DSP-Arbeit im Hintergrund: Foreground Service + AAudio.

Das, was niemand zur Sprache bringt

Das Muster, das ich in dieser Serie immer wieder hervorhebe: das nützlichste Stück UX für jede Android-Audio-App (und besonders für eine, die von Nutzern mit Barrierefreiheitsbedarf verwendet wird) ist, dem Nutzer zu zeigen, wohin sein Audio geht.

Streaming via LE Audio → [Device name]
Or: Streaming via wired → headphones
Or: Streaming via speaker

Die MediaRouter-API liefert dir diese Information. Sie anzuzeigen kostet dich 20 Codezeilen. Fast keine Consumer-App tut es. Das ist einer der leichteren Gewinne, die einem Android-Audio-Entwickler im Jahr 2026 zur Verfügung stehen.

Was wir gebaut haben

HearLab Companion ist die barrierefreiheitsorientierte Android-Begleit-App. Sie nutzt AAudio für Untertitel-Audio mit niedriger Latenz, MediaRouter für die Sichtbarkeit des Routings und die Standard-Barrierefreiheits-APIs für das Rendern der Untertitel. Nicht-medizinisch konzipiert. Siehe Hörunterstützung entwerfen, ohne sie zu medikalisieren für den Rahmen.

Die Roadmap umfasst:

• Visualisierung des ASHA- + LE-Audio-Routings in der Begleit-App
• Hintergrund-Logging von Umgebungsaudio mit batterieschonendem Duty Cycling
• Eine Dashboard-Ebene für Audiologen (B2B2C)

Wohin sich Android-Audio entwickelt

Drei Vorhersagen für 2027:

1. LE Audio ersetzt A2DP im Mainstream-Konsumentengebrauch. Bereits im Gange; wird auf Flaggschiffen bis Mitte 2027 nahezu abgeschlossen sein.
2. Auracast-Broadcast-Audio wird zu einer Standard-Barrierefreiheitsoberfläche an öffentlichen Orten. Die Infrastruktur ist den Anwendungen voraus.
3. Die Latenzlücke in der Mid-Tier schließt sich wesentlich. Dass Mid-Tier-Android-Geräte die Flaggschiffe bei der Round-Trip-Latenz einholen, ist eine Geschichte von 12–18 Monaten.

Verwandt

• Echtzeit-DSP auf Android: was AAudio richtig macht (die ursprüngliche AAudio-Übersicht)
• Barrierefreiheit beim Hören auf Android (verwandtes Säulenstück)
• WebAudio versus native: wo die Grenze im Jahr 2026 wirklich liegt
• Hörgeräte-Routing durch das Android Audio Framework

Mach mit

Wir stellen Meinungen ein, keine Stellen. Wenn du auf irgendeiner Ebene mit Android-Audio arbeitest (Game-Audio, Musik-Apps, Barrierefreiheit, Broadcast, Konferenzen) und du denkst, dieser Leitfaden liegt falsch, dann melde dich. Wir aktualisieren das Dokument, während sich die Plattform verändert.