Закрывая приложение из недавних мы ожидаем, что оно будет убито. И чаще всего так он и было. Но в какой-то момент что-то пошло не так, и многие начали замечать, что настройки, которые должны были примениться после перезапуска приложения, игнорируются. Раньше такого точно не было и этому свидетельствуют жалобы на новое поведение.

Оказалось, что процесс приложения продолжает работать. И теперь, чтобы точно перезапустить приложение, нужно останавливать его в настройках. В первую очередь подумал, что это новая секретная оптимизацией недавних обновлений системы, так как при живом процессе onCreate у Application не вызывается повторно, а скорость запуска приложения ускоряется в разы. И оптимизацию скорее всего сделали в Android 14 и в свежих релизах. У меня на руках два устройства: Pixel 7 и Pixel 6 Pro. Оба с Android 14, но на Pixel 6 Pro нет такой оптимизации, — приложение умирает при удалении из недавних — но и сборка там февральская, когда как на Pixel 7 сентябрьская сборка и оптимизация присутствует.

Исследуем

Решил проверить не только наше приложение, и оказалось, что оптимизация работает не для всех. Например, сработала для Telegram и ряда банков, но не сработала, например, для Tooba. Для последнего в логах вывелось сообщение Killing 6505:site.tooba.android/u0a410 (adj 905): remove task, которого не было для других.

Стремясь понять всю цепочку событий начал исследование издалека, а именно с момента смахивания приложения из списка недавних. Происходит это в RecentsView, в котором в момент завершения анимации вызывается метод removeTaskInternal. Он делегирует вызов в ActivityManagerWrapper.

Делегирование на этом не заканчивается - обертка делегирует вызов в сервис IActivityTaskManager.

Единственной реализацией этого сервиса является ActivityTaskManagerService, который делегирует вызов в один из методов ActivityTaskSupervisor.

Тут не сильно важно, что вызовется в итоге, — removeTask или removeRootTask — потому что removeRootTask для простого случая начнет в цикле вызывать removeTask для всех листьев. Он же останавливает запущенные Activity и далее вызывает метод cleanUpRemovedTask. В этом методе выполняются три интересных действия:

• Очистка сервисов в cleanUpServices
• Проверка, что Activity завершились. Если нет, то убийство откладывается на 1000ms. После чего будет вызван метод killTaskProcessesIfPossible
• Убийство, если это возможно, в методе killTaskProcessesIfPossible

В killTaskProcessesIfPossible, происходит несколько проверок, к которым есть описание в виде комментариев и убийство снова делегируется в ActivityManagerInternal путем отправки сообщения.

ActivityManagerInternal реализует внутренний класс LocalService, который лежит внутри ActivityManagerService (не путать с ActivityTaskManagerService). И вот наконец мы пришли к месту, где начинает формироваться наш лог с сообщением "remove task".

Но, кроме этого, видно, что процесс будет убит, если выполняются условия:

• Процесс в фоне
• Нет работающих BroadcastReceiver
• Нет работающих Service

В ином случае мы откладываем убийство установкой флага в ProcessRecord. Теперь возникает вопрос: кто убьет приложение позже, так как никакое отложенного сообщение тут не отправляется?

Знакомьтесь, OomAdjuster. В задачи OomAdjuster входит определение состояния процесса, оценка oom_adj с предварительной сортировкой в CacheOomRanker, а так же он умеет замораживать и размораживать процессы, используя CachedAppOptimizer. Все эти процессы запускаются по различным триггерам по типу запуска какого-то компонента или его завершение. Даже смерть процесса - это триггер, который прилетает в OomAdjuster из ActivityManagerService и инициируется в слушателе состояния процесса AppDeathRecipient.

Убивать OomAdjuster умеет в случаях если приложение долго остается замороженным/закешированным или в случае, когда установлен флаг waitingToKill, который мы ранее видели в ActivityManagerService#LocalService, и выполнены те же самые условия. Поэтому получается, что флаг waitingToKill отложит убийство до возникновения любого триггера у OomAdjuster.

