Android studio service неубиваемый

Building an Android service that never stops running

I’ve been struggling these days trying to find a way to run an endless service in Android. This is just a guide for all of you who pursue the same goal. Hope it helps!

The problem

Due to Android battery optimizations introduced in Android 8.0 (API level 26), background services have now some important limitations. Essentially, they are killed once the app is in background for a while making them worthless for our purpose of running an always-running service.

According to Android recommendations, we should be using JobScheduler, which seems to work pretty well and will handle wakelocks for us, keeping the phone awake while the jobs are running.

Unfortunately, this won’t work either. JobScheduler will run jobs at Android’s discretion and, on top of that, once the phone enters in Doze Mode, the frequency of these jobs being run will constantly decrease. And even worst, if you ever want to access the network -say you need to send data to your server- you won’t be able to. Check out the list of restrictions Doze Mode imposes.

JobScheduler works well if you don’t mind about not having access to the network and you don’t care about not controlling the periodicity either. In our case, we want our service to run at a very specific frequency and never be stopped, so we’ll need something else.

It’s all about Foreground Services

If you’ve been looking over the internet for a solution to this problem it’s very likely that you’ve eventually arrived to this page from the Android’s documentation.

There, we are introduced to the different types of services that Android provides. Take a look at the Foreground Service description:

A foreground service performs some operation that is noticeable to the user. For example, an audio app would use a foreground service to play an audio track. Foreground services must display a Notification. Foreground services continue running even when the user isn’t interacting with the app.

It seems to be precisely what we’re looking for… an it is, indeed!

Show me the code

Creating a foreground service is really a straight-forward process so I will visit and explain all the steps needed to build a foreground service that never stops.

As usual, I’ve created a repository with all the code in case you want to take a look at it and skip the rest of the post.

Adding some dependencies

I’m using Kotlin for this example, so we will be leveraging coroutines and the Fuel library for HTTP requests.

In order to add these dependencies we must add them to our build.gradle file:

Writing our service

Foreground Services need a notification to be shown so the user is aware that the app is still running. That makes sense if you think about it.

Note that we will have to override some of the Service callback methods that handle key aspects of the service lifecycle.

It’s also very important that we use a partial wakelock so our service never gets affected by Doze Mode. Bear in mind that this will have an impact in the battery life of our phone so we must evaluate whether our use case can be handled by any of the other alternatives Android offers in order to run processes in the background.

There are some utility function calls ( log , setServiceState ) and some custom enums ( ServiceState.STARTED ) in the code, but don’t worry too much. If you want to see where they come from, just take a look at the example repository.

Time to deal with the Android Manifest

We will need some extra permissions for FOREGROUND_SERVICE , INTERNET and WAKE_LOCK . Be sure you don’t forget to include them because it won’t work otherwise.

Once we put them in place we will need to declare our service.

Can you tell me how I start the service?

Yes, you’re right. You see, depending on the Android version we must start the service with a particular method.

If the Android version is below API 26 we must use startService. In any other case, startForegroundService is what we must use instead.

Here you can see our MainActivity , just a screen with two buttons to start and stop the service. That’s all you need to start our endless service.

Remember that you can check out the complete code in this GitHub repository.

Bonus: Start the service on Android boot

Ok, we now have our endless service making network requests every minute as we wanted but then the user restarts the phone… and our service doesn’t start again…

Don’t worry, we can find a solution for this, too. We will create a BroadCastReceiver called StartReceiver .

Then, we’ll modify again our Android Manifest and add a new permission ( RECEIVE_BOOT_COMPLETED ) and our new BroadCastReceiver.

Take into account that the service won’t be rebooted unless it was already running. That’s how we programmed it, it’s not that it has to be like that.

Anyway, if you want to test this, just spin up one emulator with Google Services in it and be sure to be running adb in root mode.

Bonus 2: Restart the service when the task is removed

Michal Materowski wrote to me with this case and its solution, so kudos for him!

