Dziennik programisty

Jest 2026 rok, a odtwarzanie dźwięku przez całą noc nadal jest zaskakująco trudne

Autor: Colin Hanson · 13 października 2026 · 7 minut czytania

Chciałem, żeby telefon szumiał jak wentylator do rana. W 2026 roku wydawało się to rozwiązanym problemem. Tymczasem zajęło mi zaskakująco dużo czasu jako programiście.

Przez lata używałem White Noise Lite. Reklamy i interfejs, który wydawał mi się prastary, ale zwykle działało. Potem zaczęło regularnie się zatrzymywać. Uważałem to za awarie, choć bez logów nie znałem przyczyny. Chciałem też nowoczesnego interfejsu i dźwięku generowanego na urządzeniu zamiast nagrań, z precyzyjnymi ustawieniami. Stworzyłem Veil i dużo lepiej zrozumiałem problem niezawodności.

Na iOS odtwarzanie w tle było stosunkowo proste i z mojego doświadczenia Veil działa tam stabilnie od początku. Android wymagał więcej pracy: różny sprzęt, stare telefony z małą pamięcią, zarządzanie baterią producentów i aktualizacje podczas słuchania. Mój kod też miał błędy. Dla kogoś budzącego się o trzeciej nad ranem różnica niewiele znaczy.

Raporty awarii nie wystarczały. Zabity proces może nie zgłosić wyjątku, a działający proces może mieć niemy strumień audio. Nawet usługa pierwszoplanowa i powiadomienie nie dowodzą, że głośnik gra. Dodałem natywny dziennik odtwarzania, informacje o zakończeniu procesu, pomiary pamięci, stan usług, zdarzenia audio i zapisy celowych zatrzymań. Ważne dane przetrwają proces i są zbierane przy późniejszym uruchomieniu.

Chciałem odtworzyć noc na tyle, by rozróżnić możliwe przyczyny. Czy odtwarzanie nadal było zamierzone? Czy skończył się minutnik? Rosła pamięć? Telefon był ładowany? Android zastąpił pakiet? Więcej sygnałów pomagało, jeśli rozumiałem ich ograniczenia.

Najpierw naprawiłem pomiar. Usunięcie Veil z ostatnich aplikacji mogło zatrzymać dźwięk bez zamknięcia zapisanej sesji. Android usuwał proces z pamięci podręcznej kilka godzin później, a raport uznawał to za awarię odtwarzania. Celowy poranny stop stawał się „nocnym zamknięciem”. Aktualizacje przerywające rzeczywiste odtwarzanie pomijano zaś jako nieszkodliwe zakończenia systemowe.

Poprawienie definicji zmieniło obraz awarii przed kolejnymi poprawkami audio. Rozróżniam teraz lepsze odtwarzanie i lepszy pomiar. Regularnie analizuję wersję, rodzinę urządzeń, długość sesji i powód zakończenia, bez urządzeń testowych i duplikatów. Opóźnione raporty też mają znaczenie: kilka krótkich sesji nie dowodzi działania przez noc.

Te wzorce kierują testami. Prowadzę długie i nocne próby na prawdziwych telefonach oraz w zdalnym laboratorium Samsunga, z ciągłym logcat, próbkowaniem pamięci i presji pamięci oraz zapisami stanu audio i usług przy awarii. System zbiera dowody bez mojego osobistego obserwowania błędu.

Test może zmieniać wynik. USB zasila telefon, więc nie jest to próba na odłączonej baterii. Powtarzanie dumpsys meminfo samo mogło zakłócać audio. Udana noc dowodzi tylko braku reprodukcji w tych warunkach, a nie poprawności każdego urządzenia i stanu systemu.

Dziwnym odkryciem był Android Auto Backup. Na moim Pixelu logi pokazały, jak BackupManager zabija proces Veil podczas kopii zapasowej, gdy dźwięk gra. W danych znalazłem 190 SIGKILL chronionych procesów na 93 instalacjach, od 14 sierpnia do 11 września 2026, często w odstępach około trzech dni. Wzorzec wspierał hipotezę kopii zapasowej, nie dowodził każdego przypadku.

