Kehityspäiväkirja

Vuonna 2026 unisovelluksen pitäminen äänessä koko yön on yhä yllättävän vaikeaa

Kirjoittaja Colin Hanson · 13. lokakuuta 2026 · 7 minuutin lukuaika

Halusin puhelimeni pitävän tuulettimen ääntä aamuun asti. Vuonna 2026 se vaikutti melko ratkaistulta ongelmalta. Silti siihen on kulunut yllättävän paljon kehittäjän aikaani.

Käytin vuosia White Noise Litea. Mainoksia ja mielestäni ikivanha käyttöliittymä, mutta yleensä se toimi. Sitten se alkoi pysähtyä usein. Pidin niitä kaatumisina, vaikka minulla ei ollut lokeja syyn selvittämiseen. Halusin myös modernin käyttöliittymän ja laitteessa tuotettua ääntä tallenteiden sijaan, tarkoin säädöin. Lopulta tein Veilin ja ymmärsin luotettavuusongelman paljon paremmin.

iOS:n taustatoisto oli verraten suoraviivaista, ja kokemukseni mukaan Veil on ollut siellä vakaa alusta asti. Android vei enemmän aikaa: erilaiset laitteet, vanhat vähämuistiset puhelimet, valmistajien akunhallinta ja kesken kuuntelun tulevat päivitykset. Omassakin koodissani oli virheitä. Kolmelta yöllä heräävälle erolla ei juuri ole merkitystä.

Kaatumisraportit eivät riittäneet. Lopetettu prosessi ei välttämättä ilmoita poikkeusta, ja elävän prosessin äänivirta voi olla hiljainen. Etualapalvelu ja toistoilmoituskaan eivät todista kaiuttimesta tulevaa ääntä. Lisäsin natiivin toistolokin, prosessin lopetustiedot, muistimittaukset, palvelutilan, äänitapahtumat ja tahallisten pysäytysten kirjaukset. Olennaiset tiedot säilyvät prosessin yli ja kerätään myöhemmällä käynnistyksellä.

Halusin rekonstruoida yön riittävän hyvin mahdollisten syiden erottamiseen. Oliko toisto yhä tarkoituksena? Loppuiko ajastin? Kasvoiko muisti? Oliko puhelin latauksessa? Oliko Android korvannut paketin? Lisäsignaalit auttoivat, kun ymmärsin niiden rajat.

Ensin piti korjata mittaus. Veilin pyyhkäisy pois saattoi pysäyttää äänen sulkematta kirjattua istuntoa. Android saattoi vapauttaa välimuistissa olevan prosessin vasta tunteja myöhemmin, minkä raportti laski toistovirheeksi. Tahallinen aamupysäytys muuttui ”yökatkokseksi”. Oikean toiston katkaisseet päivitykset taas suljettiin pois harmittomina järjestelmälopetuksina.

Määritelmien korjaus muutti vikakuvaa ennen uusia äänikorjauksia. Erottelen nyt toiston ja mittaamisen parannukset. Analysoin säännöllisesti versiota, laiteperhettä, istunnon pituutta ja lopetussyytä ilman testilaitteita ja kaksoisraportteja. Viiveetkin merkitsevät: muutama lyhyt istunto ei todista version kestävän yötä.

Havainnot ohjaavat laitetestejä. Teen pitkiä ja yön yli kestäviä testejä fyysisillä puhelimilla sekä Samsungin etälaboratoriossa. Käytössä ovat jatkuva logcat, muistin ja muistipaineen näytteet sekä ääni- ja palvelutilan tilannekuvat vikatilanteessa. Todisteet kerätään ilman, että minun pitää nähdä vika itse.

Testaus voi vaikuttaa tulokseen. USB syöttää virtaa, joten kyse ei ole irrotetun puhelimen akkutestistä. Toistuva dumpsys meminfo saattoi itse aiheuttaa äänihäiriöitä. Puhdas yö kertoo vain, ettei vika toistunut niissä oloissa, ei kaikkien laitteiden tai järjestelmätilojen toimivuudesta.

Erikoinen löytö oli Android Auto Backup. Pixelini järjestelmälokeissa BackupManager lopetti Veilin varmuuskopioinnin aikana äänen soidessa. Asennusdatasta löytyi 190 suojattujen prosessien SIGKILL-lopetusta 93 asennuksella 14.8.–11.9.2026, usein noin kolmen päivän välein. Kuvio tuki varmuuskopiointiselitystä todistamatta jokaista tapausta.

