Ontwikkeldagboek

Het is 2026, en een slaapapp de hele nacht laten spelen is nog verrassend lastig

Door Colin Hanson · 13 oktober 2026 · 7 minuten leestijd

Ik wilde dat mijn telefoon tot de ochtend een ventilatorgeluid maakte. In 2026 leek dat een redelijk opgelost probleem. Toch heeft het me als ontwikkelaar verrassend veel tijd gekost.

Jarenlang gebruikte ik White Noise Lite. Met advertenties en een voor mijn gevoel stokoude interface, maar meestal werkte het. Dat telde. Toen begon het regelmatig te stoppen. Ik noemde het crashes, zonder logs om de oorzaak te kennen. Ik wilde ook een moderne interface en geluid dat op het apparaat wordt gegenereerd in plaats van een opname, met nauwkeurige instellingen. Uiteindelijk bouwde ik Veil en begreep ik het betrouwbaarheidsprobleem veel beter.

Op iOS was achtergrondweergave relatief eenvoudig en is Veil naar mijn ervaring vanaf het begin erg stabiel. Android werd een langer project: allerlei hardware, oudere telefoons met weinig geheugen, accubeheer per fabrikant en soms een update midden in een luistersessie. Mijn eigen code had ook fouten. Voor iemand die om drie uur wakker wordt, maakt dat onderscheid weinig uit.

Crashrapporten waren het begin, maar ik had meer context nodig. Een beëindigd proces meldt misschien geen uitzondering; een levend proces kan een stille audiostream hebben. Zelfs een voorgrondservice met afspeelmelding bewijst geen geluid uit de luidspreker. Ik voegde een native afspeellogboek, procesuitgangsgegevens, geheugenmetingen, servicestatus, audio-events en expliciete registraties van bewuste stops toe. Relevante gegevens overleven het proces en worden bij een latere start verzameld.

Ik wilde genoeg van de nacht reconstrueren om mogelijke oorzaken te onderscheiden. Was afspelen nog de bedoeling? Was de timer klaar? Groeide het geheugen? Hing de telefoon aan de lader? Had Android het pakket vervangen? Meer signalen hielpen, mits ik hun betekenis begreep.

Eerst moest ik de meting repareren. Veil wegvegen kon audio stoppen zonder de geregistreerde sessie goed af te sluiten. Android kon uren later het gecachte proces opruimen, waarna mijn rapport dit als afspeelfout telde. Bewust stoppen in de ochtend werd een ‘nachtelijke kill’. Updates die echte weergave onderbraken werden juist als onschuldige systeemuitgangen uitgesloten.

Betere definities veranderden het beeld nog vóór verdere audiofixes. Sindsdien onderscheid ik betere weergave van betere meting. Ik analyseer regelmatig per versie, apparaatfamilie, sessieduur en stopreden, zonder testapparaten en dubbele meldingen. Vertraagde rapportage telt ook: een paar korte sessies bewijzen niet dat een nieuwe versie een nacht volhoudt.

Die patronen sturen de tests. Ik doe lange en nachtelijke tests op echte telefoons en sessies in Samsungs externe lab, met doorlopende logcat, geheugen- en geheugendrukmetingen en momentopnamen van audio en services bij fouten. De opstelling verzamelt bewijs zonder dat ik de fout zelf moet betrappen.

De test kan de uitkomst beïnvloeden. USB voedt de telefoon, dus dat is geen test op een losse accu. Herhaald dumpsys meminfo kon zelf audiostoringen veroorzaken. Een goede nacht betekent alleen dat de fout onder die omstandigheden niet optrad. Dat pleit niet ieder apparaat en iedere systeemtoestand vrij.

Een vreemde ontdekking was Android Auto Backup. Op mijn Pixel legden systeemlogs vast hoe BackupManager Veil tijdens een back-up beëindigde terwijl audio speelde. In de installatiegegevens vond ik 190 SIGKILLs van beschermde processen op 93 installaties, van 14 augustus tot 11 september 2026, vaak ongeveer drie dagen uit elkaar. Dat ondersteunde de back-upverklaring zonder ieder geval te bewijzen.