Теперь осталось понять, что именно изменилось в этих классах за последнее время. Долго искать не пришлось - нашелся такой коммит, который попал в основную ветку в феврале 2024, а сделан был еще в ноябре в 2023.

Изменения в коммите минимальные - перед убийством добавили проверку того, что имеются started сервисы в ActivityManagerService#LocalService и OomAdjuster.

Забавно, что коммент перед установкой флага ожидания, не обновили.

Сначала, изменение показалось странным, ведь ранее мы встречали такой метод как cleanUpService, где должна была происходить остановка сервисов аналогично тому, что рядом происходит остановка активностей. Оказалось, что метод делегируется в ActivityServices, который останавливает сервисы только в том случае, если у них в AndroidManifest.xml указан android:stopWithTask="true". В ином случае запускается большая цепочка событий определения того, когда стоит перезапустить сервис и с какими аргументами, но остановки сервиса не будет, следовательно, и остановки процесса приложения.

Эксплуатируем

Мы можем проверить гипотезы, попыткой воспроизвести проблему в приложении с одним сервисом. И, о чудо, приложение не умирает. Иногда 2 минуты, а иногда все 10.

При этом сам сервис OomAdjuster и ActivityServices уже убили ввиду его бездействия.

А вот с февральской сборкой на Pixel 6 Pro поведение не получается повторить - туда этот коммит не попал. Так же не получается повторить с флагом stopWithTask=true.

Теперь стало интересно как долго можно сохранять приложение живым. Для этого сделал приложение, в котором сервис стартует и периодически делает какую-то работу. Но есть еще вариант заставить приложение жить еще дольше, выкинув в onDestroy сервиса ошибку, чтобы процесс завершения сервиса не был успешным никогда. А затем эту ошибку можно поймать с помощью Thread.setDefaultUncaughtExceptionHandler, чтобы у нас не упало приложение. Но есть проблема, и она заключается в том, что из-за того, что мы выкинули ошибку в onDestroy, пользователь через некоторое время увидит диалог об ANR. И, если он не нажмет "Close App", то мы продолжим жить. Правда он будет получать этот диалог с определенной периодичностью.

Кроме этого, если пользователь зайдет в приложение, то оно у него не запустится дальше Splash Screen. Эту проблему можно исправить, перезапустив Looper в Exception Handler, но это все равно не поможет отвязаться от диалога с ANR.

Тут можно вспомнить, что кроме Service, который предотвращает убийство на некоторых версиях Android 14, есть еще BroadcastReceiver. Поэтому попробовал отправлять сообщение в моменте закрытия приложения и получил такой же эффект - приложение не будет убито. Кроме этого, мы, конечно, не можем запускать сервис из фона, но никто не запрещал отправлять широковещательное сообщение, поэтому вполне рабочий вариант отправлять новое сообщение в том же самом BroadcastReceiver.

Но если отправлять сообщения слишком часто, то система в OomAdjuster нас пометит как "excessive processes" и прибьет, потому что мы выполняем слишком много транзакций через Binder(хотя это не так уж часто возникает). И чтобы решить эту проблему, можно делать какую-либо работу или подобрать такой таймаут, чтобы и система нас не прибила, и ANR не вылез.

Так же можно поступить для Service в Android 15 - выполнять долгую работу в onDestroy и отправлять в конце сообщение BroadcastReceiver. Но работу в этом случае мы можем выполнять до 200 секунд и не получать ANR.

Ну и вишенкой будет запуск фонового сервиса при получении сообщения BOOT_COMPLETED в BroadcastReceiver. Экспериментально получилось убедиться, что Android такое позволяет делать.

Итог

Изменение, найденное случайным образом, привело к тому, что был найден способ поддерживать живым приложение очень долго. Благодаря этому приложение будет готово к запуску всегда, а его запуск будет приравниваться к запуску обычной Activity. В моем случае, приложение работало несколько часов до момента, пока устройство не ушло в глубокий сон. И все это без Activity, без Foreground Service и без permission'а на работу в фоне.

