Udviklingsdagbog

I 2026 er det stadig overraskende svært at få en søvnapp til at spille hele natten

Af Colin Hanson · 13. oktober 2026 · 7 minutters læsning

Jeg ville have min telefon til at lave ventilatorlyd indtil morgen. I 2026 virkede det som et nogenlunde løst problem. Alligevel har det kostet overraskende meget udviklingstid.

I årevis brugte jeg White Noise Lite. Der var reklamer og en efter min mening ældgammel brugerflade, men det virkede som regel. Så begyndte det jævnligt at stoppe. Jeg opfattede det som nedbrud uden at have logs til at kende årsagen. Jeg ønskede også en moderne brugerflade og lyd genereret på telefonen frem for optagelser, med præcise indstillinger. Til sidst byggede jeg Veil og forstod problemet med driftssikkerhed langt bedre.

På iOS var baggrundsafspilning relativt ligetil, og efter min erfaring har Veil været stabil fra starten. Android tog længere tid: forskellig hardware, ældre telefoner med lidt hukommelse, producenternes batteristyring og opdateringer midt i lytningen. Min egen kode havde også fejl. For den, der vågner klokken tre, betyder forskellen ikke meget.

Nedbrudsrapporter var ikke nok. En dræbt proces rapporterer måske ingen undtagelse, og en levende proces kan have en lydløs strøm. Selv en forgrundstjeneste med afspilningsnotifikation beviser ikke lyd fra højttaleren. Jeg tilføjede en indbygget afspilningsjournal, procesafslutninger, hukommelsesmålinger, tjenestestatus, lydhændelser og udtrykkelige registreringer af bevidste stop. Relevante data overlever processen og indsamles ved en senere start.

Jeg ville rekonstruere nok af natten til at skelne mulige årsager. Var afspilning stadig ønsket? Var timeren færdig? Voksede hukommelsen? Ladede telefonen? Havde Android erstattet pakken? Flere signaler hjalp, når jeg forstod deres betydning.

Først måtte jeg rette målingen. At swipe Veil væk kunne stoppe lyden uden at lukke den registrerede session. Android kunne rydde den cachede proces timer senere, og rapporten talte det som afspilningsfejl. Et bevidst morgenstop blev et ”natligt stop”. Opdateringer, der faktisk afbrød lyd, blev derimod frasorteret som harmløse systemafslutninger.

Bedre definitioner ændrede billedet før flere lydrettelser. Jeg skelner nu mellem bedre afspilning og bedre måling. Jeg analyserer jævnligt efter version, enhedsfamilie, sessionslængde og afslutningsårsag, uden testenheder og dubletter. Forsinkede rapporter tæller også: få korte sessioner beviser ikke, at en version holder natten ud.

Mønstrene styrer testene. Jeg kører lange og natlige tests på fysiske telefoner og i Samsungs fjernlaboratorium, med løbende logcat, hukommelses- og hukommelsestryksmålinger samt øjebliksbilleder af lyd og tjenester ved fejl. Opsætningen samler beviser, uden at jeg skal overvære fejlen.

Testen kan selv påvirke resultatet. USB leverer strøm, så det er ikke en test uden oplader. Gentagen dumpsys meminfo kunne selv give lydudfald. En fejlfri nat viser kun, at fejlen ikke opstod under de forhold, ikke at alle telefoner og systemtilstande er i orden.

En sær opdagelse var Android Auto Backup. På min Pixel viste systemlogs, at BackupManager afsluttede Veil under backup, mens lyd spillede. I installationsdata fandt jeg 190 SIGKILL af beskyttede processer på 93 installationer fra 14. august til 11. september 2026, ofte med omkring tre dages mellemrum. Det støttede backupforklaringen uden at bevise hvert tilfælde.

Jeg deaktiverede Auto Backup og accepterede kompromiset med gendannelse fra skyen. Android beskriver, at backup lukker appen, men normalt undtager apps i forgrunden. Sporingen på telefonen gjorde dette konkrete tilfælde muligt at handle på. Androids dokumentation om backup

Andre fejl var mine. Genopretning kunne opbygge en ny lydkontekst, før den gamle var lukket, så ressourcer overlappede under problemer. Nu afventes lukningen med tidsgrænse, og genopretning og afspilningsoperationer køres efter hinanden. Nyere brugerønsker gælder: et stop, mens en reparation venter, må ikke blive ophævet af reparationen.

En rettelse gav en ny fejl. En kontrol på 150 ms tjekkede, om lydkontekstens ur gik frem, og fandt fastlåste kontekster, der meldte sig aktive. Men den ventede på en JavaScript-timer. I baggrunden kunne ventetiden hænge, indtil appen kom frem igen. Kontrollen kører nu kun i forgrunden. Også genopretning skal testes med slukket skærm.

Nogle gode ændringer var produktbeslutninger. Målinger viste cirka 90 MB ekstra resident hukommelse knyttet til reklamernes WebView-proces. Tidligere undersøgelser havde også vist alvorlige SDK-relaterede hukommelsesfejl. Først begrænsede jeg belastningen, så fjernede jeg reklamer og SDK helt. Natlig driftssikkerhed var vigtigere.

Telemetrien manglede, om personen forventede stoppet. Efter en relevant afbrydelse kan Veil vise et kort med tidspunktet og spørge ”Forventede du det?”. Ordene er bevidste. ”Stoppede du lyden?” overser en partner, der stoppede, eller forventede afbrydelser uden egen handling.

Et forventet stop fører ikke til batterifejlfinding. Ellers anerkender appen afbrydelsen og tilbyder hjælp ud fra beviserne. Svaret beskriver oplevelsen uden at påstå en teknisk årsag. Nye Android-brugere slipper også for at blive mødt af skræmmende tilladelser og en skattejagt i batteriindstillingerne.

Indstillingerne er besværlige på begge sider. Jeg kan åbne dem eller anmode om en undtagelse, hvor det er relevant, men brugeren bestemmer. Androids undtagelse styrer heller ikke alle producenters oprydning. Et konkret trin efter et problem hjælper mere end ukendte indstillinger før den første lyd. Androids vejledning om strømstyring

Opdateringer er særligt frustrerende. Jeg kan vise Plays automatiske opdatering pr. app, men Veil styrer den ikke. Manuelle opdateringer giver ekstra arbejde, og Google har undtagelser for kritiske sikkerhedsopdateringer. En opdatering for bedre nætter kan selv afbryde natten. Opdateringsindstillinger i Google Play

Automatisk genoptagelse efter opdateringer er endnu ikke færdig. Ud over lydgrafen skal timerstatus og brugerhensigt bevares korrekt. Nogle producentmønstre kræver bedre reproduktion, før jeg kan forklare dem sikkert. Appen skal komme sig efter fejl, ikke bekæmpe en bevidst standsning.

Mest fremskridt kom fra regelmæssig analyse, lange tests, målrettede rettelser og direkte feedback sammen. Hver del finder det, de andre overser. Jeg interesserer mig mindre for, om appen siger, at den spiller, og mere for beviserne. Den, der trykker afspil før sengetid, skal kunne stole på det, selv om det tog mere arbejde end forventet.