Как построить фоновый сервис для Android, который не убьёт система: архитектурный разбор

Разработчик приложения Muffle рассказал о том, с какими архитектурными проблемами столкнулся при создании Android-приложения для автоматического управления звуковыми профилями. История полезна как иллюстрация системных ограничений платформы, с которыми сталкивается любой фоновый сервис.

Фоновое приложение на Android — это не столько про написание кода, сколько про борьбу с операционной системой, которая искренне хочет вас убить. И главный урок: если ваш процесс не может восстановить состояние за полсекунды после перезапуска — баги неизбежны.

Предыстория: задача звучит тривиально

Разработчик, представившийся как создатель приложения Muffle, описывает ситуацию, знакомую каждому: тихая комната ожидания в медицинском учреждении, телефон внезапно начинает орать рингтоном, а в панике вместо кнопки «без звук» случайно нажимается «громкость вверх». Казалось бы, примитивная проблема — автоматически переключать звуковой профиль в зависимости от контекста: время, геолокация, расписание.

Однако реализация этого «простого» требования на современном Android превращается в полноценный инженерный квест. Причина — в том, что Google последние десять лет целенаправленно ужесточает условия жизни для фоновых процессов, и то, что работало в Android 5.0, давно мертво в Android 14 и новее.

Doze: первый и главный враг

Первое, с чем столкнулся разработчик — режим энергосбережения Doze, введённый в Android 6.0 Marshmallow. В Doze система агрессивно откладывает отложенные задачи и блокирует сетевые запросы. Слушатель геозон (BroadcastReceiver) просто переставал срабатывать, а AlarmManager давал задержки вплоть до нескольких минут.

Вопреки интуиции, «простой BroadcastReceiver на изменение времени или вход в геозону» не работает как фоновое решение с Android 6.0 и далее. Это не баг — это дизайн. Google намеренно не хочет, чтобы приложения выполняли произвольный код в фоне, когда экран выключен и устройство лежит в кармане.

ForegroundService: плата за привилегию

Решение — ForegroundService, сервис с постоянным уведомлением в шторке. Это единственный способ сказать операционной системе: «мой процесс выполняет задачу, видимую пользователю, не убивайте его». Разработчики часто избегают таких сервисов из-за визуального шума в уведомлениях, но для приложения, которое должно жить в фоне постоянно, альтернативы нет.

Для планирования задач автор использовал WorkManager — рекомендованный Google механизм для отложенной фоновой работы. Вместо того чтобы полагаться на AlarmManager для всего, цепочка OneTimeWorkRequest с конкретными ограничениями (Constraints) ставится на нужное время. При этом важно: для сенситивных по времени переключений звука ограничения вроде RequiredNetworkType.NOT_REQUIRED и RequiresBatteryNotLow должны быть сняты, иначе система заблокирует выполнение в неподходящий момент.

Ключевой фрагмент:

val routineRequest = OneTimeWorkRequestBuilder()
    .setInitialDelay(timeUntilTrigger, TimeUnit.MILLISECONDS)
    .setConstraints(Constraints.Builder()
        .setRequiresDeviceIdle(false)
        .build())
    .build()
WorkManager.getInstance(context).enqueue(routineRequest)

AudioManager: нюансы переключения звука

Само переключение звука происходит через AudioManager, но тут есть подводные камни. Режим «Не беспокоить» (Do Not Disturb) затрагивает флаги NotificationManager.INTERRUPTION_FILTER_ALL и связанные с ними константы. Попытка изменить эти настройки без разрешения ACCESS_NOTIFICATION_POLICY приводит к мгновенному крашу приложения. Не к ошибке, не к graceful degradation — к падению.

Ещё сложнее — приоритизация. Что делать, если два правила перекрываются? Рабочая встреча с 14:00 до 15:00 и время молитвы с 14:30 до 15:15 — какое состояние переключить первым? Как корректно вернуть предыдущий профиль, когда первое событие закончится?

