Utviklingsdagbok

I 2026 er det fortsatt overraskende vanskelig å få en søvnapp til å spille hele natten

Av Colin Hanson · 13. oktober 2026 · 7 minutters lesing

Jeg ville at telefonen skulle lage viftelyd til morgenen. I 2026 virket det som et ganske løst problem. Likevel har det tatt overraskende mye av utviklertiden min.

Jeg brukte White Noise Lite i årevis. Reklame og et grensesnitt som føltes urgammelt, men det fungerte stort sett. Så begynte det å stoppe ofte. Jeg tenkte på det som krasj, uten logger som kunne forklare årsaken. Jeg ønsket også et moderne grensesnitt og lyd generert på enheten i stedet for opptak, med presise innstillinger. Til slutt laget jeg Veil og forsto pålitelighetsproblemet mye bedre.

På iOS var bakgrunnsavspilling relativt enkelt, og Veil har etter min erfaring vært stabil fra starten. Android ble et lengre prosjekt: ulik maskinvare, eldre telefoner med lite minne, produsentenes batteristyring og oppdateringer midt i lyttingen. Min egen kode hadde også feil. For den som våkner klokken tre, betyr forskjellen lite.

Krasjrapporter var ikke nok. En drept prosess rapporterer kanskje ikke et unntak, og en levende prosess kan ha en stille lydstrøm. Selv en forgrunnstjeneste med avspillingsvarsel beviser ikke lyd fra høyttaleren. Jeg la til en innebygd avspillingsjournal, prosessavslutninger, minnemålinger, tjenestestatus, lydhendelser og tydelige registreringer av bevisste stopp. Relevante data overlever prosessen og hentes ved en senere oppstart.

Jeg ville gjenskape nok av natten til å skille mulige årsaker. Var avspilling fortsatt ønsket? Var timeren ferdig? Vokste minnebruken? Ladet telefonen? Hadde Android erstattet pakken? Flere signaler hjalp når jeg forsto hva de faktisk viste.

Først måtte selve målingen rettes. Å sveipe bort Veil kunne stoppe lyden uten å lukke den registrerte økten. Android kunne rydde den bufrede prosessen timer senere, og rapporten telte det som avspillingsfeil. Et bevisst morgenstopp ble en «nattlig avslutning». Oppdateringer som faktisk avbrøt lyd, ble derimot utelatt som harmløse systemavslutninger.

Riktigere definisjoner endret bildet før flere lydrettelser. Jeg skiller nå mellom bedre avspilling og bedre måling. Jeg analyserer jevnlig etter versjon, enhetsfamilie, øktlengde og avslutningsårsak, uten testenheter og duplikater. Forsinkede rapporter betyr også noe: få korte økter beviser ikke at en versjon holder natten ut.

Mønstrene styrer testene. Jeg kjører lange tester og nattester på fysiske telefoner og i Samsungs fjernlaboratorium, med kontinuerlig logcat, måling av minne og minnepress og øyeblikksbilder av lyd og tjenester ved feil. Oppsettet samler bevis uten at jeg må se feilen selv.

Testoppsettet kan påvirke resultatet. USB gir strøm, så det er ikke en test uten lader. Gjentatt dumpsys meminfo kunne selv skape lydfeil. En problemfri natt viser bare at feilen ikke oppsto under de forholdene, ikke at alle enheter og systemtilstander er feilfrie.

Et merkelig funn var Android Auto Backup. På min Pixel viste systemloggene at BackupManager avsluttet Veil under sikkerhetskopiering mens lyden spilte. I installasjonsdata fant jeg 190 SIGKILL av beskyttede prosesser på 93 installasjoner fra 14. august til 11. september 2026, ofte med omtrent tre dagers mellomrom. Det støttet sikkerhetskopieringsforklaringen uten å bevise hvert tilfelle.

Jeg slo av Auto Backup og aksepterte kompromisset med gjenoppretting fra skyen. Android dokumenterer at sikkerhetskopiering stopper appen, men normalt unntar apper i forgrunnen. Sporingen på enheten gjorde dette til et konkret tilfelle jeg kunne handle på. Androids dokumentasjon om sikkerhetskopiering

Andre feil var mine. Lydgjenoppretting kunne bygge en ny kontekst før den gamle var lukket, slik at ressurser overlappet mens appen allerede hadde problemer. Nå avventes lukking med tidsgrense, og gjenoppretting og avspillingsoperasjoner skjer etter hverandre. Nyere brukervalg gjelder: et stopp mens en reparasjon venter, må ikke oppheves av reparasjonen.

Et rettingsforsøk ga en ny feil. En kontroll på 150 ms sjekket om lydklokken gikk fremover og fant fastlåste kontekster som hevdet å være aktive. Men den ventet på en JavaScript-timer. I bakgrunnen kunne ventingen bli hengende til appen kom tilbake til forgrunnen. Kontrollen kjører nå bare i forgrunnen. Også gjenoppretting må testes med skjermen av.

Noen viktige endringer var produktvalg. Målinger viste omtrent 90 MB ekstra resident minne knyttet til reklamens WebView-prosess. Tidligere undersøkelser fant også alvorlige SDK-relaterte minnefeil. Først forsøkte jeg å begrense belastningen, deretter fjernet jeg reklame og SDK helt. For en app som skal gå hele natten var pålitelighet viktigere.

Telemetrien manglet om personen forventet stoppet. Etter et relevant avbrudd kan Veil vise et kort med tidspunktet og spørre «Forventet du dette?». Ordvalget er bevisst. «Stoppet du lyden?» overser en partner som stoppet, eller et forventet avbrudd uten egen handling.

Et forventet stopp fører ikke til batterifeilsøking. Ellers anerkjenner appen avbruddet og gir hjelp ut fra tilgjengelige bevis. Svaret beskriver opplevelsen uten å påstå en teknisk årsak. Nye Android-brukere slipper også å bli møtt med skremmende tillatelser og en skattejakt i batteriinnstillingene.

Innstillingene er vanskelige fra begge sider. Jeg kan åpne dem eller be om et unntak når det passer, men brukeren bestemmer. Androids unntak styrer heller ikke all opprydding fra produsentene. Et konkret trinn etter et problem hjelper mer enn ukjente innstillinger før første lyd. Androids veiledning om strømstyring

Oppdateringer er spesielt frustrerende. Jeg kan vise Plays automatiske oppdatering per app, men Veil styrer den ikke. Manuelle oppdateringer gir ekstra arbeid, og Google har unntak for kritiske sikkerhetsoppdateringer. En oppdatering for mer pålitelige netter kan selv avbryte natten. Oppdateringsinnstillinger i Google Play

Automatisk gjenoppretting etter oppdateringer er ennå ikke ferdig. Utover lydgrafen må timerstatus og brukerhensikt bevares riktig. Noen produsentmønstre trenger bedre reproduksjon før jeg kan forklare dem sikkert. Appen skal komme seg etter feil, ikke kjempe mot et bevisst stopp.

Mest fremgang kom fra regelmessig analyse, lange tester, målrettede rettelser og direkte tilbakemeldinger sammen. Hver del finner det de andre overser. Jeg bryr meg mindre om appen sier den spiller, og mer om bevisene. Den som trykker spill før leggetid, skal kunne stole på det, selv om det tok mer arbeid enn forventet.