Theoretically, according to Android documentation, returning RETURN_STICKY from the service’s onStartCommand method should be enough for Android to keep the foreground service running.

Michal was testing all this with a Xiaomi Note 5 with Android Pie and every time he swiped an app from recent apps, it worked flawlessly. Unfortunately, whenever he pressed the Clear all recent apps button (MIUI specific), the service was stopped and the notification was gone. The Clear all recent apps button was probably doing some sort of battery life optimization by killing all processes and their associated services.

He found out that Android documentation states that onTaskRemoved “is called if the service is currently running and the user has removed a task that comes from the service’s application.”, so the plan was to leverage this to restart the service. Bear in mind, though, that onTaskRemoved is not called if the application is killed in any other way (e.g. stopped from the phone settings).

Add these lines to your service:

You can check out the original Michal Materowski’s PR with the whole code.

IMPORTANT: Michal had to manually set Autostart permission, otherwise the service was not started on boot.

According to Michal, some people mentioned that setting stopWithTask flag might help, but it didn’t make a difference for him:

Lots of kudos to Michal Materowski for his help on this case.

Источник

Находки программиста

Решения конкретных задач программирования. Java, Android, JavaScript, Flex и прочее. Настройка софта под Linux, методики разработки и просто размышления.

среда, 13 ноября 2013 г.

«Вечный Service» в Android

Когда мы делаем приложения, мы руководствуемся самыми гумаными соображениями. Мы хотим облегчить жизнь нашим клиентам, помочь им, защитить, вооружить против любых проблем этого ужасного мира. Но клиенты почему-то не хотят покоряться нашему мудрому руководству. Закрывают наше приложения, останавливают его, находят в списке «запущенных процессов» через настройки и опять-таки останавливают. Ну, как дети малые, ей-богу 😉 Если вы в своей всеобъемлющей мудрости хотите спасти своих клиентов от их самих, вам наверняка прийдётся защититься от их жалких попыток упавлять своим смартфоном. Как же это сделать? Перенести логику в Service, чтобы закрытие приложения не останавливало его работу? Недостаточно. Сделать в нём вечный цикл, вызвать startService() в onDestroy() — тоже. В конце концов эти неразумные существа могут перезагрузить смартфон и мы утратим над ними власть не сможем помогать им. Можно, конечно ловить событие загрузки (и ещё стопицот других системных событий) и поднимать наш сервис. Однако система на то и система, чтобы жить своими, непредсказуемыми событиями, а значит никакой гарантии, что эти события произойдут когда нам нужно, увы, нет. Как же нам быть? Ответ очевиден:

Этот механизм позволяет нам не ждать милостей от природы событий от системы, а «заказывать» ей свои собственные события. Мы говорим системе «разбудить» наше приложение через Х секунд и делаем то что нам нужно в течении этих Х секунд а потом завершаем работу. Если пользователь или система убили нас раньше, их радость будет недолгой. Наше приложение возродится как феникс и продолжит свою работу. Такая схема позволяет нам гарантированно и независимо от прихотей платформы оставаться в памяти всегда. Вот как это выглядит:

Это пока только Activity c кнопкой-переключателем. Сам сервис:

И не забываем добавить в AndroidManifest (в тег application) строки:

Но, шутки в сторону

Во-первых, лучший способ помогать своим пользователям — не создавать им новых проблем. Если вы всё-таки решили висеть в памяти их смартфона, то хотя бы не держите открытыми сетевые соединения и (не дай бог) не слушайте спутники GPS. Посадите клиенту батарею и потеряете клиента.
Во-вторых, сервис всё-таки не вечный. Приложение, которое «убили» в настройках перестаёт получать Broadcast-ы а значит уже не оживёт, пока клиент не запустит его снова.
И да, не ставьте слишком короткий интервал вызова вашего сервиса. В большинстве случаев ваш сервис будет ещё жив и вы его проигнорируете, а для системы такие вызовы совсем не «бесплатны».

Источник

Наша 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 это пока работает. Надеяться или не надеяться — решать читателю.

Источник