Naar inhoud
AudioLab .tools
Inloggen

/insights · Engineering

Android-audio-ontwikkeling in 2026: de engineergids

Een praktische engineergids voor het bouwen van serieuze audio op Android in 2026. Behandelt AAudio, Oboe, JUCE, latency-budgetten, routering naar hoortoestellen, AudioWorklet-equivalenten en de delen van het platform die eindelijk gewoon werken.

5 juni 2026 22 min read androidaaudiooboerealtime audiopillardspengineering

Audio bouwen op Android betekende vroeger dat je om het platform heen moest ontwerpen. In 2026 betekent het vooral dat je hét platform gebruikt, en weet welke hoeken nog defensief werk vergen. Dit is de praktische engineergids over waar Android-audio vandaag staat, waar je als eerste naar grijpt en waar de verrassingen nog leven.

Het is het derde pijlerstuk van AudioLab.tools, in navolging van Wat is audio-AI? en AI-spraakinfrastructuur in 2026. De opzet: lagen van laag naar hoog, wat werkt, wat bijt, waarop je voortbouwt.

De stack, van de grond af

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

Boven AAudio zitten frameworks van een hoger niveau: JUCE, Superpowered, Tarsos, Oboe-direct en het steeds capabelere WebAudio-via-WebView voor hybride apps. Onder de HAL handelt de audiorouteringsmatrix van Android de bestemmingsselectie af (speaker, BT, USB, hoortoestel via ASHA/LE Audio).

De allerbelangrijkste boodschap van deze gids: gebruik AAudio (via Oboe), niet OpenSL ES. OpenSL ES werkt nog steeds, maar wordt niet ondersteund en biedt je niets wat AAudio niet al levert.

AAudio: wat het is, wat het je geeft

AAudio is Googles native API voor audio met lage latency. Geïntroduceerd in Android 8.0, sterk uitgerijpt in 12+. In 2026 is het de enige realtime-audio-API die je voor nieuw Android-werk zou moeten overwegen.

Wat je krijgt

  • Exclusieve modus: een direct pad naar de audio-HAL met de laagst mogelijke latency. De round-trip-latency op vlaggenschiptoestellen ligt nu op 3–8 ms.
  • Gedeelde modus: de standaard. Hogere latency (15–40 ms) maar werkt overal en vereist geen exclusieve toegang.
  • Hints voor de performance-modus: LOW_LATENCY, NONE, POWER_SAVING. Het platform kiest de buffergroottes daarop af.
  • Onderhandeling over de samplerate: je kunt een rate aanvragen; het platform kan je een andere geven. Controleer altijd.
  • Audio-attributen: usage, content type, source. Bepaalt routering, ducking en toegankelijkheidsgedrag.

Wat nog bijt

  • Round-trip-latency varieert enorm tussen toestellen. Pixel- en Galaxy-vlaggenschepen zijn uitstekend; sommige mid-tier-toestellen zitten nog in de 30–80 ms-range.
  • De performance-modus is niet gegarandeerd. Om LOW_LATENCY vragen is een hint, geen belofte. Verifieer altijd dat de buffergrootte die je kreeg overeenkomt met wat je vroeg.
  • Bluetooth-routering is nog steeds trager dan bedraad. LE Audio heeft het gat aanzienlijk verkleind; toestellen van vóór LE Audio betalen nog 60–120 ms BT-latency.
  • Doze-modus en batterijbesparing zullen je audiothread doden of pauzeren. Test met batterijbesparing aan. Altijd.

Oboe: de juiste wrapper

Gebruik Oboe. Het is de door Google gezegende C++-wrapper rond AAudio (met OpenSL ES als fallback voor heel oude toestellen, die je in 2026 kunt negeren).

#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();

Een paar regels die niet zo helder in de documentatie staan als zou moeten:

De audiothread doet alleen het werk van de audiothread

Geen allocaties. Geen mutex-locks. Geen JNI-calls naar Java. Geen logging in het hete pad. Geen file-I/O. Het lezen van gedeelde state vereist lock-free queues. Het schrijven van gedeelde state vereist hetzelfde aan de andere kant. De audiothread draait op realtime-prioriteit; alles wat hem blokkeert veroorzaakt glitches.

Hot reload van parameters via lock-free queues

Het patroon dat schaalt: een triple-buffered of ring-buffered parameter-struct waar de UI-thread naartoe schrijft en waaruit de audiothread leest. Wanneer de gebruiker een slider verschuift, schrijft de UI-thread de nieuwe waarde; de audiothread pikt die op bij de volgende callback. Geen locks, geen allocaties.