Ik schakelde Auto Backup uit en accepteerde de gevolgen voor cloudherstel. Android documenteert dat back-ups de app stoppen, terwijl voorgrondapps normaal worden overgeslagen. De registratie op het apparaat maakte dit specifieke geval concreet genoeg om aan te pakken. Android-documentatie over back-ups

Andere fouten waren van mij. Audioherstel kon een vervangende context opbouwen voordat de oude klaar was met sluiten. Dat stapelde bronnen op terwijl de app al problemen had. Afbouw wordt nu met een tijdslimiet afgewacht; herstel en afspeeloperaties verlopen na elkaar. Een nieuwere gebruikerskeuze gaat voor: stoppen tijdens een wachtende reparatie mag niet leiden tot opnieuw afspelen.

Een reparatiepoging veroorzaakte een nieuwe fout. Een controle van 150 ms keek of de audioklok vooruitging en ontdekte vastgelopen contexten die zichzelf actief noemden. Maar die controle wachtte op een JavaScript-timer. Op de achtergrond kon dat wachten blijven hangen tot de app weer zichtbaar was. Nu draait de controle alleen op de voorgrond. Ook herstelpaden moeten met uitgeschakeld scherm worden getest.

Sommige nuttige wijzigingen waren productbeslissingen. Metingen lieten ongeveer 90 MB extra resident geheugen bij het advertentie-WebView-proces zien. Eerder onderzoek vond al ernstige SDK-gerelateerde geheugenfouten. Eerst beperkte ik de kosten, daarna verwijderde ik advertenties en SDK volledig. Voor een app die de nacht moet doorkomen was betrouwbaarheid belangrijker.

Telemetrie vertelde nog niet of de persoon de stop verwachtte. Na een relevante onderbreking kan Veil een kaartje met tijdstip tonen en vragen: ‘Verwachtte je dit?’ Bewust niet ‘Heb jij gestopt?’, want een partner kan stoppen of een onderbreking kan verwacht zijn zonder eigen handeling.

Bij een verwachte stop volgt geen accuprobleemoplossing. Anders erkent de app de onderbreking en biedt hulp die bij het bewijs past. Het antwoord beschrijft de ervaring zonder de technische oorzaak te claimen. Zo hoef ik nieuwe Android-gebruikers niet meteen te ontvangen met alarmerende toestemmingen en een speurtocht door accu-instellingen.

Die instellingen zijn voor beide kanten lastig. Ik kan ze openen of waar passend een uitzondering aanvragen, maar de gebruiker beslist. Androids uitzondering beheerst ook niet elke opruimfunctie van fabrikanten. Een gerichte stap na een probleem helpt meer dan onbekende instellingen vóór het eerste geluid. Android-richtlijnen voor energiebeheer

Updates zijn extra frustrerend. Ik kan de automatische update-instelling per app in Play aanwijzen, maar Veil beheert die niet. Handmatig bijwerken kost moeite; Google houdt uitzonderingen voor kritieke beveiligingsupdates. Een update voor betere nachtelijke betrouwbaarheid kan zelf een nacht onderbreken. Google Play-update-instellingen

Automatisch herstel na updates is nog niet af. Naast de audiograaf moeten timerstatus en gebruikersintentie correct behouden blijven. Sommige fabrikantpatronen vragen betere reproductie voordat ik ze zeker kan verklaren. De app moet fouten herstellen, maar niet vechten tegen iemand die bewust stopte.

De meeste vooruitgang kwam uit regelmatige analyse, lange tests, gerichte fixes en directe feedback samen. Elke aanpak vindt wat de andere mist. Minder belangrijk is of de app zegt dat hij speelt; belangrijker is het bewijs. Wie voor het slapen op afspelen drukt, moet daarop kunnen vertrouwen, ook al kostte dat veel meer werk dan verwacht.