Diario di sviluppo

Nel 2026 è ancora sorprendentemente difficile far suonare un’app per dormire tutta la notte

Di Colin Hanson · 13 ottobre 2026 · 7 minuti di lettura

Volevo che il telefono facesse un rumore di ventilatore fino al mattino. Nel 2026 sembrava un problema ormai risolto. Invece mi ha portato via una quantità sorprendente di tempo da sviluppatore.

Per anni ho usato White Noise Lite. Aveva pubblicità e un’interfaccia che mi sembrava antica, ma in genere funzionava: era quello che contava. Poi ha iniziato a fermarsi regolarmente. Li consideravo crash, pur senza avere i log per sapere cosa succedesse. Volevo anche un’interfaccia moderna e suoni generati sul dispositivo anziché registrazioni, con controlli precisi. Alla fine ho creato Veil e ho capito molto meglio il problema dell’affidabilità.

Su iOS la riproduzione in background è stata relativamente semplice e, nella mia esperienza, Veil è molto stabile fin dall’inizio. Android ha richiesto più lavoro: hardware molto diversi, telefoni vecchi con poca memoria, gestione della batteria dei produttori e aggiornamenti occasionali durante l’ascolto. C’erano anche parecchi problemi nel mio codice. Per chi si sveglia alle tre di notte, la distinzione conta poco.

Sono partito dai rapporti sui crash, ma serviva più contesto. Un processo terminato può non segnalare eccezioni e un processo vivo può avere un flusso audio muto. Neppure un servizio in primo piano con notifica dimostra che esca suono dall’altoparlante. Ho aggiunto un registro nativo della riproduzione, informazioni sulla fine dei processi, misure di memoria, stato dei servizi, eventi audio e registrazioni esplicite degli stop intenzionali. I dati utili sopravvivono al processo e vengono raccolti a un avvio successivo.

L’obiettivo era ricostruire abbastanza della notte da distinguere le possibili cause. Si voleva ancora ascoltare? Il timer era scaduto? La memoria cresceva? Il telefono era in carica? Android aveva sostituito il pacchetto? Più segnali aiutavano, purché ne capissi i limiti.

Una delle prime cose da correggere è stata la misurazione. Rimuovere Veil dalle app recenti poteva fermare il suono senza chiudere bene la sessione registrata. Ore dopo Android poteva recuperare il processo in cache, che i miei rapporti contavano come guasto audio. Uno stop volontario al mattino diventava un’«interruzione notturna». Al contrario, gli aggiornamenti che interrompevano l’ascolto erano esclusi come normali uscite di sistema.

Correggere le definizioni ha cambiato il quadro prima di altri interventi sull’audio. Ora distinguo con attenzione i miglioramenti della riproduzione da quelli della misurazione. Analizzo periodicamente i dati per versione, famiglia di dispositivi, durata e motivo di uscita, escludendo test e duplicati. Contano anche i rapporti tardivi: poche sessioni brevi con una nuova versione non dimostrano che regga una notte.

Questi schemi guidano i test. Eseguo prove lunghe e notturne su telefoni reali, oltre a sessioni nel laboratorio remoto Samsung, con logcat continuo, campionamento della memoria e della pressione sulla memoria, e istantanee di audio e servizi quando qualcosa non va. Il sistema raccoglie le prove senza che debba assistere al guasto.

Anche il test può alterare il risultato. USB alimenta il telefono: non equivale a una prova a batteria scollegata. Ripetere dumpsys meminfo poteva causare disturbi audio. Una notte senza problemi dimostra soltanto che non ho riprodotto il guasto in quelle condizioni, non che ogni dispositivo e stato del sistema siano a posto.

Una scoperta curiosa riguardava Android Auto Backup. Sul mio Pixel i log mostravano BackupManager terminare Veil durante un backup mentre l’audio suonava. Nei dati delle installazioni ho trovato 190 SIGKILL di processi protetti su 93 installazioni, dal 14 agosto all’11 settembre 2026, con ricorrenze intorno ai tre giorni. Lo schema sosteneva l’ipotesi del backup senza provare ogni singolo caso.