Herstel is jouw verantwoordelijkheid

De audiothread kan op elk moment door het OS gestopt, gepauzeerd of herstart worden. Bluetooth-handoff, scherm uit, hoofdtelefoon losgekoppeld, doze-modus, preëmptie van de exclusieve modus: al deze dingen beëindigen of onderbreken je stream. Je code moet dit detecteren en netjes herstarten.

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: wanneer cross-platform telt

Voor een app die op Android én iOS én macOS én Windows moet uitkomen, is JUCE de weg van de minste weerstand. De DSP-code is dezelfde; JUCE handelt de platformspecifieke audio-bring-up af.

In 2026 richt JUCE op Android zich onder de motorkap op Oboe. De performance is goed, de cross-platform-abstractie houdt stand voor de meeste use cases, en het verhaal rond het auteursrecht van audioplugins (VST/AU/AAX) is volwassen.

Wanneer je JUCE op Android niet moet gebruiken:

  • Je richt je alleen op Android.
  • Je wilt een minimale binary-grootte (JUCE voegt enkele MB toe).
  • Je moet diep integreren met Android-specifieke API’s (MIDI 2.0 op Android, USB audio class drivers, eigen audio-HAL-features). JUCE’s abstracties lekken hier.

Voor een gefocuste, Android-only audio-app is Oboe + je eigen minimale C++-harnas sneller, kleiner en flexibeler.

Latency-budgetten

Echte cijfers van vlaggenschiphardware in 2026:

PathRound-trip latency
Wired headphones + LowLatency + Exclusive3–8 ms
Wired headphones + LowLatency + Shared15–25 ms
Bluetooth A2DP (legacy)60–250 ms
Bluetooth LE Audio10–30 ms
USB-C wired DAC8–18 ms
Built-in speaker30–60 ms
AVB / Dante via USB5–15 ms

Dit zijn vlaggenschipcijfers; mid-tier-hardware voegt over de hele linie 10–20 ms toe. Test op je daadwerkelijke matrix van doeltoestellen.

De regel voor realtime-audio-apps: latency telt alleen waar de gebruiker het opmerkt. Een gitaarstemapparaat heeft minder dan 15 ms nodig. Een drumpad minder dan 30 ms. Een muziekspeler kan 150 ms accepteren. Een meditatie-app accepteert 500 ms. Ontwerp voor je werkelijke budget, niet voor het laagste theoretische getal.

Bluetooth-audio in 2026

Het verhaal van Bluetooth-audio is sinds de uitrol van LE Audio in 2024 wezenlijk veranderd.

Klassiek Bluetooth (A2DP)

Nog overal in gebruik. De SBC-codec is de basislijn; AAC wordt door de meeste toestellen ondersteund; aptX HD en LDAC zijn van hogere kwaliteit. Latency is het eeuwige probleem; A2DP heeft geen echte lagelatentiemodus.

LE Audio (Bluetooth 5.2+)

Het verhaal van 2024–2026. LC3-codec, lage latency (~10–30 ms), broadcast-ondersteuning (Auracast), directe streaming naar hoortoestellen. De adoptie is mainstream op vlaggenschepen; de uitrol over de mid-tier loopt.

Ontwerp voor nieuwe ontwikkeling in de veronderstelling dat LE Audio beschikbaar is, maar val elegant terug op A2DP.

Auracast

Publieke broadcast-audio over LE. Eén bron streamt naar veel toestellen, inclusief hoortoestellen. De infrastructuur wordt uitgerold op luchthavens, in congrescentra en in luisterondersteunende locaties. Nog vroege dagen, maar een betekenisvolle mogelijkheid voor toegankelijkheidsbewuste toepassingen.

ASHA (Audio Streaming for Hearing Aids)

Het profiel in proprietary-stijl dat Google bouwde voor directe streaming naar hoortoestellen. Nog in gebruik voor hoortoestellen van vóór LE Audio. Moet de komende jaren naast LE Audio worden verondersteld in elke app voor hoorondersteuning.

Zie Hoortoegankelijkheid op Android voor de diepere duik in de routering naar hoortoestellen.

Het Audio Framework in Java/Kotlin

Boven de native laag geven Android’s Java/Kotlin AudioManager + MediaRouter je het routeringsoppervlak. De belangrijke API’s:

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 stuurt routeringsbeslissingen en ducking-gedrag aan. Dit correct instellen is het verschil tussen je audio die via ASHA naar het hoortoestel van de gebruiker wordt gerouteerd en je audio die naar de telefoonspeaker gaat. Krijg dit goed voor elkaar.

