Le développement audio sur Android en 2026 : le guide de l’ingénieur

Bâtir de l’audio sur Android voulait dire, autrefois, concevoir en contournant la plateforme. En 2026, cela revient surtout à utiliser la plateforme, tout en sachant quels recoins exigent encore un travail défensif. Voici le guide concret de l’ingénieur sur l’état de l’audio Android aujourd’hui, ce vers quoi se tourner en premier, et là où se cachent encore les surprises.

C’est le troisième des articles piliers d’AudioLab.tools, après Qu’est-ce que l’IA audio ? et L’infrastructure vocale par IA en 2026. La structure : des couches du bas vers le haut, ce qui fonctionne, ce qui mord, ce sur quoi bâtir.

La pile, depuis la base

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

Au-dessus d’AAudio se trouvent des frameworks de plus haut niveau : JUCE, Superpowered, Tarsos, Oboe-direct et, de plus en plus capable, WebAudio-via-WebView pour les applications hybrides. Sous la HAL, la matrice de routage audio d’Android gère la sélection de la destination (haut-parleur, BT, USB, appareil auditif via ASHA/LE Audio).

Le message le plus important de ce guide : utilisez AAudio (via Oboe), pas OpenSL ES. OpenSL ES fonctionne encore mais n’est plus pris en charge et ne vous apporte rien qu’AAudio ne fournisse déjà.

AAudio : ce que c’est, ce que ça vous apporte

AAudio est l’API native de Google pour l’audio à faible latence. Apparue dans Android 8.0, elle a nettement mûri à partir de la 12+. En 2026, c’est la seule API audio temps réel à envisager pour tout nouveau travail sur Android.

Ce que vous obtenez

• Mode exclusif : un chemin direct vers la HAL audio avec la latence la plus faible possible. La latence aller-retour sur les appareils haut de gamme se situe désormais entre 3 et 8 ms.
• Mode partagé : le mode par défaut. Latence plus élevée (15–40 ms) mais fonctionne partout et ne nécessite pas d’accès exclusif.
• Indications de mode de performance : LOW_LATENCY, NONE, POWER_SAVING. La plateforme sélectionne les tailles de buffer en conséquence.
• Négociation du taux d’échantillonnage : vous pouvez demander un taux ; la plateforme peut vous en donner un autre. Vérifiez toujours.
• Attributs audio : usage, content type, source. Pilotent le routage, le ducking et le comportement d’accessibilité.

Ce qui mord encore

• La latence aller-retour varie énormément d’un appareil à l’autre. Les fleurons Pixel et Galaxy sont excellents ; certains appareils de milieu de gamme sont encore dans la plage des 30–80 ms.
• Le mode de performance n’est pas garanti. Demander LOW_LATENCY est une indication, pas une promesse. Vérifiez toujours que la taille de buffer obtenue correspond à celle demandée.
• Le routage Bluetooth est toujours plus lent que le filaire. LE Audio a réduit l’écart de façon notable ; les appareils antérieurs à LE Audio paient encore 60–120 ms de latence BT.
• Le mode Doze et les économiseurs de batterie tueront ou mettront en pause votre thread audio. Testez avec l’économiseur de batterie activé. Toujours.

Oboe : le bon wrapper

Utilisez Oboe. C’est le wrapper C++ béni par Google autour d’AAudio (avec un repli sur OpenSL ES pour les appareils très anciens, que vous pouvez ignorer en 2026).

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

Quelques règles qui ne figurent pas dans la documentation aussi clairement qu’elles le devraient :

Le thread audio ne fait que le travail du thread audio

Pas d’allocations. Pas de verrous mutex. Pas d’appels JNI vers Java. Pas de logging dans le chemin chaud. Pas d’E/S fichier. Lire un état partagé exige des files lock-free. Écrire un état partagé exige la même chose de l’autre côté. Le thread audio est en priorité temps réel ; tout ce qui le bloque provoque des glitches.

Rechargement à chaud des paramètres via des files lock-free

Le motif qui passe à l’échelle : une structure de paramètres en triple buffer ou en buffer circulaire, dans laquelle le thread UI écrit et depuis laquelle le thread audio lit. Quand l’utilisateur déplace un curseur, le thread UI écrit la nouvelle valeur ; le thread audio la récupère au prochain callback. Pas de verrous, pas d’allocations.