Ho disattivato Auto Backup accettando il compromesso sul ripristino dal cloud. Android documenta che il backup arresta l’app, escludendo normalmente quelle in primo piano. La traccia sul dispositivo ha reso questo caso concreto su cui intervenire. Documentazione dei backup Android

Altri problemi erano nel mio codice. Il recupero audio poteva costruire un nuovo contesto prima della chiusura del precedente, sovrapponendo risorse quando l’app era già in difficoltà. Ora attende la chiusura con un limite di tempo e viene serializzato con le operazioni di riproduzione. Deve anche rispettare le intenzioni più recenti: uno stop premuto mentre una riparazione è in coda non deve essere annullato dalla riparazione.

Un tentativo di correzione ha introdotto un altro guasto. Un controllo di 150 ms verificava l’avanzamento dell’orologio audio, individuando contesti bloccati ma dichiarati attivi. Purtroppo aspettava un timer JavaScript. In background l’attesa poteva bloccarsi fino al ritorno in primo piano. Il controllo ora funziona solo in primo piano: un’altra ragione per testare il recupero a schermo spento.

Alcune modifiche utili erano decisioni di prodotto. Le misure mostravano circa 90 MB di memoria residente aggiuntiva associata al processo WebView pubblicitario. Indagini precedenti avevano già trovato gravi problemi di memoria legati all’SDK. Prima ho cercato di contenerne il costo, poi ho rimosso del tutto pubblicità e SDK. Per un’app che deve suonare tutta la notte, l’affidabilità contava di più.

Restava una lacuna: la persona si aspettava lo stop? Dopo un’interruzione rilevante, Veil può mostrare una scheda con l’ora e chiedere «Te lo aspettavi?». Le parole sono volute. «Hai fermato tu l’audio?» non copre un partner che lo ferma o un’interruzione prevista senza toccare il telefono.

Se lo stop era previsto, niente procedure sulla batteria. Altrimenti l’app riconosce l’interruzione e offre indicazioni basate sulle prove disponibili. La risposta descrive l’esperienza senza pretendere di identificare la causa tecnica. Evito così di accogliere tutti i nuovi utenti Android con autorizzazioni allarmanti e cacce al tesoro nelle impostazioni.

Quelle impostazioni sono scomode per entrambi. Posso aprirle o chiedere un’esenzione quando opportuno, ma decide l’utente. L’esenzione Android non controlla neppure tutti i comportamenti di pulizia dei produttori. Un passo preciso dopo un problema aiuta più di impostazioni sconosciute prima ancora di ascoltare un suono. Guida al risparmio energetico Android

Gli aggiornamenti sono particolarmente frustranti. Posso spiegare l’impostazione automatica per singola app in Play, ma Veil non la controlla. Gestire gli aggiornamenti manualmente aggiunge lavoro; Google prevede eccezioni per quelli di sicurezza critici. Un aggiornamento per migliorare l’affidabilità notturna può interrompere proprio la notte. Impostazioni degli aggiornamenti Google Play

Il ripristino automatico dopo un aggiornamento è ancora incompleto. Oltre al grafo audio devono sopravvivere correttamente timer e intenzioni dell’utente. Alcuni schemi specifici dei produttori richiedono riproduzioni migliori prima di poterli spiegare con sicurezza. Voglio recuperare dai guasti, non contrastare chi ha fermato l’app di proposito.

I progressi maggiori sono venuti dall’unione di analisi ricorrenti, test lunghi, correzioni mirate e riscontri diretti. Ognuno scopre ciò che sfugge agli altri. Mi interessa meno che l’app dica di suonare e più quali prove lo dimostrino. Chi preme play prima di dormire dovrebbe potersi fidare, anche se arrivarci ha richiesto molto più lavoro del previsto.