De volledige set: USAGE_MEDIA, USAGE_VOICE_COMMUNICATION, USAGE_ASSISTANCE_ACCESSIBILITY, USAGE_NOTIFICATION_RINGTONE, USAGE_ALARM, enzovoort. Gebruik de meest specifieke.

Microfoon, opname en effecten

Voor audio-opname:

  • Gebruik AAudioStream met Direction::Input en dezelfde hints voor de performance-modus als bij output.
  • Voor behoeften van een hoger niveau (opnemen naar bestand met ingebouwde effecten) is MediaRecorder + AudioEffect het Java-pad. Minder flexibel, maar dekt de gangbare gevallen.
  • AcousticEchoCanceler, NoiseSuppressor, AutomaticGainControl bestaan als systeemeffecten. De kwaliteit verschilt per toestel; vertrouw er voor serieus werk niet op en gebruik een externe bibliotheek.

Voor realtime-effecten op opgenomen audio:

  • Capture → AAudio-input → jouw DSP → AAudio-output
  • Doelwaarden voor round-trip-latency: onder 20 ms is acceptabel voor monitoring, onder 10 ms voor tracking.

MIDI 2.0

Android nam MIDI 2.0 over in 13. Tegen 2026 is het het aanbevolen pad voor nieuw MIDI-werk. JUCE ondersteunt het; de platform-API’s zijn stabiel.

Voor de meeste audio-apps is MIDI 1.0 prima. Voor moderne hardwarecontrollers is USB-MIDI 2.0 de juiste keuze.

Power, doze en achtergrondaudio

Realtime-audio + achtergrond = een stroompje footguns:

  • Een foreground service met FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK houdt de audiothread in leven.
  • Zonder die service wordt de audiothread op de achtergrond gepauzeerd of gedood.
  • Doze-modus en batterijbesparing zijn agressief. Test met beide aan.
  • App standby buckets: je app kan in een beperkte staat belanden als hij dagenlang niet wordt gebruikt. Achtergrondaudio verslechtert in die staten.

Voor het afspelen van achtergrondmuziek is MediaSession + ExoPlayer de juiste stack. Voor DSP-werk op de achtergrond: foreground service + AAudio.

Het ding dat niemand naar boven haalt

Het patroon dat ik in deze serie steeds blijf aanstippen: het nuttigste stukje UX voor elke Android-audio-app (en zeker een die door toegankelijkheidsgebruikers wordt gebruikt) is de gebruiker laten zien waar hun audio naartoe gaat.

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

De MediaRouter-API geeft je deze informatie. Het tonen ervan kost je 20 regels code. Bijna geen enkele consumentenapp doet het. Dit is een van de makkelijkere winsten die in 2026 beschikbaar zijn voor een Android-audio-ontwikkelaar.

Wat we hebben gebouwd

HearLab Companion is de toegankelijkheid-eerst Android-begeleidingsapp. Hij gebruikt AAudio voor captioning-audio met lage latency, MediaRouter voor zichtbaarheid van de routering en de standaard toegankelijkheids-API’s voor het renderen van bijschriften. Niet-medisch van opzet; zie Hoorondersteuning ontwerpen zonder het te medicaliseren voor het kader.

De roadmap omvat:

  • ASHA + LE Audio-routeringsvisualisatie in de begeleidingsapp
  • Achtergrondlogging van omgevingsaudio met batterijvriendelijke duty cycling
  • Een dashboardlaag gericht op audiologen (B2B2C)

Waar Android-audio naartoe gaat

Drie voorspellingen voor 2027:

  1. LE Audio vervangt A2DP in het mainstream consumentengebruik. Al gaande; zal tegen medio 2027 op vlaggenschepen vrijwel compleet zijn.
  2. Auracast-broadcast-audio wordt een standaard toegankelijkheidsoppervlak op publieke locaties. De infrastructuur loopt voor op de toepassingen.
  3. Het latency-gat in de mid-tier sluit zich wezenlijk. Dat mid-tier-Android-toestellen de vlaggenschepen inhalen op round-trip-latency is een verhaal van 12–18 maanden.

Verwant

Doe mee

We nemen meningen aan, geen functies. Werk je op welk niveau dan ook met Android-audio (game-audio, muziek-apps, toegankelijkheid, broadcast, conferencing) en vind je dat deze gids fout zit, neem dan contact op. We werken het document bij naarmate het platform verandert.

More in Engineering