0,0
рейтинг
20 августа 2015 в 12:31

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

Вместо введения


Во многих практических задачах требуется выполнение различных фоновых действий, будь то проигрывание музыки, обмен данными с сервером или просто слежение за действиями пользователя дабы похитить у него реквизиты кредитных карт. Ну а если не получится, то по крайней мере завалить его целевой рекламой, используя полученные сведения. Как уже давным-давно все знают, в Android такие вещи оформляются в виде службы (Service).

Официальная документация гласит, что ОС Android останавливает службу только в случае нехватки памяти. Тем не менее, существует и другие случаи. Пользователь может сам остановить службу, используя предоставляемые ему средства меню Settings/Apps, там же он может сделать и полную остановку приложения. Но для этого ему надо напрягаться и, в общем-то осознавать свои действия и их последствия. К сожалению, для уничтожения службы у него есть и другие возможности, которыми он может пользоваться бессознательно. В частности, если в нашем приложении ранее была запущена хоть одна Activity, видимая в истории, то пользователь буквально одним движением пальца сможет вынести соответствующую задачу. Как ни парадоксально, попутно Android вышибет и весь процесс вместе со службой.

Лично мне такое поведение Android логичным не кажется. Пользователь зачастую просто чистит Recent Apps от давно забытого хлама, совсем не обязательно он при этом желает отказаться от тех благ, которые ему предоставляла выполняющаяся служба. Однако разработчики Google мыслили немного по-другому. По-другому, так по-другому, их право, но в конце концов нам с вами тоже надо как-то жить.

Итак, каркас простейшего приложения для отработки приемов борьбы.

SomeActivity.java:
public class SomeActivity extends Activity {

	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		Log.i("Test", "Activity: onCreate");
		Intent serviceIntent = new Intent(this, MyService.class);
		startService(serviceIntent);
	}

	@Override
	protected void onDestroy() {
		super.onDestroy();
		Log.i("Test", "Activity: onDestroy");
	}

}

KamikadzeService.java:
public class KamikadzeService extends Service {

	@Override
	public IBinder onBind(Intent intent) {
		return null;
	}

	@Override
	public void onCreate() {
		Log.i("Test", "Service: onCreate");
	}

	@Override
	public int onStartCommand(Intent intent, int flags, int startId) {
		Log.i("Test", "Service: onStartCommand");
		return START_STICKY;
	}
		
	@Override
	public void onDestroy() {
		super.onDestroy();
		Log.i("Test", "Service: onDestroy");
	}

	@Override
	public void onTaskRemoved(Intent rootIntent) {		
		Log.i("Test", "Service: onTaskRemoved");
	}

}

Здесь все элементарно. 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, исправления, обновления и т.д. Сколько таких прошивок до сих пор живы на устройствах, никто не знает. Но то, что они еще попадаются, это точно. Решение в лоб с попыткой перезапустить службу

	@Override
	public void onTaskRemoved(Intent rootIntent) {		
		Log.i("Test", "Service: onTaskRemoved");
		if (Build.VERSION.SDK_INT == 19)
		{
			Intent restartIntent = new Intent(this, getClass());
			startService(restartIntent);
		}
	}

