Полный список
— создаем, запускаем и останавливаем простой сервис
Для начала надо определиться, как по-русски называть Service. Общепринятый перевод – служба. Наиболее популярный пример – службы в Windows. Но для системы Android мне привычнее использовать слово сервис. Его я и буду использовать в своих уроках для обозначения Service.
И еще один момент надо сразу прояснить. Service прописывается в манифесте рядом с Activity, и получается, что приложение (Application) содержит в себе и Activity и сервис. Предлагаю для упрощения изложения материала под словом приложение понимать все таки только Activity, которые можно запустить и увидеть на экране. Т.е. то, что мы раньше и называли приложением. А сервис считать отдельной от приложения вещью. А если надо будет обозначить приложение, как контейнер для Activity и сервиса, буду использовать слово Application.
Т.е. приложение – это набор Activity, сервис – Service. Приложение + сервис = Application. Как то так.
Итак, сервис – это некая задача, которая работает в фоне и не использует UI. Запускать и останавливать сервис можно из приложений и других сервисов. Также можно подключиться к уже работающему сервису и взаимодействовать с ним.
В качестве примера можно рассмотреть алгоритм почтовой программы. Она состоит из приложения и сервиса. Сервис работает в фоне и периодически проверяет наличие новой почты, скачивает ее и выводит уведомления. А когда вы запускаете приложение, оно отображает вам эти загруженные сервисом письма. Также приложение может подключиться к сервису и поменять в нем, например, период проверки почты или совсем закрыть сервис, если постоянная проверка почты больше не нужна.
Т.е. сервис нужен, чтобы ваша задача продолжала работать, даже когда приложение закрыто. В ближайших уроках мы разберемся, какие способы взаимодействия существуют между приложением и сервисом. В этом же уроке создадим простейший сервис, который будет выводить что-нибудь в лог. А приложение будет запускать и останавливать сервис.
Project name: P0921_ServiceSimple
Build Target: Android 2.3.3
Application name: ServiceSimple
Package name: ru.startandroid.develop.p0921servicesimple
Create Activity: MainActivity
Добавим в strings.xml строки:
Две кнопки – для запуска и остановки сервиса. И ProgressBar.
Рядом с MainActivity создайте класс MyService, наследующий android.app.Service
У сервиса так же, как и у Activity есть методы onCreate и onDestroy – которые срабатывают при создании и уничтожении сервиса.
Метод onStartCommand – срабатывает, когда сервис запущен методом startService. В нем мы запускаем наш метод someTask, который пока пуст. У onStartCommand на вход и на выход идут параметры, мы их пока не используем.
Метод onBind нам пока не интересен. Но реализовать его мы обязаны, возвращаем null.
someTask – здесь будем кодить работу для сервиса
Сервис, как и новые, создаваемые Activity необходимо прописать в манифесте. Делается это полностью аналогично. Жмете Add, выбираете Service. И в поле Name выбираете MyService.
Здесь у нас два метода, которые срабатывают при нажатии на кнопки Start service и Stop service. В них мы соответственно запускаем или останавливаем сервис методами startService и stopService. На вход передаем Intent, указывающий на сервис. Это очень похоже на то, как мы вызываем Activity методом startActivity.
Давайте все сохраним и запустим приложение.
Нажмем Start service и смотрим лог:
Выполнился метод onCreate – сервис создался, и onStartCommand – сервис выполняет содержимое метода onStartCommand.
Если мы теперь еще раз нажмем Start service:
Сервис уже создан, onCreate не вызывается, выполняется только метод onStartCommand.
Жмем Stop service
Убедимся, что сервис не зависит от приложения. Жмем Start service.
Сервис запущен. Закрываем приложение кнопкой Назад. В логах тишина, onDestroy в сервисе не выполнился, сервис продолжает жить. Ему все равно, работает приложение, его запустившее или не работает.
Долгим удержанием клавиши Домой выведем список последних приложений
снова откроем наше приложение и нажмем Stop service. В логах:
Теперь попробуем выполнять что-нибудь осмысленное в onStartCommand. Перепишем метод someTask в MyService.java:
Будем с интервалом в 1 секунду выводить в лог записи из сервиса.
Все сохраним, запустим и нажмем Start service:
ProgressBar замер, экран стал недоступен. А логи идут:
Вывод – сервис работает в основном потоке и блокирует экран.
Вынесем цикл с паузами в отдельный поток. И чтобы два раза не бегать, давайте заодно узнаем, что делает метод stopSelf.
Перепишем метод someTask:
Мы вынесли код в отдельный поток и добавили вызов метода stopSelf – этот метод аналогичен методу stopService, он останавливает сервис, в котором был вызван.
Все сохраняем, запускаем и жмем Start service. ProgressBar крутится, экран не блокирован, логи идут:
Сервис создался, выполнил работу и сам остановился методом stopSelf.
На следующем уроке:
— передаем данные в сервис
— рассматриваем методы остановки сервиса stopSelf и stopSelfResult
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме
Источник
Android Start/Stop Service from Activity Example using HandlerThread
android.app.Service
android.app.Service runs the long running process in background. Service does not interact to user. It will run in background even if the user switches to another application. While using Service we need to override methods. Some of them are as follows.
onCreate() : System calls it when service is first created. We can use it to initialize values for process.
onStartCommand(Intent intent, int flags, int startId) : System calls it when service is started explicitly. For every service start call, it is called.
onBind(Intent): It is used for inter process communication(IPC). It returns null if clients can not bind to service.
onDestroy(): System calls it when service is completed or stopped. We can use it for resource cleanup purpose.
Service can stop itself by calling methods as follows.
stopSelf(): On calling it, Service is stopped if it is running.
stopSelfResult(int startId): Stops the service for the most recent start id.
Find some constants which are returned from onStartCommand(Intent, int, int) .
START_STICKY : It starts the onStartCommand if killed while stating.
START_NOT_STICKY : If service is killed while starting, it does not restart until explicitly service is started.
START_REDELIVER_INTENT : If service is killed while starting, it will schedule to restart with latest intent.
Источник
Наша Service и опасна и трудна или некоторые аспекты выживания служб в Android
Вместо введения
Во многих практических задачах требуется выполнение различных фоновых действий, будь то проигрывание музыки, обмен данными с сервером или просто слежение за действиями пользователя дабы похитить у него реквизиты кредитных карт. Ну а если не получится, то по крайней мере завалить его целевой рекламой, используя полученные сведения. Как уже давным-давно все знают, в Android такие вещи оформляются в виде службы (Service).
Официальная документация гласит, что ОС Android останавливает службу только в случае нехватки памяти. Тем не менее, существует и другие случаи. Пользователь может сам остановить службу, используя предоставляемые ему средства меню Settings/Apps, там же он может сделать и полную остановку приложения. Но для этого ему надо напрягаться и, в общем-то осознавать свои действия и их последствия. К сожалению, для уничтожения службы у него есть и другие возможности, которыми он может пользоваться бессознательно. В частности, если в нашем приложении ранее была запущена хоть одна Activity, видимая в истории, то пользователь буквально одним движением пальца сможет вынести соответствующую задачу. Как ни парадоксально, попутно Android вышибет и весь процесс вместе со службой.
Лично мне такое поведение Android логичным не кажется. Пользователь зачастую просто чистит Recent Apps от давно забытого хлама, совсем не обязательно он при этом желает отказаться от тех благ, которые ему предоставляла выполняющаяся служба. Однако разработчики Google мыслили немного по-другому. По-другому, так по-другому, их право, но в конце концов нам с вами тоже надо как-то жить.
Итак, каркас простейшего приложения для отработки приемов борьбы.
Здесь все элементарно. SomeActivity при создании запускает службу KamikadzeService, которая, в свою очередь, стартует, как липкая или sticky. Для агентов враждебных платформ поясню, что служба при старте дает указание операционной системе в случае непредвиденного завершения сервиса перезапустить его при первой возможности. Делает она это, возвращая START_STICKY из метода onStartCommand. Если служба не липкая, то после удаления пользователем задачи шансов на возрождение после смерти у нее не будет.
Метод onTaskRemoved вызывается системой как раз при удалении пользователем задачи. Здесь совершенно необходимо упомянуть об атрибуте службы android:stopWithTask, который можно выставить в манифесте. Как можно догадаться по его названию (либо просто почитав документацию), если android:stopWithTask = ”true”, то волевое движение пальца пользователя по нужному квадратику в Recent Tasks List наряду с удалением задачи будет и останавливать службу. Поскольку в этом случае сервис будет считаться согласным на остановку, то и перезапускать автоматически никто ничего не будет — умерла, так умерла.
В самом начале моей борьбы за относительную устойчивость сервисов, обнаружив наличие этого флага, я имел наивность предположить, что проблема решится установкой android:stopWithTask = ”false” и сервис больше не будет умирать вместе с задачей. Увы, действительность и мечтания имели ряд существенных отличий. Действительно, в этом случае система не будет останавливать службу. Она ее просто прибьет без соответствующего предупреждения. Кстати, по умолчанию этот атрибут равен ”false”, из чего уже можно было догадаться, что явная его установка ни к чему не приведет
Для столь же простодушных разработчиков подытожу: значение атрибута службы android:stopWithTask никак не влияет на ее шансы остаться в живых после удаления задачи пользователем, служба в любом случае обречена. Этот атрибут всего лишь определяет, какой метод сервис будет вызван перед уничтожением. Если он равен ”true”, то у службы будет вызван метод onDestroy (не во всех, мягко говоря, случаях, но об этом чуть позже). А если атрибут равен ”false”, то последним вздохом сервиса, заметным разработчику, будет запуск метода onTaskRemoved.
Изучив все это и всласть поэкспериментировав с приведенной программкой, можно сделать следующий вывод: у нас не получится избежать гибели background service при удалении задачи. Ну не получится и не получится, в конце концов легкой жизни никто не обещал. Раз уж система может перезапускать нашу липкую службу, пусть делает это. А мы просто будем время от времени сохранять ее состояние, восстанавливая его при возрождении службы из пепла. Увы, не все так просто.
KitKat. No rest for the wicked
Еще в СССР в конце 80-х в рамках цикла передач “Сколько-то там вечеров с Thames Television” показывали рекламу шоколада KitKat. Ни про какой KitKat никто в то время не слыхивал, но реклама была в новинку и просматривали ее с интересом. И я отлично запомнил слоган, который сейчас и воткнул в название раздела. Ибо отражает.
В качестве предисловия. Выше упоминалось, что при android:stopWithTask=”true” сервис именно останавливается, то есть перед смертью получает свой успокоительный onDestroy. Так было до появления Android KitKat, с приходом которого все неуловимо изменилось. При удалении пользователем задачи в этой и более поздних версиях Android служба перейдет в иной мир … бесследно. В подавляющем большинстве случаев. Если конечно, не считать возможный вызов onDestroy у Activity, попавшему пользователю под палец. Очевидно, что все это делает android:stopWithTask совершенно бесполезным для наших целей.
Но выпуск Android KitKat хорошо запомнился разработчикам фоновых служб совсем не поэтому. Дело в том, что в первоначальных вариантах этой версии крылась одна занимательная деталь, которая в свое время лично меня вогнала в состояние глубокой депрессии. KitKat никогда не перезапускал sticky-сервисы.
А дальше были крики душ программистов на stackoverflow, ворох тикетов в Google, исправления, обновления и т.д. Сколько таких прошивок до сих пор живы на устройствах, никто не знает. Но то, что они еще попадаются, это точно. Решение в лоб с попыткой перезапустить службу
не дает ничего, поскольку Android сначала отработает старт, а лишь потом со спокойной совестью уничтожит службу. Здесь придется добавить костыль в виде AlarmManager:
То есть планируем перезапуск службы вручную через три секунды после удаления задачи. Время взято с потолка.
Передний край нащупала разведка
Тот, кто читал эту статью сначала, помнит мое утверждение о неотвратимости смерти background service при удалении задачи. Признаюсь, я здесь немного манипулировал терминами. На самом деле у службы существует способ остаться целой и невредимой, но уже в виде foreground service. Например, так:
При создании служба создает уведомление, в нашем случае это всего лишь иконка приложения. Созданное уведомление передается в метод startForeground и — вуаля — служба становится почти бессмертной. Удаление задачи на нее никак не повлияет, да и при нехватке памяти она будет останавливаться только в самом крайнем случае. Практически единственный способ ее остановить — нажимание соответствующих кнопок в Settings/Apps, что, в общем-то и требовалось. Так зачем же я городил огород до этого? А дело в этом самом уведомлении, которое Google с давних пор требует для перевода службы на передний план. Оно заметно для пользователя, заметно даже если его создать с прозрачной иконкой. А для ряда приложений это не всегда хорошо. Я сейчас говорю не о троянах и прочих вредоносных программах, их создатели вряд ли озабочены описываемой проблемой вообще, поскольку по определению не должны показывать пользователю что-то, за что он может потянуть. Просто показ уведомлений, не обусловленных реальной необходимостью, выглядит, на мой взгляд, глуповато. Пользователь это также чувствует и зачастую это его даже раздражает, как видно из комментариев к некоторым приложениям в Google Play.
Но и против уведомлений у нас нашлись методы, правда это уже не костыль, а скорее, хак. Добавим еще одну службу в проект:
А onCreate в KamikadzeService перепишем так:
Суть подхода в том, что служба HideNotificationService, выйдя не передний план с тем же идентификатором 777, уходит опять на задний с удалением своего уведомления. Заодно уничтожается и уведомление KamikadzeService, но последняя остается на переднем плане, причем уже «на первый взгляд, как будто, не видна». После этого служба HideNotificationService прекращает работу. Следует уточнить, что порядок запуска служб, как и их выхода на передний план здесь не имеет значения, главное обеспечить, чтобы stopForeground второй (HideNotificationService) был вызван позже, чем startForeground первой (KamikadzeService). И обязательно равенство идентификаторов, передаваемых в startForeground.
И здесь опять возникает резонный вопрос — если все это прекрасно работает, зачем я ранее долго и нудно разжевывал про повадки ”чисто” фоновых служб? Да потому что описанный прием — хак и хак достаточно грязный, чтобы им еще долго можно было пользоваться. Хотя в эмуляторе с прилетевшим на днях Android 6.0 это пока работает. Надеяться или не надеяться — решать читателю.
Источник
