990x.top
Простой компьютерный блог для души)
com.google.android.ext.services — что это?
com.google.android.ext.services — системная служба ранжирования уведомлений, которая сортирует уведомления по уровню важности, используя такие данные как дата появления, источник (приложения типа мессенджеры более приоритетные), контакт.
Также найдена информация, что данный пакет является системным приложением Android Services Library, функция сортировки уведомлений называется Android Notification Ranking.
На форуме 4PDA говорится что com.google.android.ext.services можно заморозить (например используя Titanium Backup). Однако на других сайтах сказано — удалять нельзя, это логично, учитывая что программа системная и является частью операционной системы Андроид. И конечно после отключения могут быть проблемы с поступлением уведомлений.
Один пользователь нашел способ отключения ненужных приложений без использования root-прав:
- Открываем настройки телефона.
- Выбираем Все приложения.
- Активируем вкладку Работающие.
- Крутим в самый низ, находим Android Services Library (при отсутствии — нужно включить Показывать системные процессы) > Настройки > Ссылки для запуска.
- Появится список программ, выбираем ненужное. Тапаем Остановиться, после — Отключить.
Данным способом некоторые пользователи отключили программы Гугл.
Надеюсь данная информация оказалась полезной. Удачи и добра, до новых встреч друзья!
Источник
Полный список
— разбираемся, зачем нужна библиотека Support Library
— на примере фрагментов используем библиотеку v4
Support Library – библиотека, которая на старых версиях Android делает доступными возможности новых версий. Например, фрагменты появились только в третьей версии (API Level 11). Если вы хотите использовать их в своем приложении, это приложение не будет работать на более старых версиях Android, т.к. эти старые версии никогда не слышали про класс android.app.Fragment. Какие тут есть выходы?
1) Добавить в код проверку версии системы и в зависимости от результата выполнять тот или иной код. Т.е. если версия 11 и выше, используем фрагменты, иначе Activity. Вполне выполнимо, но не совсем просто. Можно ошибиться и запутаться. Т.е. при запуске приложения на старых версиях приходится либо отказываться от новшеств и пользоваться тем, что есть, либо изобретать велосипед и реализовывать новшества самому.
2) Можно забить на старые версии и позиционировать свое приложение только для новых версий. Тогда теряется ощутимая часть потенциальных пользователей вашей программы. На момент написания этого материала на версии Android ниже третьей сидит 69,7% пользователей. Ощутимая такая потеря получится — больше, чем две трети! Конечно, со временем все перейдут на третью и последующие версии, и смогут использовать ваше приложение. Но к тому времени выйдут новые версии Android с новыми возможностями, вы их реализуете в своем приложении и, тем самым, снова отсеете часть пользователей. В общем, вырисовывается постоянная дискриминация пользователей по версии.
3) Использовать библиотеку Support Library. Она содержит классы — аналоги новшеств последних версий, которые будут работать на старых версиях.
На данный момент есть две библиотеки v4 и v13. Цифра здесь указывает минимальный API Level на котором можно использовать эту библиотеку. Т.е. приложение, использующее v4, может быть запущено на API Level >= 4 и ему будут доступны новшества, которые входят в эту библиотеку (например, фрагменты).
Библиотеки эти периодически обновляются, в них добавляются новые классы, реализующие новые возможности. Так что, если вы не нашли в них сейчас то, что вам нужно, вполне возможно, что это появится в будущем. Самый яркий пример – ActionBar. Его, к сожалению, в v4 пока нет. И я, честно говоря, не знаю, появится ли. Умельцы пишут свои аналоги, т.е. реализуют первый вариант из рассмотренных нами выше и предоставляют нам возможность использовать его, как третий вариант. Ведь мы вовсе не обязаны ограничиваться стандартной Support Library от гугла. Можно использовать и другие библиотеки от других разработчиков. Самая популярная реализация ActionBar – это ActionBarSherlock.
Разобрались с тем, что такое Support Library и зачем она нужна. Теперь посмотрим, как ее использовать. Работать будем с v4.
Если у вас библиотека загружена, а версия ADT одна из последних, то Eclipse сам автоматически добавит в проект эту библиотеку. И вы сразу после создания нового проекта сможете ее использовать.
Если не все так радужно, то надо скачать и добавить самим. Несложный и недолгий процесс. На официальном сайте есть инструкция. И я здесь просто напишу перевод этой инструкции со своими дополнениями. Но не спешите все это проделывать! Возможно, вам это не понадобится.
Чтобы загрузить библиотеку:
Откройте SDK Manager, найдите там Android Support Library и установите ее
Библиотека v4 загрузится в папку: /extras/android/support/v4/android-support-v4.jar
Чтобы добавить библиотеку в ваш проект:
В проекте создайте папку libs. Он должна быть в корне, на том же уровне, что и res, bin и прочие. Поместите в папку libs загруженную библиотеку android-support-v4.jar. Далее, правой кнопкой на этой библиотеке в папке libs, и в контекстном меню Build Path > Add to Build Path.
Обновите манифест, указав в нем, что минимальная требуемая версия для вашего приложения – API Level 4.
При создании нового проекта проверьте — если папка libs с библиотекой в проекте есть, то выше приведенная инструкция вам не нужна.
Из рассмотренных нами в прошлых уроках классов, библиотека содержит Fragment, FragmentManager, FragmentTransaction, ListFragment, DialogFragment.
Полный список объектов можно посмотреть, открыв API на сайте. Вот основной пакет — android.support.v4.app. Слева видны остальные.
Напишем простейший пример использования фрагмента в приложении для API Level 10.
Project name: P1141_SupportLibrary
Build Target: Android 2.3.3 (не 4.1 . )
Application name: SupportLibrary
Package name: ru.startandroid.develop.p1141supportlibrary
Create Activity: MainActivity
Сначала layout fragment.xml:
Пустой красный LinearLayout.
Далее создаем класс — MyFragment. Если мы сделаем это по старинке, наследуя android.app.Fragment, то в созданном классе получим ошибку The import android.app.Fragment cannot be resolved. И это логично, т.к. в Android 2.3.3 (API Level 10) нет такого класса.
И, собственно, именно тут и пригодится нам библиотека v4. Будем наследовать ее класс android.support.v4.app.Fragment при создании фрагмента
Только FrameLayout, который будет контейнером для фрагмента.
Далее есть один нюанс. Чтобы в старой версии Android использовать фрагменты из Support Library, нам необходимо использовать не стандартное Activity, а также из библиотеки – android.support.v4.app.FragmentActivity.
В коде видим еще одно отличие. FragmentActivity использует метод getSupportFragmentManager (а не getFragmentManager) для получения FragmentManager. В остальном, работа с фрагментами не будет отличаться от прошлых уроков. Различие будет только в секции import. Если раньше было, например так:
import android.app.Fragment;
import android.app.FragmentManager;
import android.app.FragmentTransaction;
(это работает только на новых версиях)
то с использованием v4 будет так:
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentManager;
import android.support.v4.app.FragmentTransaction;
(это будет работать и на старых и на новых версиях)
Цель проста — работоспособность вашего приложения на старых версиях, которые ничего не знают про фрагменты. Старые версии будут использовать для работы с фрагментами классы библиотеки v4. Но, разумеется, этот код без проблем сработает и на последних версиях Android.
Все сохраняем, запускаем приложение и видим работающий фрагмент на Android версии 2.3.3
Ради интереса запустим его же на Android 4.1
Итого, благодаря библиотеке, один и тот же код работает на старых и новых версиях и использует возможности новых версий.
На следующем уроке:
— учитываем ориентацию и размер экрана в работе приложения
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме
Источник
Наша 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 это пока работает. Надеяться или не надеяться — решать читателю.
Источник