не дает ничего, поскольку Android сначала отработает старт, а лишь потом со спокойной совестью уничтожит службу. Здесь придется добавить костыль в виде AlarmManager:

	@Override
	public void onTaskRemoved(Intent rootIntent) {
		Log.i("Test", "Service: onTaskRemoved");
		if (Build.VERSION.SDK_INT == 19)
		{
			Intent restartIntent = new Intent(this, getClass());

			AlarmManager am = (AlarmManager) getSystemService(ALARM_SERVICE);
			PendingIntent pi = PendingIntent.getService(this, 1, restartIntent, 
					PendingIntent.FLAG_ONE_SHOT);
			restartIntent.putExtra(“RESTART”
			am.setExact(AlarmManager.RTC, System.currentTimeMillis() + 3000, pi);
		}
	}


То есть планируем перезапуск службы вручную через три секунды после удаления задачи. Время взято с потолка.

Передний край нащупала разведка


Тот, кто читал эту статью сначала, помнит мое утверждение о неотвратимости смерти background service при удалении задачи. Признаюсь, я здесь немного манипулировал терминами. На самом деле у службы существует способ остаться целой и невредимой, но уже в виде foreground service. Например, так:

public class KamikadzeService extends Service {
	// ...
	
	@Override
	public void onCreate() {
		Log.i("Test", "Service: onCreate");
				
		Notification.Builder builder = new Notification.Builder(this)
			.setSmallIcon(R.drawable.ic_launcher);
		Notification notification;
		if (Build.VERSION.SDK_INT < 16)
			notification = builder.getNotification();
		else
			notification = builder.build();		
		startForeground(777, notification);	
	}

	// ...
}

При создании служба создает уведомление, в нашем случае это всего лишь иконка приложения. Созданное уведомление передается в метод startForeground и — вуаля — служба становится почти бессмертной. Удаление задачи на нее никак не повлияет, да и при нехватке памяти она будет останавливаться только в самом крайнем случае. Практически единственный способ ее остановить — нажимание соответствующих кнопок в Settings/Apps, что, в общем-то и требовалось. Так зачем же я городил огород до этого? А дело в этом самом уведомлении, которое Google с давних пор требует для перевода службы на передний план. Оно заметно для пользователя, заметно даже если его создать с прозрачной иконкой. А для ряда приложений это не всегда хорошо. Я сейчас говорю не о троянах и прочих вредоносных программах, их создатели вряд ли озабочены описываемой проблемой вообще, поскольку по определению не должны показывать пользователю что-то, за что он может потянуть. Просто показ уведомлений, не обусловленных реальной необходимостью, выглядит, на мой взгляд, глуповато. Пользователь это также чувствует и зачастую это его даже раздражает, как видно из комментариев к некоторым приложениям в Google Play.

Но и против уведомлений у нас нашлись методы, правда это уже не костыль, а скорее, хак. Добавим еще одну службу в проект:

public class HideNotificationService extends Service {

	@Override
	public IBinder onBind(Intent intent) {
		return null;
	}

	@Override
	public void onCreate() {
		Notification.Builder builder = new Notification.Builder(this)
			.setSmallIcon(R.drawable.ic_launcher);
		Notification notification;
		if (Build.VERSION.SDK_INT < 16)
			notification = builder.getNotification();
		else
			notification = builder.build();
		
		startForeground(777, notification);
		stopForeground(true);
	}

}

А onCreate в KamikadzeService перепишем так:

public class KamikadzeService extends Service {
	// ...

	@Override
	public void onCreate() {
		Log.i("Test", "Service: onCreate");
		Notification.Builder builder = new Notification.Builder(this)
			.setSmallIcon(R.drawable.ic_launcher);
		Notification notification;
		if (Build.VERSION.SDK_INT < 16)
			notification = builder.getNotification();
		else
			notification = builder.build();
			
		startForeground(777, notification);
		Intent hideIntent = new Intent(this, HideNotificationService.class);
		startService(hideIntent);
	}

	// ...
}

Суть подхода в том, что служба HideNotificationService, выйдя не передний план с тем же идентификатором 777, уходит опять на задний с удалением своего уведомления. Заодно уничтожается и уведомление KamikadzeService, но последняя остается на переднем плане, причем уже «на первый взгляд, как будто, не видна». После этого служба HideNotificationService прекращает работу. Следует уточнить, что порядок запуска служб, как и их выхода на передний план здесь не имеет значения, главное обеспечить, чтобы stopForeground второй (HideNotificationService) был вызван позже, чем startForeground первой (KamikadzeService). И обязательно равенство идентификаторов, передаваемых в startForeground.

И здесь опять возникает резонный вопрос — если все это прекрасно работает, зачем я ранее долго и нудно разжевывал про повадки ”чисто” фоновых служб? Да потому что описанный прием — хак и хак достаточно грязный, чтобы им еще долго можно было пользоваться. Хотя в эмуляторе с прилетевшим на днях Android 6.0 это пока работает. Надеяться или не надеяться — решать читателю.
Александр Афанасьев @alafix
карма
11,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (20)

  • 0
    Где-то месяц назад долго и упорно бился с проблемой остановки сервиса при выкидывании приложения пальцем. Тогда так и не поняв, какого Линуса чёрта оно так работает, запустил foreground, благо, там это было приемлемо.
  • +3
    Приведите, пожалуйста, пример фоновой службы, которая должна что-то долго выполнять (тратя ресурсы устройства), но при этом не показывать иконку в статус баре? Мне кроме вирусов на ум ничего не приходит. Пользователь должен понимать, что пока висит эта иконка, батарея его устройства тратится быстрее, т.к. фоновая задача чем-то занимается.

    А то сейчас полно приложений, которые что-то делают в фоне, без иконки, а на утро обнаруживаешь 5% заряда, если вайфай не отключил. Так что имхо, это правильно, что смахивание активити из истории убивает напрочь, я хотя бы уверен, что обнаружу телефон утром с зарядом.
    • 0
      Например, hangouts и вообще вся служба push нотификаций держит постоянное xmpp соединение из сервиса, но при этом не умирает (обычно). Понятно, что другие IM, кто хочет держать соединение, тоже хотели бы обладать таким свойством.
  • 0
    Пример из жизни. Приложение включает диктофон по n-ному нажатию кнопки Power. А по поводу смахиваний спорно, как я и писал, у пользователя на такие случаи всегда есть Force Stop в запасе.
    • 0
      Вы себе представляете Force Stop для 20+ приложений? Смахивание — максимально простой вариант для удаления таски.

      А по поводу диктофона, странный пример, но годится. А вы засекали, сколько процентов батерии за день жрет сервис, который слушает нажатия?
      • 0
        Таски да, но не службы, не убедите, не для этого они рождены имхо :) К тому же START_STICKY и только вперед, за исключением ранних выпусков 4.4.1 и 4.4.2 (если не ошибаюсь). В итоге — служба работает, а смахнуть ее уже не получится. И так 20+ раз :)
      • 0
        По поводу батарейки. Нет, не засекал. Но однако думаю, что мизер. С чего сервису ее жрать-то, если он ничего не делает?
        • 0
          Зачем тогда сервис, если он ничего не делает? :)
          Ладно, я вас понял, в любом случае. Пользователь конечно сам решит, держать ли у себя на телефоне такое приложение, исходя из соотношения пользы/расхода.
          • 0
            В описанном случае просто ждет интента, фильтр на который нельзя поставить в манифесте. А сервисом он решил назваться, только чтобы ненароком не умереть, ожидаючи :)
            • 0
              Мне одному в голову приходит идея реализации единственного сервиса-прокси, который, имея список сервисов и событий, по которым они должны запускаться, будет просто запускать сервис при наступлении события, которое к нему прикреплено. В таком случае, запущенный сервис будет только 1, а все остальные запускаются on demand и стопаются после выполнения своей работы
              • 0
                Это AlarmManager + BroadcastReceiver. Но длительную работу из броадкастов и будильников делать нельзя, для этого нужен сервис. А сервисы ненадежны, т.к. могут прибиться системой если они не foreground.
      • 0
        Если wake-lock не задействован, то почти нисколько, только если андроид не перезапускает этот процесс каждые пять минут.
  • 0
    «Смахиванием» пользователь абсолютно четко дает понять, что ему не нужно смахиваемое приложение работающим. Если было бы нужным, то не смахивал-бы.
    Для того, чтоб запретить системе убывать процесс, нужно присвоить параметру "/proc/{pid}/oom_adj" значение "-17". Но для этого нужны системные права.
    Хотя опять-же это помогает от автоматического удаления при нехватке памяти. Полагаю что от «смахивания» это не защитит, так как система делает именно то, что пользователь запрашивает.
    • 0
      Видимо, зависит от приложения. Я, в частности, смахиванием хочу дать понять, что мне больше не нужно общение с этим приложением, а вот основной его функционал пусть остается, я за него заплатил целый доллар в Google Play,
      • 0
        Так это делается проще — нужно просто закрыть приложение кнопкой Back.
        • 0
          Угу, с кучей ярлыков в рисентах впоследствии, листать — не перелистать.
  • 0
    В этой ситуации ещё напрягает, что, например, при закрытии приложения Google Play Music из Recents воспроизведение музыки в приложении останавливается.
    • 0
      Плееры имхо идеальны для реализации как раз в виде foreground-службы именно с уведомлениями
  • 0
    На самом деле, даже startForeground не всегда помогает. Если смахнуть задачу при работающем Foreground сервисе, то при получении им Broadcast сообщения без флага FLAG_RECEIVER_FOREGROUND, процесс будет убит.

    Ссылка на англоязычную статью: possiblemobile.com/2014/06/effects-android-application-termination
    • 0
      Да, Вы абсолютно правы, есть такой момент. Детально не исследовал, поэтому писать не стал. Думаю, что этот эффект сродни тому, с которым сталкивался лично: если у foreground-service после смахивания выполнить stopForeground, то процесс тоже умрет. Видимо, при получении интента, Android на время его обработки изменяет приоритет на указанный в этом интенте, в том числе и в сторону понижения. Но это так, размышления, надо будет покопаться на досуге в исходниках.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.