Journal de développement

En 2026, faire tourner une application de sommeil toute la nuit reste étonnamment difficile

Par Colin Hanson · 13 octobre 2026 · 7 min de lecture

Je voulais que mon téléphone fasse un bruit de ventilateur jusqu’au matin. En 2026, cela me semblait être un problème à peu près résolu. Pourtant, il m’a pris un temps surprenant en tant que développeur.

Pendant des années, j’ai utilisé White Noise Lite. Il y avait des publicités et une interface qui me paraissait d’un autre âge, mais l’application fonctionnait généralement, et c’était l’essentiel. Puis elle s’est mise à s’arrêter régulièrement. Je pensais à des plantages, sans avoir les journaux pour savoir ce qui se passait. Je voulais aussi une interface moderne et du son généré sur l’appareil plutôt qu’un enregistrement, avec des réglages précis. J’ai fini par créer Veil, et j’ai beaucoup mieux compris le problème de la fiabilité.

Sur iOS, la lecture en arrière-plan a été relativement simple à mettre en place et, d’après mon expérience, Veil est très stable depuis le début. Android a demandé bien plus de travail. Le matériel est très varié, avec des téléphones anciens et peu de mémoire, des politiques de batterie propres aux fabricants et, parfois, une mise à jour en pleine écoute. Mon propre code avait aussi sa part de problèmes. Pour quelqu’un qui se réveille à trois heures du matin, la différence importe peu.

J’ai commencé par les rapports de plantage, mais il m’a vite fallu davantage de contexte. Un processus tué peut ne jamais signaler d’exception, et un processus vivant peut avoir un flux audio silencieux. Même un service au premier plan et une notification de lecture ne prouvent pas que le haut-parleur émet du son. J’ai ajouté un journal natif de lecture, les informations de fin de processus, des mesures mémoire, l’état du service, les événements des flux audio et des traces explicites des arrêts volontaires. Les données utiles survivent au processus et sont récupérées lors d’un lancement ultérieur.

Il fallait reconstituer assez précisément la nuit pour départager les causes possibles. La lecture était-elle toujours souhaitée ? Le minuteur avait-il expiré ? La mémoire augmentait-elle ? Le téléphone était-il branché ? Android avait-il remplacé le paquet de l’application ? Chaque signal supplémentaire aidait, à condition de comprendre ce qu’il pouvait réellement m’apprendre.

L’une des premières choses à déboguer a été la mesure elle-même. Retirer Veil des applications récentes pouvait arrêter le son sans clore correctement la session enregistrée. Android pouvait récupérer le processus en cache des heures plus tard, et mes rapports comptaient cela comme une panne de lecture. Un arrêt volontaire le matin devenait un « arrêt nocturne ». À l’inverse, les mises à jour interrompant une véritable lecture étaient exclues comme des fins de processus normales.

Corriger ces définitions a changé le tableau des pannes avant même de réparer davantage de code audio. Depuis, je distingue soigneusement une amélioration de la lecture d’une amélioration de sa mesure. Je reviens régulièrement sur les données par version, famille d’appareils, durée de session et motif d’arrêt, en excluant les appareils de test et les doublons. Les retards de remontée comptent aussi : quelques sessions courtes sur une nouvelle version ne disent pas si elle tient toute une nuit.

Ces tendances orientent les tests sur appareils. J’ai effectué des essais prolongés et nocturnes sur de vrais téléphones, ainsi que des sessions dans le laboratoire distant Samsung, avec logcat en continu, échantillonnage de la mémoire et de la pression mémoire, et captures de l’état audio et des services en cas de panne. Le dispositif collecte les preuves sans que je doive surprendre personnellement le téléphone au moment du problème.

J’ai aussi appris que le dispositif de test peut modifier le résultat. L’USB alimente le téléphone : un essai par USB n’est donc pas un test sur batterie débranchée. Exécuter dumpsys meminfo de façon répétée pouvait lui-même provoquer des défauts audio. Et une nuit sans incident prouve seulement que je n’ai pas reproduit la panne dans ces conditions. C’est utile, mais cela ne valide pas tous les appareils ni tous les états du système.

L’une des découvertes les plus étranges concernait Android Auto Backup. Sur mon Pixel, les journaux système ont montré BackupManager tuant le processus de Veil pendant une sauvegarde, alors que le son jouait. Dans les données du parc, j’ai trouvé 190 SIGKILL de processus protégés sur 93 installations, entre le 14 août et le 11 septembre 2026, avec des récurrences proches de trois jours. Ce schéma étayait l’hypothèse de la sauvegarde sans prouver la cause de chaque arrêt.

