Наша Service и опасна и трудна или некоторые аспекты выживания служб в Android

[raid]

Где-то месяц назад долго и упорно бился с проблемой остановки сервиса при выкидывании приложения пальцем. Тогда так и не поняв, какого Линуса чёрта оно так работает, запустил foreground, благо, там это было приемлемо.

[Zeliret]

Приведите, пожалуйста, пример фоновой службы, которая должна что-то долго выполнять (тратя ресурсы устройства), но при этом не показывать иконку в статус баре? Мне кроме вирусов на ум ничего не приходит. Пользователь должен понимать, что пока висит эта иконка, батарея его устройства тратится быстрее, т.к. фоновая задача чем-то занимается.

А то сейчас полно приложений, которые что-то делают в фоне, без иконки, а на утро обнаруживаешь 5% заряда, если вайфай не отключил. Так что имхо, это правильно, что смахивание активити из истории убивает напрочь, я хотя бы уверен, что обнаружу телефон утром с зарядом.

[Valle]

Например, hangouts и вообще вся служба push нотификаций держит постоянное xmpp соединение из сервиса, но при этом не умирает (обычно). Понятно, что другие IM, кто хочет держать соединение, тоже хотели бы обладать таким свойством.

[alafix]

Пример из жизни. Приложение включает диктофон по n-ному нажатию кнопки Power. А по поводу смахиваний спорно, как я и писал, у пользователя на такие случаи всегда есть Force Stop в запасе.

[Zeliret]

Вы себе представляете Force Stop для 20+ приложений? Смахивание — максимально простой вариант для удаления таски.

А по поводу диктофона, странный пример, но годится. А вы засекали, сколько процентов батерии за день жрет сервис, который слушает нажатия?

[alafix]

Таски да, но не службы, не убедите, не для этого они рождены имхо :) К тому же START_STICKY и только вперед, за исключением ранних выпусков 4.4.1 и 4.4.2 (если не ошибаюсь). В итоге — служба работает, а смахнуть ее уже не получится. И так 20+ раз :)

[alafix]

По поводу батарейки. Нет, не засекал. Но однако думаю, что мизер. С чего сервису ее жрать-то, если он ничего не делает?

[Zeliret]

Зачем тогда сервис, если он ничего не делает? :)
Ладно, я вас понял, в любом случае. Пользователь конечно сам решит, держать ли у себя на телефоне такое приложение, исходя из соотношения пользы/расхода.

[alafix]

В описанном случае просто ждет интента, фильтр на который нельзя поставить в манифесте. А сервисом он решил назваться, только чтобы ненароком не умереть, ожидаючи :)

[pesh1983]

Мне одному в голову приходит идея реализации единственного сервиса-прокси, который, имея список сервисов и событий, по которым они должны запускаться, будет просто запускать сервис при наступлении события, которое к нему прикреплено. В таком случае, запущенный сервис будет только 1, а все остальные запускаются on demand и стопаются после выполнения своей работы

[Valle]

Это AlarmManager + BroadcastReceiver. Но длительную работу из броадкастов и будильников делать нельзя, для этого нужен сервис. А сервисы ненадежны, т.к. могут прибиться системой если они не foreground.

[Valle]

Если wake-lock не задействован, то почти нисколько, только если андроид не перезапускает этот процесс каждые пять минут.

[r_ii]

«Смахиванием» пользователь абсолютно четко дает понять, что ему не нужно смахиваемое приложение работающим. Если было бы нужным, то не смахивал-бы.
Для того, чтоб запретить системе убывать процесс, нужно присвоить параметру "/proc/{pid}/oom_adj" значение "-17". Но для этого нужны системные права.
Хотя опять-же это помогает от автоматического удаления при нехватке памяти. Полагаю что от «смахивания» это не защитит, так как система делает именно то, что пользователь запрашивает.

[alafix]

Видимо, зависит от приложения. Я, в частности, смахиванием хочу дать понять, что мне больше не нужно общение с этим приложением, а вот основной его функционал пусть остается, я за него заплатил целый доллар в Google Play,

[r_ii]

Так это делается проще — нужно просто закрыть приложение кнопкой Back.

[alafix]

Угу, с кучей ярлыков в рисентах впоследствии, листать — не перелистать.

[xapienz]

В этой ситуации ещё напрягает, что, например, при закрытии приложения Google Play Music из Recents воспроизведение музыки в приложении останавливается.

[alafix]

Плееры имхо идеальны для реализации как раз в виде foreground-службы именно с уведомлениями

[KamiSempai]

На самом деле, даже startForeground не всегда помогает. Если смахнуть задачу при работающем Foreground сервисе, то при получении им Broadcast сообщения без флага FLAG_RECEIVER_FOREGROUND, процесс будет убит.

Ссылка на англоязычную статью: possiblemobile.com/2014/06/effects-android-application-termination

[alafix]

Да, Вы абсолютно правы, есть такой момент. Детально не исследовал, поэтому писать не стал. Думаю, что этот эффект сродни тому, с которым сталкивался лично: если у foreground-service после смахивания выполнить stopForeground, то процесс тоже умрет. Видимо, при получении интента, Android на время его обработки изменяет приоритет на указанный в этом интенте, в том числе и в сторону понижения. Но это так, размышления, надо будет покопаться на досуге в исходниках.