Я вынес код в отдельную библиотеку "Philosopher's Stone" и рядом добавил пример приложения, которое можно скачать в виде apk и протестировать сколько оно проживет на вашем устройстве. Для этого запустите приложение, а затем смахните его из списка недавних. Позже, периодически открывая и закрывая активность, вы будете видеть как долго работает приложение.

Опубликовано в Полуночные Зарисовки

Google начали делать свой инструмент для создания fat aar, но сильно его не доработали. В Open Source остались сомнительные решения, написанные на Groovy, поэтому сделал свой с блэкджеком, в смысле с shadow-jar.

Интро

Думаю многие слышали про такой формат дистрибуции нескольких библиотек или Gradle модулей, запакованных в один артефакт. В любом случае напомню, что по умолчанию каждый Gradle модуль с подключенным плагином com.android.library можно собрать как один aar, но могут быть случаи, когда все же есть необходимость объединить несколько библиотека в одном aar артефакте. Такая идея не нова. Например, в Java мире это называется uber jar или fat jar и готовится он с помощью довольно известных плагинов maven-shade-plugin и shadow-jar для Gradle.

Необходимость

Так ли нам нужен fat aar? В основном, нет. Если правильно организовать многомодульность в проекте и заложить то, что эти модули будут опубликованы как библиотеки, и все будет прекрасно.

Необходимость может появиться в ряде случаев. Например, если у вас есть локальные jar и aar файлы, которые нужно опубликовать вместе с библиотекой, но исходники уже утеряны. Другой пример, если не хочется раскрывать идеальную многомодульную архитектуру для пользователей библиотеки. В конце концов, может быть случай, что нужно поделиться куском приложения с другим проектом, а сроки горят.

Еще причин почему это может быть нужно, можете найти в issue по этой теме, который висит аж с 2017 года. В комментарии там пришли люди из разных компаний. Например, вот свежий комментарий человека из Netflix:

А Google что, не делает? На самом деле начинали делать в 2022 и назвали они свое творение Fused Library.

Fused Library

Да, плагин назван так, что его вряд ли кто-то нашёл бы... Но все же он нашёлся. К тому же, появлялись коммиты с обновлениями буквально в дни, когда я его смотрел.

Это свидетельствует о том, что ребята намерены продолжать разработку инструмента, хоть и был перерыв в два года.

Я потратил пару вечеров, пытаясь его завести, но лишь расстроился тому, насколько сырой все же инструмент.

1. Сразу бросается в глаза то, что он не умеет формировать aar файл...

Он все объединяет в jar. Понятно, что ошибка в том, не выставлено расширение файла при конфигурации задачи, но уже тут можно делать выводы, что решение нерабочее. И все же продолжил исследование инструмента на случай, если надумаю починить и доработать.

2. По картинке из пункта 1 можно заметить, что нет никаких классов в собранном jar. Все дело в том, что плагин даже это не умел делать, так как там забыли упаковать классы в jar. Благо это исправили в июле этого года.

3. Нет поддержки различных build variants. Поддерживает только один build type - debug. С учетом того, что fat aar чаще нужен в релизной сборке, такое нам не подойдет.

Тут завершу список проблем, потому что их просто нельзя починить. Да, реализация интересная и отличается от всего, что было до этого, но его нельзя доработать без форка всего AGP, так как используется internal api. К тому же, по последним изменениям непонятно, какие планы у разработчиков. Ясно одно, что проект все еще экспериментальный, поэтому велика вероятность того, что решения, которые будут приниматься, не совпадут с моими предложениями. (Как-то у меня была попытка законтрибьютить в AGP - там так же все же предпочли сделать по своему.)

Учитывая все это, прекратил ковырять этот плагин. Сильно сырой все же.

Что в Open Source?

Взяв весь свой пыл куда-нибудь закотрибьютить пошёл искать решения в GitHub. Нашёл пару решений, но самое популярное, написанное с использованием Groovy, уже заброшено. Этот заброшенный плагин был форком других похожих плагинов. Теперь уже его форкнули для поддержки AGP 8 и нетранзитивных R-классов.