J’ai désactivé Auto Backup pour Veil, en acceptant le compromis sur la restauration depuis le cloud. Android indique que la sauvegarde arrête l’application tout en excluant normalement les applications au premier plan ; la trace sur l’appareil a rendu ce cas précis exploitable. Documentation des sauvegardes Android

D’autres problèmes relevaient de mon code. La reprise audio pouvait créer un nouveau contexte avant que l’ancien ait fini de se fermer, faisant coexister des ressources alors que l’application était déjà en difficulté. J’ai rendu la fermeture attendue et limitée dans le temps, puis sérialisé la reprise avec les opérations de lecture. La reprise doit aussi respecter les intentions plus récentes : si l’utilisateur appuie sur arrêt pendant qu’une réparation attend, celle-ci ne doit pas relancer le son.

Une tentative de correction a introduit une autre panne. J’ai ajouté une sonde de 150 ms pour vérifier que l’horloge du contexte audio avançait, afin de détecter un contexte bloqué malgré son état déclaré actif. Malheureusement, la sonde attendait un minuteur JavaScript. En arrière-plan, cette attente pouvait rester suspendue jusqu’au retour de l’application au premier plan. La sonde ne fonctionne désormais qu’au premier plan : une raison supplémentaire de tester les chemins de reprise écran éteint.

Certaines des modifications les plus utiles étaient des décisions produit. Les mesures sur appareil montraient environ 90 Mo de mémoire résidente supplémentaire liés au processus WebView publicitaire. Une enquête antérieure avait aussi révélé de graves problèmes mémoire liés au SDK. J’ai d’abord tenté de contenir ce coût, puis supprimé complètement les publicités et le SDK. Pour une application censée tourner toute la nuit, la fiabilité comptait davantage.

La télémétrie laissait une question essentielle sans réponse : la personne s’attendait-elle à l’arrêt ? Après une interruption pertinente, Veil peut afficher une petite carte avec l’heure et demander : « Tu t’attendais à cet arrêt ? » La formulation est volontaire. « Est-ce toi qui as arrêté le son ? » exclurait les cas où un partenaire l’a arrêté ou où l’interruption était attendue sans action de l’utilisateur.

Si l’arrêt était attendu, l’utilisateur n’est pas envoyé vers un dépannage de batterie. Sinon, l’application reconnaît l’interruption et propose une aide correspondant aux éléments disponibles. La réponse me renseigne directement sur l’expérience, sans prétendre identifier la cause technique. Cela évite aussi d’accueillir chaque nouvel utilisateur Android avec des autorisations inquiétantes et un jeu de piste dans les paramètres de batterie.

Ces réglages sont compliqués des deux côtés. Je peux ouvrir les paramètres ou demander une exemption lorsque c’est approprié, mais la décision reste à l’utilisateur. Le mécanisme d’exemption Android ne contrôle pas non plus toutes les fonctions de nettoyage des fabricants. Une étape précise après un problème est plus utile qu’une visite de paramètres inconnus avant même d’avoir écouté un son. Gestion de l’énergie sur Android

Les mises à jour sont particulièrement frustrantes. Je peux expliquer où se trouve le réglage de mise à jour automatique par application dans Play, mais Veil ne le contrôle pas. Gérer les mises à jour manuellement ajoute une corvée, et Google prévoit des exceptions pour les correctifs de sécurité critiques. Une mise à jour censée améliorer la fiabilité nocturne peut elle-même interrompre la nuit. Paramètres de mise à jour Google Play

La reprise automatique après une mise à jour reste un chantier. Reconstruire le graphe audio ne suffit pas : l’état du minuteur et l’intention de l’utilisateur doivent aussi être conservés correctement. Certains schémas propres à des fabricants demandent encore de meilleures reproductions avant que je puisse les expliquer avec assurance. Je veux que l’application se remette des pannes, pas qu’elle lutte contre quelqu’un qui l’a arrêtée volontairement.

Les progrès les plus utiles sont venus de l’association d’analyses récurrentes, de longs tests sur appareils, de corrections ciblées et de retours directs. Chacun révèle ce que les autres manquent. Je m’intéresse moins à l’affirmation « lecture en cours » qu’aux preuves qui la soutiennent. Quelqu’un qui lance un son au coucher devrait pouvoir s’y fier, même si y parvenir a demandé bien plus de travail que prévu.