La récupération est de votre responsabilité

Le thread audio peut être arrêté, mis en pause ou redémarré par l’OS à tout moment. Transfert Bluetooth, écran éteint, casque débranché, mode Doze, préemption du mode exclusif : tout cela termine ou interrompt votre stream. Votre code doit détecter ces situations et redémarrer proprement.

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 : quand le multiplateforme compte

Pour une application qui doit être livrée sur Android et iOS et macOS et Windows, JUCE est la voie de moindre résistance. Le code DSP est le même ; JUCE gère la mise en route audio spécifique à chaque plateforme.

En 2026, JUCE sur Android s’appuie sur Oboe sous le capot. Les performances sont bonnes, l’abstraction multiplateforme tient pour la plupart des cas d’usage, et le scénario de création de plugins audio (VST/AU/AAX) est mature.

Quand ne pas utiliser JUCE sur Android :

• Vous ne ciblez qu’Android.
• Vous voulez une taille de binaire minimale (JUCE ajoute plusieurs Mo).
• Vous devez vous intégrer en profondeur à des API spécifiques à Android (MIDI 2.0 sur Android, pilotes de classe audio USB, fonctionnalités de HAL audio personnalisées). Les abstractions de JUCE fuient ici.

Pour une application audio ciblée, uniquement Android, Oboe + votre propre harnais C++ minimal est plus rapide, plus léger et plus flexible.

Budgets de latence

Des chiffres réels issus de matériel haut de gamme en 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

Ce sont des chiffres haut de gamme ; le matériel de milieu de gamme ajoute 10–20 ms partout. Testez sur votre matrice réelle d’appareils cibles.

La règle des applications audio temps réel : la latence ne compte que là où l’utilisateur la remarque. Un accordeur de guitare a besoin de moins de 15 ms. Un pad de batterie de moins de 30 ms. Un lecteur de musique peut accepter 150 ms. Une application de méditation accepte 500 ms. Concevez pour votre budget réel, pas pour le chiffre théorique le plus bas.

L’audio Bluetooth en 2026

Le scénario de l’audio Bluetooth a changé de manière notable depuis le déploiement de LE Audio en 2024.

Bluetooth classique (A2DP)

Encore utilisé partout. Le codec SBC est la base ; AAC est pris en charge par la plupart des appareils ; aptX HD et LDAC offrent une qualité supérieure. La latence est le problème perpétuel : A2DP n’a pas de véritable mode à faible latence.

LE Audio (Bluetooth 5.2+)

Le scénario de 2024–2026. Codec LC3, faible latence (~10–30 ms), prise en charge du broadcast (Auracast), streaming direct vers les appareils auditifs. L’adoption est généralisée sur les fleurons ; le déploiement s’étend au milieu de gamme.

Pour tout nouveau développement, concevez en supposant que LE Audio est disponible, mais en repliant élégamment sur A2DP.

Auracast

Audio diffusé publiquement via LE. Une source unique diffuse vers de nombreux appareils, y compris des appareils auditifs. L’infrastructure se déploie dans les aéroports, les centres de congrès et les lieux dotés d’aides à l’écoute. Encore les débuts, mais une capacité significative pour les applications soucieuses d’accessibilité.

ASHA (Audio Streaming for Hearing Aids)

Le profil de style propriétaire que Google a conçu pour le streaming direct vers les appareils auditifs. Encore utilisé pour les appareils auditifs antérieurs à LE Audio. À supposer présent aux côtés de LE Audio dans toute application de soutien auditif pour les prochaines années.

Voir L’accessibilité auditive sur Android pour la plongée plus approfondie dans le routage vers les appareils auditifs.

Le framework audio en Java/Kotlin

Au-dessus de la couche native, les AudioManager + MediaRouter Java/Kotlin d’Android vous offrent la surface de routage. Les API importantes :

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 pilote les décisions de routage et le comportement de ducking. Le régler correctement fait toute la différence entre votre audio routé vers l’appareil auditif de l’utilisateur via ASHA et votre audio routé vers le haut-parleur du téléphone. Faites-le bien.

L’ensemble complet : USAGE_MEDIA, USAGE_VOICE_COMMUNICATION, USAGE_ASSISTANCE_ACCESSIBILITY, USAGE_NOTIFICATION_RINGTONE, USAGE_ALARM, etc. Utilisez le plus spécifique.

