Entwicklungstagebuch

2026 ist es immer noch überraschend schwer, eine Schlaf-App die ganze Nacht laufen zu lassen

Von Colin Hanson · 13. Oktober 2026 · 7 Minuten Lesezeit

Mein Handy sollte bis morgens ein Ventilatorgeräusch abspielen. Das schien mir 2026 eine weitgehend gelöste Aufgabe. Als Entwickler hat sie mich dann überraschend viel Zeit gekostet.

Jahrelang nutzte ich White Noise Lite. Die App hatte Werbung und eine für mich uralte Oberfläche, funktionierte aber meistens. Darauf kam es an. Dann stoppte sie regelmäßig. Ich hielt das für Abstürze, hatte aber keine Logs, um die Ursache zu kennen. Außerdem wollte ich eine moderne Oberfläche und auf dem Gerät erzeugte Klänge statt Aufnahmen, mit präzisen Einstellungen. Schließlich entwickelte ich Veil und verstand das Zuverlässigkeitsproblem deutlich besser.

Auf iOS war Hintergrundwiedergabe relativ unkompliziert. Meiner Erfahrung nach läuft Veil dort seit Anfang an sehr stabil. Android wurde ein längeres Projekt: unterschiedlichste Hardware, ältere Handys mit wenig Speicher, herstellerspezifische Akkuverwaltung und gelegentliche Updates mitten in der Wiedergabe. Mein eigener Code hatte ebenfalls Fehler. Wer um drei Uhr nachts aufwacht, hat wenig von dieser Unterscheidung.

Absturzberichte waren der Anfang, reichten aber nicht. Ein beendeter Prozess meldet möglicherweise keine Ausnahme. Ein lebender Prozess kann einen stummen Audiostream haben. Selbst Vordergrunddienst und Wiedergabebenachrichtigung beweisen keinen Ton aus dem Lautsprecher. Ich ergänzte ein natives Wiedergabejournal, Prozessende-Daten, Speichermessungen, Dienstzustände, Audiostream-Ereignisse und ausdrückliche Einträge für absichtliche Stopps. Relevante Daten überleben den Prozess und werden bei einem späteren Start abgeholt.

Ich wollte die Nacht weit genug rekonstruieren, um mögliche Ursachen zu unterscheiden. War Wiedergabe noch gewollt? War der Timer abgelaufen? Wuchs der Speicherverbrauch? Hing das Handy am Strom? Hatte Android das App-Paket ersetzt? Mehr Signale halfen, sofern ich ihre Aussagekraft verstand.

Zuerst musste ich die Messung selbst reparieren. Wegwischen konnte Veil stoppen, ohne die protokollierte Sitzung ordentlich zu schließen. Wenn Android Stunden später den zwischengespeicherten Prozess entfernte, zählte mein Bericht das als Wiedergabefehler. Ein bewusstes Stoppen am Morgen wurde zum „nächtlichen Abbruch“. Updates, die tatsächlich laufendes Audio unterbrachen, wurden dagegen als harmlose Systembeendigungen ausgeschlossen.

Korrigierte Definitionen veränderten das Fehlerbild noch vor weiteren Audio-Fixes. Seitdem trenne ich bessere Wiedergabe sorgfältig von besserer Messung. Ich analysiere regelmäßig nach App-Version, Gerätefamilie, Sitzungsdauer und Beendigungsgrund, ohne Testgeräte und doppelte Berichte. Auch verspätete Meldungen zählen: Wenige kurze Sitzungen einer neuen Version beweisen keine zuverlässige Nacht.

Diese Muster bestimmen die Gerätetests. Ich nutze lange und nächtliche Tests auf echten Handys sowie Samsungs Remote-Labor, mit laufendem logcat, Speicher- und Speicherdruckmessungen und Zustandsaufnahmen von Audio und Diensten bei Fehlern. Die Aufzeichnung sammelt Belege, ohne dass ich den Fehler persönlich beobachten muss.

Auch der Testaufbau beeinflusst das Ergebnis. USB versorgt das Handy mit Strom, ist also kein Akkutest ohne Ladegerät. Wiederholtes dumpsys meminfo konnte selbst Audiostörungen verursachen. Eine fehlerfreie Nacht zeigt nur, dass ich den Fehler unter diesen Bedingungen nicht reproduziert habe. Sie entlastet nicht jedes Gerät und jeden Systemzustand.

Eine merkwürdige Entdeckung war Android Auto Backup. Auf meinem Pixel zeigten Systemlogs, wie BackupManager Veils Prozess während einer Sicherung trotz laufendem Audio beendete. In den Nutzungsdaten fand ich 190 SIGKILLs geschützter Prozesse auf 93 Installationen, vom 14. August bis 11. September 2026, oft im Abstand von ungefähr drei Tagen. Das stützte die Backup-Hypothese, bewies aber nicht die Ursache jedes einzelnen Abbruchs.

