В чем разница bound service и обычного сервиса в Android?

Что проверяют

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

Как отвечать

Разница в том, кто управляет временем жизни:

• started service: запускается через startService() или startForegroundService(), работу получает в onStartCommand(), живёт, пока сам не вызовет stopSelf() или его не остановят через stopService(). Возвращаемое значение START_STICKY, START_NOT_STICKY или START_REDELIVER_INTENT определяет поведение после убийства процесса;
• bound service: клиент вызывает bindService() с ServiceConnection, сервис отдаёт IBinder из onBind(). Живёт, пока привязан хотя бы один клиент, после отвязки последнего уничтожается;
• оба сразу: сервис может быть и запущенным, и привязанным. Тогда он уничтожается, только когда его остановили и отвязались все клиенты.

Способы общения с bound service: наследник Binder с прямым доступом к сервису внутри одного процесса, Messenger для простого межпроцессного обмена, AIDL для межпроцессного API с параллельными вызовами.

Современный контекст обязателен. С Android 8 приложение в фоне не может запустить фоновый сервис, нужен foreground service с уведомлением. С Android 14 для него обязателен тип в манифесте (dataSync, mediaPlayback, location и другие). Отложенную и гарантированную работу вроде синхронизации сегодня делают через WorkManager, а плеер строят на MediaSessionService из Media3: это как раз foreground-сервис, к которому привязываются клиенты.

Где спотыкаются

Считают, что сервис работает в отдельном потоке. onStartCommand() и onBind() вызываются в главном потоке, и сеть там приведёт к NetworkOnMainThreadException или ANR.

Предлагают для загрузки обычный started service, не зная про фоновые ограничения и WorkManager.

Забывают unbindService() в парном колбэке (привязка в onStart(), отвязка в onStop()). Получают утечку ServiceConnection, а после отвязки удивляются, что запущенный сервис продолжает работать.