Connexion Gemini en cache-first, OkHttp singleton + DNS préchauffé, AudioRecord pré-initialisé, buffer circulaire du micro, Baseline Profile.
Android · Wear OS · Voix · 02/11
Brain Addon
« Souvenirs » — Wear OS
Une voix d'IA sur la paume, en direct, avec Gemini Live. Je l'ai optimisée pour se lancer en 1 à 2 secondes au lieu de 5 à 14.
Comment ça est né
Igor tourne sur le VPS, mais moi, je bouge. Il me fallait une présence d'Igor là où je suis vraiment : sur la montre, à la paume, sans sortir le téléphone. Brain Addon, surnommé « Souvenirs », c'est cette voix d'Igor sur Wear OS — pilotée au poignet, en temps réel, avec Gemini Live qui fait la compréhension et la synthèse dans la même connexion.
Le projet a été dominé par une seule obsession : la latence au démarrage. Il fallait 5 à 14 secondes avant que la voix réponde, et ça cassait l'expérience — à ce moment, tu as déjà oublié ta question. J'ai passé un temps énorme à comprendre où partait ce temps, et à l'enlever.
Le contexte
Brain Addon est la présence d'Igor sur Wear OS : une voix d'IA en direct, pilotée au poignet. Gemini Live fait la compréhension et la synthèse vocales dans une même session temps réel, avec barge-in — on peut couper la voix de l'IA en parlant.
Le problème de départ était la latence au démarrage : 5 à 14 secondes avant la première réponse. J'ai analysé six goulots — attente du téléphone, configuration du relay, connexion WebSocket, négociation du profil, ouverture du micro, et le warmup du cold start — et j'ai attaqué un par un, en mesurant.
Le résultat : un démarrage « instant » qui met la voix en écoute en 1 à 2 secondes. Le micro s'ouvre en mode buffer circulaire avant même la fin du Setup, la connexion Gemini part en cache-first (OkHttp singleton + DNS préchauffé), et le chemin rapide n'attend plus le cold start grâce au Baseline Profile.
Autour de la voix, il y a un vrai système : reconnexion transparente quand le réseau bouge, notifications push via FCM avec un service de notification en foreground (SSE) et un Service Worker VAPID côté web, des personas multiples (Igor, Coach, Socrate, Debug) qui changent de voix et de prompt en direct, et la capacité de piloter le téléphone par tap-écran depuis la montre.
Le point dur
Faire descendre le démarrage de 5-14 s à 1-2 s sur Wear OS
Le démarrage d'une app Wear OS est dominé par le cold start : chargement des classes, initialization du framework, setup du composant. Sur une montre, c'est long, et la voix n'a aucun moyen d'exister avant. J'ai attaqué trois fronts à la fois : le Baseline Profile pour éliminer le JIT cold-start, l'AudioRecord pré-initialisé pour que le micro soit prêt avant que le reste ne le soit, et un buffer circulaire PCM qui capture l'audio avant même que la session ne soit ouverte — ainsi les premiers mots ne sont pas perdus.
Le deuxième point dur, c'est la fiabilité du temps réel : une connexion WebSocket qui coupe pendant que tu parles, c'est une voix qui meurt. J'ai dû construire une reconnexion transparente qui ré-attache la session sans perdre le contexte de la conversation, et un mécanisme qui garde le dernier état vocal en cache pour que le retour soit immédiat.
Fonctionnalités
Compréhension et synthèse vocales dans une même session temps réel, avec barge-in (on peut couper la voix de l'IA en parlant).
Quand le réseau bouge, la session se reconnecte sans perdre le contexte de la conversation.
Service de notification en foreground (SSE), cinq canaux sonores, réception au démarrage, Service Worker VAPID côté web. Cible de latence sous la seconde.
Changement de voix et de prompt en direct, piloté par des mots-clés. Le fichier personas.json alimente l'API et l'indicateur du header.
Depuis la montre, des actions tapent sur l'écran du téléphone pour piloter l'app, sans le sortir de la poche.
Arbitrages techniques
Buffer audio avant la session ouverte
Ne jamais perdre les premiers mots du user. Contrepartie : De la mémoire en cache, et un chemin de discard quand la session échoue.
Cache-first Gemini
Ne pas attendre le cold start de la connexion. Contrepartie : Il faut maintenir un état réutilisable et le valider à chaque ouverture.
Service de notification en foreground (SSE)
Les push FCM sont batchés et lents ; un SSE tenu en foreground est quasi instantané. Contrepartie : Une batterie consommée par un service permanent — j'ai dû équilibrer avec des wake-ups ciblés.
Personas pilotées par mots-clés
Changer de voix sans UI, en restant à la voix. Contrepartie : Les mots-clés doivent être disjoints et prévisibles, sinon c'est instable.
Stack technique
KotlinWear OS · Compose
RéseauOkHttp · WebSocket · FCM
VoixGemini Live · buffer PCM circulaire
PerfBaseline Profile · cache-first
NotificationsSSE foreground · VAPID
UImode clair / sombre · personas.json
En chiffres
1-2 sdémarrage (avant : 5-14 s)
0personas
<1 slatence notification cible
0canaux sonores
0goulots attaqués
Parcours du projet
-
V1
App Wear OS de base, client WebSocket, voix Gemini, mode clair.
-
V2 fast-launch
Cache-first Gemini (~1-2 s), OkHttp singleton, AudioStreamer preInit, reconnexion transparente.
-
V2 notifications
Service de notification foreground (SSE), FCM, 5 canaux, BootReceiver, Service Worker VAPID.
-
Personas
personas.json, switch live voix + prompt par mots-clés, reconnexion Gemini, historique persona.
-
V3 instant startup
Buffer audio avant SetupComplete, auto-connect avant Compose, Baseline Profile, chemin rapide sans cold start.
Ce que ça a rendu
-
01
Voix quasi instantanée
Démarrage en 1-2 s au lieu de 5-14 — l'expérience n'est plus cassée par le délai.
-
02
Présence en mobilité
Igor est à la paume, en direct, avec des personas — pas juste une puce de notification.
-
03
Brique de l'écosystème
Brain Addon est le front wearable d'Igor ; il consomme le même noyau que le web et Tether.