Автор реализовал это через локальную SQLite-базу (Room ORM), работающую как стек. Каждое активное правило пушит текущее состояние в базу, при завершении — попает. Если два правила наложились, последнее в стеке побеждает, а при его снятии восстанавливается предыдущее. Архитектурно это разумно, хотя в статье не упоминается, как обрабатывается ситуация, когда два правила заканчиваются одновременно или в обратном порядке.

Геолокация: хаос производителей

Пожалуй, самый показательный эпизод — геозоны. Автор рассчитывал на стандартный GeofencingClient из Google Play Services, предполагая, что раз API единое, поведение будет единообразным. Это оказалось ошибкой.

Производители вроде Xiaomi и Oppo внедряют собственные агрессивные менеджеры энергосбережения, которые убивают фоновые слушатели локации вопреки стандартной документации Android. Приложение на Pixel работало безупречно, на китайских устройствах — геотриггеры просто не срабатывали.

Решение, как это часто бывает на Android, оказалось не техническим, а UX-ориентированным: специальный экран настроек с инструкциями для пользователя — как добавить приложение в «Автозапуск», как отключить оптимизацию батареи именно для этого приложения. Никакая чистая архитектура не победит OEM-прошивку, которая решительно убивает ваш процесс.

Это системная проблема платформы: Google выпускает guidelines, но каждый крупный производитель (Samsung, Xiaomi, Oppo, Huawei, Vivo) реализует свою собственную агрессивную политику управления фоновыми процессами. Для разработчика это означает, что тестирование на эмуляторе стандартного Android не даёт никаких гарантий для реальных устройств.

Персистентность: защитное программирование

Ещё одна архитектурная ловушка — перезагрузка устройства. Если телефон ребутится, вся внутренняя стейт-машина приложения сбрасывается. Без слушателя ACTION_BOOT_COMPLETED, который перерегистрирует задачи WorkManager и восстанавливает ForegroundService, приложение просто перестаёт работать до тех пор, пока пользователь не откроет его вручную. Для приложения, позиционируемого как «работает в фоне и не требует внимания», это критический дефект.

Автор формулирует важный принцип: персистентность должна быть defensive. Нужно исходить из того, что система убьёт ваш процесс в самый неподходящий момент, и восстановление состояния из локальной базы должно занимать миллисекунды, а не секунды.

Архитектурные итоги и честная ретроспектива

Автор признаёт несколько ошибок, которые допустил на старте:

• Обработка слишком многих сложных edge cases в основном потоке сервиса вместо выноса вычислений в отдельный Dispatchers.IO через корутины.
• Недооценка архитектуры локальной базы данных. Рутины оказались не независимыми объектами, а частью сложной темпоральной стейт-машины. Смешивание простых флагов и сложных логических связей в одной SQLite-базе добавило ненужную сложность — лучше разделить на DataStore для простых данных и SQLite для истории и связей.
• Излишняя надежда на стандартное поведение платформы вместо проектирования под самый рестриктивный сценарий.

Что это значит для пользователя

С точки зрения конечного пользователя, приложение Muffle решает реальную боль — автоматическое переключение звуковых профилей по времени и геолокации. Но сама история его разработки — хорошая иллюстрация того, почему подобных приложений на рынке удивительно мало, и почему те, что есть, часто работают нестабильно на устройствах отдельных производителей.

Android-платформа последние восемь лет движется в сторону всё более агрессивного ограничения фоновой активности. Это хорошо для батареи, но создаёт барьер для целого класса приложений, которые по определению должны работать в фоне. Пользователям стоит понимать: установить такое приложение недостаточно — на устройствах Xiaomi, Oppo и некоторых моделях Samsung потребуется ручная настройка исключений из оптимизации батареи.

Если вы ищете подобное решение, стоит проверить, поддерживает ли оно именно вашу модель устройства и версию прошивки. Эмулятор Pixel — это не реальный мир Android.