Poistin Auto Backupin käytöstä hyväksyen pilvipalautuksen rajoituksen. Androidin dokumentaation mukaan varmuuskopiointi lopettaa sovelluksen mutta ohittaa yleensä etualan sovellukset. Laitteen loki teki tästä tapauksesta konkreettisen korjattavan. Androidin varmuuskopiointiohje

Osa virheistä oli omiani. Äänen palautus saattoi rakentaa uuden kontekstin ennen vanhan sulkeutumista, jolloin resurssit menivät päällekkäin ongelmatilanteessa. Sulkemista odotetaan nyt aikarajan puitteissa, ja palautus sekä toistotoiminnot sarjallistetaan. Uudempi käyttäjän valinta ratkaisee: jonossa oleva korjaus ei saa kumota käyttäjän pysäytystä.

Yksi korjaus toi uuden vian. 150 ms:n tarkistus mittasi äänikontekstin kellon etenemistä ja löysi jumiutuneita, aktiivisiksi ilmoittautuvia konteksteja. Se kuitenkin odotti JavaScript-ajastinta, joka saattoi taustalla jäädä odottamaan sovelluksen paluuta etualalle. Tarkistus toimii nyt vain etualalla. Palautumispolutkin täytyy testata näyttö sammutettuna.

Tärkeitä parannuksia tuli tuotepäätöksistä. Mittaukset näyttivät mainosten WebView-prosessiin liittyvän noin 90 Mt lisää residenttiä muistia. Aiempi selvitys löysi myös vakavia SDK:hon liittyviä muistivirheitä. Ensin rajasin kuormaa, sitten poistin mainokset ja SDK:n kokonaan. Yön yli toimivalle sovellukselle luotettavuus oli tärkeämpää.

Telemetriasta puuttui tieto, odottiko ihminen pysähdystä. Olennaisen katkoksen jälkeen Veil voi näyttää kellonajan ja kysyä ”Odotitko tätä?”. Sanamuoto on harkittu. ”Pysäytitkö äänen?” ei kata kumppanin pysäytystä eikä odotettua katkosta ilman omaa toimintaa.

Odotettu pysähdys ei johda akkuvian etsintään. Muuten sovellus tunnistaa katkoksen ja tarjoaa näyttöön sopivat ohjeet. Vastaus kertoo kokemuksesta väittämättä teknistä syytä. Uusia Android-käyttäjiä ei myöskään tarvitse vastaanottaa pelottavilla luvilla ja akkuasetusten etsinnällä.

Asetukset ovat hankalia molemmille. Voin avata ne tai pyytää poikkeusta tarvittaessa, mutta käyttäjä päättää. Androidin poikkeus ei hallitse kaikkien valmistajien siivoustoimintoja. Konkreettinen askel ongelman jälkeen auttaa enemmän kuin vieraat asetukset ennen ensimmäistä ääntä. Androidin virranhallintaohje

Päivitykset turhauttavat erityisesti. Voin neuvoa Playn sovelluskohtaisen automaattipäivityksen, mutta Veil ei hallitse sitä. Käsin päivittäminen on lisätyö, ja Google varaa poikkeukset kriittisille tietoturvapäivityksille. Luotettavuutta parantava päivitys voi itse katkaista yön. Google Playn päivitysasetukset

Automaattinen palautuminen päivityksestä on yhä kesken. Äänigraafin lisäksi ajastimen tila ja käyttäjän tarkoitus on säilytettävä oikein. Jotkin valmistajakohtaiset kuviot tarvitsevat paremman toiston ennen varmaa selitystä. Sovelluksen pitää palautua vioista, ei vastustaa tahallista pysäytystä.

Eniten auttoi toistuvan analyysin, pitkien testien, täsmäkorjausten ja suoran palautteen yhdistelmä. Kukin löytää muiden ohittamia asioita. Minua kiinnostaa vähemmän sovelluksen väite toistosta ja enemmän sen näyttö. Nukkumaan mennessä toiston käynnistävän pitää voida luottaa siihen, vaikka sen saavuttaminen vaati odotettua enemmän työtä.