Microphone, capture et effets

Pour la capture audio :

• Utilisez AAudioStream avec Direction::Input et les mêmes indications de mode de performance qu’en sortie.
• Pour des besoins de plus haut niveau (enregistrer vers un fichier avec des effets intégrés), MediaRecorder + AudioEffect est la voie Java. Moins flexible, mais couvre les cas courants.
• AcousticEchoCanceler, NoiseSuppressor, AutomaticGainControl existent en tant qu’effets système. La qualité varie selon l’appareil ; pour un travail sérieux, ne vous y fiez pas et utilisez une bibliothèque tierce.

Pour des effets en temps réel sur l’audio capturé :

• Capture → entrée AAudio → votre DSP → sortie AAudio
• Cibles de latence aller-retour : moins de 20 ms est acceptable pour le monitoring, moins de 10 ms pour le tracking.

MIDI 2.0

Android a adopté MIDI 2.0 dans la 13. D’ici 2026, c’est la voie recommandée pour tout nouveau travail MIDI. JUCE le prend en charge ; les API de la plateforme sont stables.

Pour la plupart des applications audio, MIDI 1.0 convient. Pour les contrôleurs matériels modernes, USB-MIDI 2.0 est le bon choix.

Énergie, Doze et audio en arrière-plan

Audio temps réel + arrière-plan = un filet de pièges :

• Un foreground service avec FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK maintient le thread audio en vie.
• Sans lui, le thread audio sera mis en pause ou tué en arrière-plan.
• Le mode Doze et l’économiseur de batterie sont agressifs. Testez avec les deux activés.
• App standby buckets : votre application peut tomber dans un état restreint si elle n’est pas utilisée pendant des jours. L’audio en arrière-plan se dégrade dans ces états.

Pour la lecture de musique en arrière-plan, MediaSession + ExoPlayer est la bonne pile. Pour le travail DSP en arrière-plan : foreground service + AAudio.

La chose que personne ne met en avant

Le motif que je ne cesse de signaler dans cette série : le morceau d’UX le plus utile pour toute application audio Android, et surtout pour une application utilisée par des utilisateurs en situation d’accessibilité, est de montrer à l’utilisateur où va son audio.

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

L’API MediaRouter vous donne cette information. L’afficher vous coûte 20 lignes de code. Presque aucune application grand public ne le fait. C’est l’un des gains les plus faciles à la portée d’un développeur audio Android en 2026.

Ce que nous avons bâti

HearLab Companion est l’application compagnon Android pensée d’abord pour l’accessibilité. Elle utilise AAudio pour l’audio de sous-titrage à faible latence, MediaRouter pour la visibilité du routage et les API d’accessibilité standard pour le rendu des sous-titres. Non médicale par conception : voir Concevoir un soutien auditif sans le médicaliser pour le cadre.

La feuille de route couvre :

• La visualisation du routage ASHA + LE Audio dans l’application compagnon
• La journalisation en arrière-plan de l’audio environnemental avec un duty cycling économe en batterie
• Une couche de tableau de bord destinée aux audiologistes (B2B2C)

Où va l’audio Android

Trois prédictions pour 2027 :

1. LE Audio remplace A2DP dans l’usage grand public courant. Déjà en cours ; sera quasi achevé sur les fleurons d’ici mi-2027.
2. L’audio diffusé Auracast devient une surface d’accessibilité standard dans les lieux publics. L’infrastructure est en avance sur les applications.
3. L’écart de latence du milieu de gamme se résorbe sensiblement. Que les appareils Android de milieu de gamme rattrapent les fleurons sur la latence aller-retour est une histoire de 12 à 18 mois.

Liens connexes

• DSP temps réel sur Android : ce qu’AAudio réussit : l’aperçu d’origine d’AAudio
• L’accessibilité auditive sur Android : article pilier jumeau
• WebAudio contre natif : où se situe réellement la frontière en 2026
• Routage des appareils auditifs via le framework audio Android

Impliquez-vous

Nous recrutons des opinions, pas des postes. Si vous travaillez dans l’audio Android à quelque niveau que ce soit (audio de jeu, applications musicales, accessibilité, broadcast, conférence) et que vous pensez que ce guide se trompe, contactez-nous. Nous mettons le document à jour à mesure que la plateforme évolue.