В актуальном форке хоть и решили проблемы с AGP 8, но остались другие.

1. Есть проблема со слиянием ресурсов с одинаковыми id. Такое может быть, потому что плагин соединяет ресурсы только после того, как сформирует конечные артефакты.

2. Нет возможности выполнять формировать shaded jar, то есть перемещать классы в разные пакеты. Такое, например, делали в компиляторе Kotlin, чтобы зависимость для Idea не конфликтовала с зависимостью для Gradle. Ну и по проекту можно найти разные применения shadow-jar.

Пошёл искать дальше и обнаружил ещё один плагин. Он полностью написан на Kotlin, имеет еще больше проблем, некоторые вещи недоделаны, а поддерживается только AGP 4. Напомню, что на дворе AGP 8 и не за горами AGP 9.

И все же я решил оживить именно этот проект. Потому что, по моему мнению, автор старался делать иначе, чем в других проектах, и так, чтобы это было надежно. Это можно заметить по исследованию задач для формирования aar, результат которых он оставил в виде комментариев в коде.

Grease

Итак, что было сделано:

• Переход с AGP 4 на AGP 8.
• Доработал слияние ресурсов, вдохновившись Fused Library. Решение получилось надежнее, чем у fat-aar-android.
• Подключил shadow-jar и научил его трансформировать метаданные Kotlin и AndroidManifest.xml. Кроме того, работу shadow-jar можно конфигурировать.

Может показаться, что это немного, но по сути плагин был полностью переписан в рамках первого пункта.

Было большим удивлением то, что после того, как освежил инструмент, у него сразу появились клиенты, которые начали накидывать issues. Количество звезд при этом выросло в два раза. Поэтому, пока Google доделывает Fused Library, есть альтернатива в виде Grease.

Опубликовано в Полуночные Зарисовки

И вот в один день в мае пришел ко мне коллега, которому я до этого рекомендовал Layout Plugin, с новостями о том, что появился плагин для Compose. Оказалось, что они сделали его еще в прошлом году. Я бросился изучать как именно и что они сделали. В общем не увидел какого-то Rocket Science, а скорее код, который ранее уже видел в исходниках Layout Inspector в Android Studio. Вот например, LayoutInspectorThree, где они вытаскиваю SemanticsNode. И тот же класс в коде AS. Или, например, RecompositionHandler, который хукает виртуальную машину ART для подсчета количества рекомпозиций и пропусков. Вот он в исходниках AS.

В любом случае, все выглядело круто. Даже если код скопирован, есть шансы на то, что этот инструмент гибче и его можно сколько угодно допиливать, так как под рукой все SemanticsNode, а там можно и все Modifier.Node вытащить. Поэтому надо пробовать запустить. Но, к сожалению, первая попытка не увенчалась успехом:

Видимо, часть кода они скопировали, а часть вынесли в виде aar. Я так понял, что это локально собранная версия этой библиотеки, но поновее, так как, если заменить библиотеку механизмами Gradle, то при сборке не найдутся некоторые классы. Я не перый, кто пытался запустить этот плагин, но с тех пор, как его сделали, во Flipper не очень-то и хотели его развивать. Ну так может показаться по issues, которые висят, и по отсутствию новых коммитов.

В тот раз остановился на этом месте и мне было лень дальше пытаться запустить его :) Да, надо было просто опубликовать нормальную версию библиотеки inspection или скачать aar из их репозитория и подключить так. Но, с учетом того, что я пропал на несколько месяцев, времени для этой авантюры не нашлось...

И вот недавно тестировал еще один инструмент, о котором напишу отдельно, и решил проверить его тут. Опять же, для этого надо было просто опубликовать недостающий aar и наконец запустить, ибо Layout Inspector уже невозможно терпеть. Честно сказать, был приятно удивлен тому, как это быстро работает и не лагает.

Рекомендую самим попробовать. Держите инструкцию как подключить плагин и там же пример проекта с ним.

Опубликовано в Полуночные Зарисовки