Ich deaktivierte Auto Backup für Veil und nahm die Einschränkung bei der Cloud-Wiederherstellung in Kauf. Laut Android-Dokumentation stoppt ein Backup die App, wobei Apps im Vordergrund normalerweise ausgenommen sind. Erst die Geräteaufzeichnung machte diesen Fall konkret bearbeitbar. Android-Dokumentation zu Backups

Andere Fehler lagen bei mir. Die Audiowiederherstellung konnte einen neuen Kontext aufbauen, bevor der alte geschlossen war. Dadurch überlappten Ressourcen, obwohl die App bereits Probleme hatte. Ich lasse den Abbau jetzt mit Zeitgrenze abwarten und führe Wiederherstellung und Wiedergabeoperationen nacheinander aus. Neuere Nutzerabsichten haben Vorrang: Wer während einer wartenden Reparatur auf Stopp drückt, darf danach nicht wieder beschallt werden.

Ein Reparaturversuch erzeugte einen neuen Fehler. Eine 150-ms-Prüfung sollte erkennen, ob die Audiokontext-Uhr tatsächlich weiterlief. Sie fand festhängende Kontexte, die sich als aktiv meldeten, wartete aber auf einen JavaScript-Timer. Im Hintergrund konnte dieses Warten bis zur Rückkehr in den Vordergrund hängen bleiben. Die Prüfung läuft deshalb nur noch im Vordergrund. Auch Wiederherstellungspfade brauchen Tests bei ausgeschaltetem Bildschirm.

Einige besonders hilfreiche Änderungen waren Produktentscheidungen. Messungen zeigten etwa 90 MB zusätzlichen residenten Speicher beim Werbe-WebView-Prozess. Frühere Untersuchungen hatten bereits schwere Speicherfehler im Zusammenhang mit dem SDK gezeigt. Erst begrenzte ich den Aufwand, dann entfernte ich Werbung und SDK vollständig. Für eine App, die nachts durchlaufen soll, war Zuverlässigkeit wichtiger.

Eine wichtige Frage blieb offen: Hatte die Person mit dem Stopp gerechnet? Nach einer relevanten Unterbrechung kann Veil eine kleine Karte mit Uhrzeit und der Frage „Hattest du damit gerechnet?“ zeigen. Die Wortwahl ist bewusst. „Hast du gestoppt?“ erfasst weder einen Stopp durch den Partner noch erwartete Unterbrechungen ohne eigene Bedienung.

Bei erwarteten Stopps gibt es keine Akku-Fehlersuche. Sonst bestätigt die App die Unterbrechung und bietet Hilfe passend zu den vorhandenen Hinweisen. Die Antwort beschreibt das Erleben, ohne eine technische Ursache vorzutäuschen. So muss ich neue Android-Nutzer auch nicht sofort mit beunruhigenden Berechtigungen und einer Suchaktion in den Akkueinstellungen begrüßen.

Diese Einstellungen sind für beide Seiten schwierig. Ich kann passende Einstellungen öffnen oder eine Ausnahme beantragen, entscheiden muss der Nutzer. Androids Ausnahmeverfahren kontrolliert auch nicht sämtliche Aufräumfunktionen der Hersteller. Ein konkreter Schritt nach einem Problem hilft mehr als unbekannte Einstellungen vor dem ersten abgespielten Ton. Android-Leitfaden zur Energieverwaltung

Updates sind besonders ärgerlich. Ich kann die automatische Aktualisierung pro App in Play erklären, aber Veil kann sie nicht steuern. Manuelle Updates bedeuten zusätzliche Arbeit; für kritische Sicherheitsupdates behält Google Ausnahmen vor. Ein Update für zuverlässigere Nächte kann selbst eine Nacht unterbrechen. Google-Play-Update-Einstellungen

Die automatische Wiederaufnahme nach einem Update ist noch nicht fertig. Neben dem Audiographen müssen Timerzustand und Nutzerabsicht korrekt erhalten bleiben. Manche herstellerspezifischen Muster brauchen bessere Reproduktionen, bevor ich sie sicher erklären kann. Die App soll Fehler überwinden, aber nicht gegen ein bewusstes Stoppen ankämpfen.

Am meisten half die Kombination aus regelmäßiger Analyse, langen Gerätetests, gezielten Korrekturen und direkten Rückmeldungen. Jede Methode entdeckt Dinge, die den anderen entgehen. Mich interessiert weniger, ob die App „Wiedergabe läuft“ behauptet, als welche Belege dafür sprechen. Wer vor dem Schlafen startet, sollte sich darauf verlassen können, auch wenn das erheblich mehr Arbeit war als erwartet.