Щоденник розробника

Надворі 2026-й, а змусити застосунок для сну звучати всю ніч досі напрочуд складно

Автор: Colin Hanson · 13 жовтня 2026 року · 7 хвилин читання

Я хотів, щоб телефон шумів як вентилятор до ранку. У 2026 році це здавалося вже вирішеною проблемою. Але вона забрала напрочуд багато мого часу як розробника.

Роками я користувався White Noise Lite. Реклама й інтерфейс, який здавався мені старезним, але здебільшого все працювало. Потім звук почав регулярно зупинятися. Я вважав це аваріями, хоча не мав журналів, щоб знати причину. Хотілося також сучасного інтерфейсу й звуку, створеного на пристрої, а не запису, з точними налаштуваннями. Зрештою я створив Veil і набагато краще зрозумів проблему надійності.

На iOS фонове відтворення було відносно простим, і з мого досвіду Veil там стабільний від початку. Android забрав більше часу: різне обладнання, старі телефони з малою пам’яттю, керування батареєю виробників та оновлення під час прослуховування. Мій код теж мав помилки. Людині, яка прокидається о третій ночі, ця різниця мало допомагає.

Звітів про аварії було замало. Завершений процес може не повідомити виняток, а живий процес може мати беззвучний аудіопотік. Навіть служба переднього плану й сповіщення не доводять звук із динаміка. Я додав нативний журнал відтворення, дані про завершення процесів, вимірювання пам’яті, стан служб, аудіоподії та записи навмисних зупинок. Важливі дані переживають процес і збираються під час пізнішого запуску.

Я хотів відтворити події ночі достатньо, щоб розрізнити можливі причини. Чи звук ще мав грати? Чи завершився таймер? Чи зростала пам’ять? Телефон заряджався? Android замінив пакет? Більше сигналів допомагало, якщо я розумів їхні межі.

Спершу довелося виправити вимірювання. Змахування Veil зі списку недавніх застосунків могло зупинити звук, не закривши записаний сеанс. Android очищав кешований процес через кілька годин, а звіт рахував це як збій відтворення. Навмисна ранкова зупинка ставала «нічним завершенням». Оновлення, які справді переривали звук, натомість виключалися як нешкідливі системні завершення.

Уточнення визначень змінило картину ще до нових виправлень аудіо. Тепер розділяю покращення відтворення та його вимірювання. Регулярно аналізую версію, сімейство пристроїв, тривалість і причину завершення, прибираючи тестові пристрої та дублікати. Важливі й затримки звітів: кілька коротких сеансів не доводять витривалості протягом ночі.

Ці закономірності спрямовують тести. Проводжу довгі й нічні перевірки на фізичних телефонах і в дистанційній лабораторії Samsung, з безперервним logcat, вимірюваннями пам’яті та тиску на неї, знімками стану аудіо й служб при збої. Докази збираються без моєї особистої присутності в момент помилки.

Тестування може впливати на результат. USB живить телефон, тож це не тест від’єднаної батареї. Повторний dumpsys meminfo сам міг спричиняти звукові збої. Чиста ніч показує лише, що помилка не відтворилася за цих умов, а не справність усіх пристроїв і станів системи.

Дивною знахідкою був Android Auto Backup. На моєму Pixel журнали показали, як BackupManager завершив Veil під час резервування, поки звук грав. У даних установлень я знайшов 190 SIGKILL захищених процесів на 93 установленнях від 14 серпня до 11 вересня 2026 року, часто з інтервалом близько трьох днів. Це підтримувало гіпотезу резервування, але не доводило кожен випадок.

Я вимкнув Auto Backup, прийнявши обмеження відновлення з хмари. Документація Android каже, що резервування завершує застосунок, зазвичай оминаючи застосунки переднього плану. Запис із пристрою дозволив діяти в цьому конкретному випадку. Документація резервування Android

Інші помилки були мої. Відновлення звуку могло створювати новий контекст до закриття старого, накладаючи ресурси під час проблем. Тепер закриття очікується з часовим обмеженням, а відновлення й операції відтворення виконуються послідовно. Новіший намір користувача важливіший: ремонт у черзі не має скасовувати натиснуту зупинку.

Одна спроба виправлення створила іншу помилку. Перевірка на 150 мс дивилася, чи рухається годинник аудіоконтексту, виявляючи завислі контексти, що звітували про активність. Але вона чекала на таймер JavaScript. У фоні очікування могло зависнути до повернення застосунку на передній план. Тепер перевірка працює лише на передньому плані. Шляхи відновлення теж треба тестувати з вимкненим екраном.

Корисними були й продуктові рішення. Вимірювання показали близько 90 МБ додаткової резидентної пам’яті, пов’язаної з рекламним процесом WebView. Попередні дослідження також виявили серйозні помилки пам’яті, пов’язані з SDK. Спершу я обмежував витрати, потім повністю прибрав рекламу та SDK. Нічна надійність важила більше.

Телеметрія не казала, чи людина очікувала зупинку. Після відповідного переривання Veil може показати картку з часом і запитати «Це було очікувано?». Формулювання навмисне. «Ви зупинили звук?» не охоплює партнера, який його зупинив, або очікуване переривання без власної дії.

Очікувана зупинка не веде до діагностики батареї. Інакше застосунок визнає переривання й дає поради відповідно до доказів. Відповідь описує досвід, не вдаючи знання технічної причини. Нових користувачів Android також не треба зустрічати тривожними дозволами та пошуками налаштувань батареї.

Налаштування складні для обох сторін. Я можу їх відкрити або попросити виняток, коли доречно, але вирішує користувач. Виняток Android не керує всім очищенням виробників. Конкретний крок після проблеми допомагає більше, ніж незнайомі налаштування до першого звуку. Керування живленням Android

Оновлення особливо дратують. Можу показати автоматичні оновлення окремого застосунку в Play, але Veil ними не керує. Оновлювати вручну означає додаткову роботу, а Google передбачає винятки для критичних оновлень безпеки. Оновлення для кращої нічної надійності саме може перервати ніч. Налаштування оновлень Google Play

Автоматичне відновлення після оновлення ще не завершене. Окрім аудіографа, мають правильно зберегтися таймер і намір користувача. Деякі закономірності виробників потребують кращого відтворення перед упевненим поясненням. Застосунок має оговтуватися від помилок, а не боротися з навмисною зупинкою.

Найбільше дала комбінація регулярного аналізу, довгих тестів, конкретних виправлень і прямих відгуків. Кожен метод знаходить пропущене іншими. Мене менше цікавить твердження застосунку про відтворення, більше його докази. Людина, яка вмикає звук перед сном, має довіряти йому, хоча це вимагало більше роботи, ніж я очікував.