Когда система может перезапустить Service

А, слушай, вот тебе наглядный пример, как эта система может взять и перезапустить твой Service на ровном месте. Сидит он себе, работает, и тут — бац! — его нет. А потом он снова есть. Магия, блядь? Нет, просто Android, ёпта.

Итак, сценарии, когда эта мартышлюшка может ожить:

1. Нехватка памяти. Это классика, ебать мои старые костыли. Системе не хватает оперативки, она смотрит на твой сервис и думает: "А пошёл ты на хуй, ядрёна вошь". И убивает его процесс. Но если ты в onStartCommand вернул START_STICKY или START_REDELIVER_INTENT, система, немного постыдившись, сама же его и пересоздаст, как ни в чём не бывало. Типа "ой, сорян, братан, на тебе твой сервис обратно".

2. Возврат из onStartCommand(). Вот тут вся магия и завязана. Что ты вернёшь, то и получишь. Вернул START_STICKY — система попытается пересоздать сервис, но уже без того интента, с которым его убили. Вернул START_REDELIVER_INTENT — ну тут вообще красота, система не только сервис вернёт, но и последний интент ему вручит, типа "держи, мы тут всё сохранили, извини за неудобства".

3. Явный вызов startService(). Ну тут всё просто, как три копейки. Сервис остановили, а потом ты или кто-то другой такой: "А давайте-ка его ещё раз запустим!" И понеслась. Никакой магии, просто команда.

Вот смотри, как это в коде выглядит, проще некуда:

override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
    // Тут твоя бизнес-логика, которая может в любой момент накрыться медным тазом
    return START_STICKY // Или START_REDELIVER_INTENT — выбирай, что тебе больше по душе
}

Вот и вся философия. Сделал правильно — сервис будет как кошка, которая гуляет сама по себе, но всегда возвращается. Сделал криво — он просто сдохнет, и доверия ебать ноль, что он воскреснет.