Utvecklingsdagbok

År 2026 är det fortfarande förvånansvärt svårt att låta en sömnapp spela hela natten

Av Colin Hanson · 13 oktober 2026 · 7 minuters läsning

Jag ville att telefonen skulle låta som en fläkt fram till morgonen. År 2026 verkade det ganska färdiglöst. Ändå har det tagit förvånansvärt mycket av min utvecklartid.

Jag använde White Noise Lite i flera år. Reklam och ett gränssnitt som kändes uråldrigt, men det fungerade oftast. Sedan började det stanna regelbundet. Jag tänkte på det som krascher, utan loggar som kunde förklara vad som hände. Jag ville också ha ett modernt gränssnitt och ljud genererat på enheten i stället för inspelningar, med precisa reglage. Till slut byggde jag Veil och förstod tillförlitlighetsproblemet mycket bättre.

På iOS var bakgrundsuppspelning relativt enkel och Veil har enligt min erfarenhet varit stabilt från början. Android tog längre tid: varierad hårdvara, äldre telefoner med lite minne, tillverkarnas batterihantering och uppdateringar mitt i lyssnandet. Min egen kod hade också fel. För den som vaknar klockan tre spelar skillnaden liten roll.

Kraschrapporter räckte inte. En dödad process kanske inte rapporterar något undantag, och en levande process kan ha en tyst ljudström. Inte ens en förgrundstjänst med uppspelningsnotis bevisar ljud från högtalaren. Jag lade till en inbyggd uppspelningsjournal, processavslut, minnesmätningar, tjänststatus, ljudhändelser och uttryckliga noteringar om avsiktliga stopp. Relevanta data överlever processen och samlas in vid en senare start.

Jag ville återskapa tillräckligt av natten för att skilja möjliga orsaker åt. Skulle ljudet fortfarande spela? Var timern klar? Ökade minnet? Laddades telefonen? Hade Android ersatt paketet? Fler signaler hjälpte när jag förstod vad de faktiskt visade.

Först behövde själva mätningen rättas. Att svepa bort Veil kunde stoppa ljudet utan att stänga den registrerade sessionen. När Android frigjorde den cachade processen timmar senare räknades det som ett uppspelningsfel. Ett avsiktligt morgonstopp blev ett ”nattligt avslut”. Samtidigt uteslöts uppdateringar som verkligen avbröt ljud som ofarliga systemavslut.

Bättre definitioner ändrade felbilden före fler ljudfixar. Jag skiljer nu noga på bättre uppspelning och bättre mätning. Jag analyserar regelbundet version, enhetsfamilj, sessionslängd och avslutsorsak, utan testenheter eller dubbletter. Fördröjda rapporter spelar också roll: några korta sessioner visar inte om en version klarar natten.

Mönstren styr enhetstesterna. Jag kör långa tester och nattester på riktiga telefoner och i Samsungs fjärrlabb, med kontinuerlig logcat, mätning av minne och minnestryck samt ögonblicksbilder av ljud och tjänster vid fel. Bevis samlas utan att jag måste se felet personligen.

Testmiljön påverkar resultatet. USB ger ström, så ett USB-test är inget test på urkopplat batteri. Upprepad dumpsys meminfo kunde själv ge ljudstörningar. En felfri natt visar bara att felet inte uppstod under just de förhållandena, inte att alla enheter och systemlägen fungerar.

En märklig upptäckt var Android Auto Backup. På min Pixel visade systemloggarna hur BackupManager avslutade Veil under säkerhetskopiering medan ljudet spelade. I installationsdata hittade jag 190 SIGKILL för skyddade processer på 93 installationer, från 14 augusti till 11 september 2026, ofta med ungefär tre dagars mellanrum. Det stödde backupförklaringen utan att bevisa varje enskilt fall.

Jag stängde av Auto Backup och accepterade kompromissen med molnåterställning. Android dokumenterar att säkerhetskopiering stoppar appen, men normalt undantar förgrundsappar. Spårningen på enheten gjorde just detta fall möjligt att agera på. Androids dokumentation om säkerhetskopiering

Andra fel var mina. Ljudåterställningen kunde skapa en ny kontext innan den gamla stängts, med överlappande resurser när appen redan hade problem. Nu inväntas stängningen med tidsgräns och återställning körs sekventiellt med uppspelningsoperationer. Nyare användaravsikter gäller: ett stopp medan en reparation väntar får inte ångras av reparationen.

En fix skapade ett nytt fel. En kontroll på 150 ms såg om ljudkontextens klocka gick framåt och hittade kontexter som påstod sig vara aktiva men hade fastnat. Den väntade dock på en JavaScript-timer, som i bakgrunden kunde bli hängande tills appen återkom till förgrunden. Kontrollen körs nu bara i förgrunden. Även återställning behöver testas med släckt skärm.

Några viktiga förbättringar var produktbeslut. Mätningar visade cirka 90 MB extra resident minne kopplat till reklamens WebView-process. Tidigare undersökningar hade också hittat allvarliga SDK-relaterade minnesfel. Först försökte jag begränsa kostnaden, sedan tog jag bort reklam och SDK helt. Nattlig tillförlitlighet vägde tyngre.

Telemetrin saknade om personen förväntade sig stoppet. Efter ett relevant avbrott kan Veil visa ett kort med tidpunkten och fråga ”Väntade du dig det här?”. Formuleringen är avsiktlig. ”Stoppade du ljudet?” missar en partner som stoppat eller väntade avbrott utan egen handling.

Ett väntat stopp leder inte till batterifelsökning. Annars bekräftar appen avbrottet och ger hjälp utifrån tillgängliga bevis. Svaret beskriver upplevelsen utan att påstå en teknisk orsak. Nya Android-användare slipper också mötas av oroande behörigheter och jakt på batteriinställningar.

Inställningarna är besvärliga för båda sidor. Jag kan öppna dem eller be om undantag där det passar, men användaren bestämmer. Androids undantag styr inte heller alla tillverkares städning. Ett konkret steg efter ett problem hjälper mer än okända inställningar före första ljudet. Androids vägledning om energihantering

Uppdateringar är extra frustrerande. Jag kan visa Plays inställning för automatiska uppdateringar per app, men Veil styr den inte. Manuella uppdateringar blir en extra uppgift, och Google har undantag för kritiska säkerhetsuppdateringar. En uppdatering för bättre nätter kan själv avbryta natten. Uppdateringsinställningar i Google Play

Automatisk återställning efter uppdateringar är ännu inte klar. Förutom ljudgrafen måste timerläge och användaravsikt bevaras rätt. Vissa tillverkarmönster behöver bättre reproduktion innan jag kan förklara dem säkert. Appen ska återhämta sig från fel, inte kämpa mot någon som stoppat avsiktligt.

Mest nytta gav regelbunden analys, långa tester, riktade fixar och direkt återkoppling tillsammans. Varje del hittar sådant de andra missar. Jag bryr mig mindre om att appen säger att den spelar och mer om bevisen. Den som trycker på spela före läggdags ska kunna lita på det, även om det krävde mer arbete än väntat.