Wyłączyłem Auto Backup, akceptując ograniczenie przywracania z chmury. Dokumentacja Androida mówi, że kopia zatrzymuje aplikację, zwykle pomijając aplikacje pierwszoplanowe. Zapis z urządzenia pozwolił podjąć konkretne działania w tym przypadku. Dokumentacja kopii zapasowych Androida

Inne błędy były moje. Odzyskiwanie audio mogło tworzyć nowy kontekst przed zamknięciem starego, nakładając zasoby podczas problemów. Teraz czeka na zamknięcie z limitem czasu i przebiega kolejno z operacjami odtwarzania. Nowsza intencja użytkownika ma pierwszeństwo: naprawa w kolejce nie może cofnąć naciśniętego stopu.

Jedna poprawka stworzyła kolejny błąd. Test 150 ms sprawdzał ruch zegara kontekstu, wykrywając zawieszone konteksty deklarujące aktywność. Czekał jednak na timer JavaScript. W tle oczekiwanie mogło utknąć do powrotu aplikacji na pierwszy plan. Test działa teraz tylko na pierwszym planie. Ścieżki odzyskiwania też trzeba badać przy wygaszonym ekranie.

Pomogły też decyzje produktowe. Pomiary pokazały około 90 MB dodatkowej pamięci rezydentnej związanej z reklamowym procesem WebView. Wcześniejsze badania wykazały poważne błędy pamięci związane z SDK. Najpierw ograniczałem koszt, potem całkowicie usunąłem reklamy i SDK. Niezawodność przez noc była ważniejsza.

Telemetria nie mówiła, czy człowiek oczekiwał stopu. Po istotnej przerwie Veil może pokazać kartę z godziną i pytaniem „Czy to było oczekiwane?”. To celowe: „Czy zatrzymałeś dźwięk?” pomija partnera, który go zatrzymał, lub przewidywaną przerwę bez własnego działania.

Oczekiwany stop nie prowadzi do diagnozowania baterii. W innym przypadku aplikacja potwierdza przerwę i pomaga zgodnie z dowodami. Odpowiedź opisuje doświadczenie bez udawania znajomości technicznej przyczyny. Nowych użytkowników Androida nie witają też niepokojące uprawnienia i polowanie na ustawienia baterii.

Ustawienia są trudne dla obu stron. Mogę je otworzyć lub poprosić o wyjątek, gdy to właściwe, ale decyduje użytkownik. Wyjątek Androida nie kontroluje całego sprzątania producentów. Konkretny krok po problemie pomaga bardziej niż obce ustawienia przed pierwszym dźwiękiem. Zarządzanie energią w Androidzie

Aktualizacje są szczególnie frustrujące. Mogę wskazać automatyczne aktualizacje konkretnej aplikacji w Play, ale Veil nimi nie steruje. Ręczne aktualizacje to obowiązek, a Google zastrzega wyjątki dla krytycznych poprawek bezpieczeństwa. Aktualizacja poprawiająca nocną niezawodność może sama przerwać noc. Ustawienia aktualizacji Google Play

Automatyczne przywracanie po aktualizacji pozostaje niedokończone. Oprócz grafu audio trzeba poprawnie zachować minutnik i intencję użytkownika. Niektóre wzorce producentów wymagają lepszej reprodukcji przed pewnym wyjaśnieniem. Aplikacja ma wychodzić z awarii, nie walczyć z celowym zatrzymaniem.

Najwięcej dało połączenie regularnej analizy, długich testów, konkretnych poprawek i bezpośrednich opinii. Każde znajduje to, co umyka innym. Mniej obchodzi mnie deklaracja odtwarzania, bardziej jej dowody. Osoba naciskająca play przed snem powinna móc ufać aplikacji, choć osiągnięcie tego wymagało więcej pracy, niż zakładałem.