Comments 20
Где-то месяц назад долго и упорно бился с проблемой остановки сервиса при выкидывании приложения пальцем. Тогда так и не поняв, какого Линуса чёрта оно так работает, запустил foreground, благо, там это было приемлемо.
Приведите, пожалуйста, пример фоновой службы, которая должна что-то долго выполнять (тратя ресурсы устройства), но при этом не показывать иконку в статус баре? Мне кроме вирусов на ум ничего не приходит. Пользователь должен понимать, что пока висит эта иконка, батарея его устройства тратится быстрее, т.к. фоновая задача чем-то занимается.
А то сейчас полно приложений, которые что-то делают в фоне, без иконки, а на утро обнаруживаешь 5% заряда, если вайфай не отключил. Так что имхо, это правильно, что смахивание активити из истории убивает напрочь, я хотя бы уверен, что обнаружу телефон утром с зарядом.
А то сейчас полно приложений, которые что-то делают в фоне, без иконки, а на утро обнаруживаешь 5% заряда, если вайфай не отключил. Так что имхо, это правильно, что смахивание активити из истории убивает напрочь, я хотя бы уверен, что обнаружу телефон утром с зарядом.
Пример из жизни. Приложение включает диктофон по n-ному нажатию кнопки Power. А по поводу смахиваний спорно, как я и писал, у пользователя на такие случаи всегда есть Force Stop в запасе.
Вы себе представляете Force Stop для 20+ приложений? Смахивание — максимально простой вариант для удаления таски.
А по поводу диктофона, странный пример, но годится. А вы засекали, сколько процентов батерии за день жрет сервис, который слушает нажатия?
А по поводу диктофона, странный пример, но годится. А вы засекали, сколько процентов батерии за день жрет сервис, который слушает нажатия?
Таски да, но не службы, не убедите, не для этого они рождены имхо :) К тому же START_STICKY и только вперед, за исключением ранних выпусков 4.4.1 и 4.4.2 (если не ошибаюсь). В итоге — служба работает, а смахнуть ее уже не получится. И так 20+ раз :)
По поводу батарейки. Нет, не засекал. Но однако думаю, что мизер. С чего сервису ее жрать-то, если он ничего не делает?
Зачем тогда сервис, если он ничего не делает? :)
Ладно, я вас понял, в любом случае. Пользователь конечно сам решит, держать ли у себя на телефоне такое приложение, исходя из соотношения пользы/расхода.
Ладно, я вас понял, в любом случае. Пользователь конечно сам решит, держать ли у себя на телефоне такое приложение, исходя из соотношения пользы/расхода.
В описанном случае просто ждет интента, фильтр на который нельзя поставить в манифесте. А сервисом он решил назваться, только чтобы ненароком не умереть, ожидаючи :)
Мне одному в голову приходит идея реализации единственного сервиса-прокси, который, имея список сервисов и событий, по которым они должны запускаться, будет просто запускать сервис при наступлении события, которое к нему прикреплено. В таком случае, запущенный сервис будет только 1, а все остальные запускаются on demand и стопаются после выполнения своей работы
Если wake-lock не задействован, то почти нисколько, только если андроид не перезапускает этот процесс каждые пять минут.
«Смахиванием» пользователь абсолютно четко дает понять, что ему не нужно смахиваемое приложение работающим. Если было бы нужным, то не смахивал-бы.
Для того, чтоб запретить системе убывать процесс, нужно присвоить параметру "/proc/{pid}/oom_adj" значение "-17". Но для этого нужны системные права.
Хотя опять-же это помогает от автоматического удаления при нехватке памяти. Полагаю что от «смахивания» это не защитит, так как система делает именно то, что пользователь запрашивает.
Для того, чтоб запретить системе убывать процесс, нужно присвоить параметру "/proc/{pid}/oom_adj" значение "-17". Но для этого нужны системные права.
Хотя опять-же это помогает от автоматического удаления при нехватке памяти. Полагаю что от «смахивания» это не защитит, так как система делает именно то, что пользователь запрашивает.
В этой ситуации ещё напрягает, что, например, при закрытии приложения Google Play Music из Recents воспроизведение музыки в приложении останавливается.
На самом деле, даже startForeground не всегда помогает. Если смахнуть задачу при работающем Foreground сервисе, то при получении им Broadcast сообщения без флага FLAG_RECEIVER_FOREGROUND, процесс будет убит.
Ссылка на англоязычную статью: possiblemobile.com/2014/06/effects-android-application-termination
Ссылка на англоязычную статью: possiblemobile.com/2014/06/effects-android-application-termination
Да, Вы абсолютно правы, есть такой момент. Детально не исследовал, поэтому писать не стал. Думаю, что этот эффект сродни тому, с которым сталкивался лично: если у foreground-service после смахивания выполнить stopForeground, то процесс тоже умрет. Видимо, при получении интента, Android на время его обработки изменяет приоритет на указанный в этом интенте, в том числе и в сторону понижения. Но это так, размышления, надо будет покопаться на досуге в исходниках.
Sign up to leave a comment.
Наша Service и опасна и трудна или некоторые аспекты выживания служб в Android