Dmservice android что это
Погружение в службы Android
Перевод статьи «Deep Dive into Android Services» от Nazmul Idris. Я оставил оригинальное название автора, хотя это скорее не «погружение», а «знакомство». Думаю, текст будет полезен начинающим разработчикам. Статья отлично дополняет офф. документацию по службам на Android. В статье разбираются особенности взаимодействия с запущенными и привязанными службами. Плюс статьи в том, что учитываются изменения в работе со службами в Android O. В переводе есть незначительные, по сравнению с оригиналом, изменения, добавленные для пущей ясности.
Введение
Большинство современных android-приложений выполняют часть задач в фоне. Это означает, что задачи выполняются в фоновом потоке, а не в потоке пользовательского интерфейса (UI-поток).
В этом случае служба (service) это подходящий компонент Android, который свяжет жизненный цикл потока со своим жизненным циклом, и таким образом не потеряет его.
Служба — это компонент android-приложения без видимого интерфейса, который запускается в основном потоке приложения. Служба должна быть объявлена в манифесте. Если вам необходимо чтобы служба работала в фоновом потоке, вы должны самостоятельно реализовать это.
Термины фон и передний план перегружены, и могут применяться к:
В этой статье, по умолчанию будем считать, что термины фон и передний план относятся к жизненному циклу. Но, когда будет идти речь о потоках, мы будем явно говорить фоновый поток или поток переднего плана.
Потоки, службы и жизненный цикл компонентов Android
Ниже приведены пояснения к основным временным моментам этой диаграммы Гантта. Детали этих моментов (и пояснения к ним) приведены в остальной части статьи.
Метод службы onCreate() вызывается в момент ее создания (путем запуска или привязки к ней).
Метод службы onDestroy() вызывается системой только когда вы сообщили службе, что пришло время завершать работу. Служба не знает, что будет происходить в коде ваших Thread или Executor — это зона вашей ответственности. Таким образом, задача программиста сообщить службе о начале и о завершении работы.
Службы делятся на два вида: запущенные и привязанные. Кроме того, служба может быть запущенной и допускать привязку. Мы рассмотрим каждый из случаев:
Изменения в Android O
Запущенные службы
Чтобы служба стала запущенной, вы должны вызвать startService() с явным намерением. Если вы не сделаете этого, тогда служба не перейдет в запущенное состояние. И, таким образом, она не сможет перейти на передний план, и stopSelf() на самом деле ничего не выполнит.
Итак, если вы не перевели службу в запущенное состояние, вы не сможете прикрепить ее к уведомлению. Это довольно важные вещи, о которых вы должны помнить, когда вам нужно перевести службу в запущенное состояние.
Intent
Передний план и механизм постоянного уведомления
Запущенная служба может работать на переднем плане. Опять же, термин передний план не относится к тому работает ли служба в фоновом потоке или в главном потоке. Но это означает, что система присвоит службе наивысший приоритет, и поэтому служба не является кандидатом для удаления системой в случае нехватки памяти. Помещать службу на передний план стоит только в том случае, когда это действительно необходимо для создания современного и отзывчивого приложения.
Примеры использования службами переднего плана:
Когда запущенная служба помещается на передний план, она должна вывести на экран уведомление, явно сообщая пользователю, что служба работает. Это важно, потому что запущенная служба на переднем плане отделена от жизненного цикла UI-компонентов (за исключением, разумеется, самого постоянного уведомления). И нет другого способа сообщить пользователю о том, что на его телефоне что-то работает (и потенциально потребляет много ресурсов) кроме как вывести в UI постоянное уведомление.
Ниже пример старта запущенной службы на переднем плане:
Вот код создания постоянного уведомления в версиях
Кроме того, вот еще одна статья, в которой больше деталей о создании уведомлений в MediaStyle (поскольку для фонового проигрывания аудио-файлов нужны как уведомления, так и привязанные и запущенные службы)
Остановка запущенных служб
Это объясняет почему метод onStartCommand() должен уметь обрабатывать Intent ы. Используя этот механизм мы можем «сказать» службе, чтобы она остановила работу. Ниже код, который иллюстрирует эти возможности:
Чтобы остановить службу вы можете выполнить одно из следующих действий:
Вот несколько примеров остановки службы из Activity :
И вот код в вашей службе, который будет обрабатывать эти запросы (при условии, что ваша запущенная служба находится на переднем плане):
Привязанные службы
Отличия между привязанной и запущенной службами:
В любом случае, когда службе (привязанной или запущенной) необходимо отправлять сообщения привязанному клиенту, ей следует использовать что-то вроде LocalBroadcastManager (в том случае, если клиент и служба работают в одном процессе). Привязанные службы обычно не подключаются к привязанному клиентскому компоненту напрямую.
bindService() и onCreate()
Ниже приведен пример реализации ServiceConnection :
Привязка службы
Отвязка от службы и вызов onDestroy()
Вот как выглядит вызов unbindService() в клиентском компоненте:
Вот пример как может выглядеть onUnbind() в коде привязанной службы:
Привязанные и запущенные службы одновременно
Бывают ситуации, когда вам могут пригодиться службы, которые являются запущенными и вместе с тем могут допускать привязку. В предыдущих разделах, мы показали особенности работы каждого из видов служб. И уже из этих особенностей можно понять, что создание привязанных и запущенных служб одновременно необходимо для реализации особого поведения в момент начала работы со службой и при завершении работы с ней.
Если служба не запущена, то клиент, который хочет привязаться к ней, вызовет onCreate() у службы. Если служба уже запущена, этот метод не вызывается. С другой стороны, если клиент отвязывается от службы и при этом служба не запущенная, то вызывается onDestroy() и служба уничтожается.
Переход в запущенное состояние
Поскольку клиент, привязываясь к службе, не переведет ее в запущенное состояние, то для привязанных и запущенных служб одновременно, требуется чтобы служба переходила в запущенное состояние самостоятельно. Вот, как можно это сделать с учетом Android O:
В коде под спойлером:
Но, перед фактическим исполнением работы, служба сначала переводит себя в запущенное состояние.
Завершение работы службы и отвязывание
Если служба не в запущенном состоянии и клиентский компонент отвязывается от службы, то служба уничтожается и вызывается onDestroy()
Вот диаграмма, в которой суммируются состояния службы и переходы между ними для запущенной и привязанной службы одновременно:
Примеры
Реализацию большинства из того, о чем говорилось в статье, можно глянуть на GitHub.
Это небольшая утилита для Android O и N, которая держит телефон в активном состоянии, если он на зарядке.
Ускорить смартфон
Все нижеописанные операции с лёгкостью могут превратить ваш смартфон в кирпич! 100 раз подумайте и изучите нюансы, прежде чем что-то делать. И всё забекапить, да.
По умолчанию андроид хрен даст что заблокировать и удалить кроме какого-нить вконтактика. Поэтому я рутанул телефон. Пришлось часов 5 потратить на изучение нюансов и опыта других людей для минимизации косяков. Во время рутования ладошки немного вспотели, но всё обошлось.
Для начала я досконально посмотрел на оперативу, что до рута было мне недоступно: оказалось, что в ней сидит куча хлама, который я использую раз в год и закрываю сразу после использования. Даже если закрыть принудительно процесс в оперативе, то он всё равно скоро сам запустится. Причём это не какой-нить индийский говнософт. Ща уже забылось, но помню яндекс-карты жрали около 50 МБ оперативы. Для масштаба: после загрузки смарта доступны около 500 МБ. И я могу их понять: каждая прога хочет сидеть в оперативе, чтобы быстро запускаться и всякие свои служебные дела делать. Если прога позаботится о пользователе и будет выгружать себя из оперативы, то высок риск что пользователь сменит её на другую, которая быстро запускается, так как сидит в оперативе. А то, что именно из-за неё тормозит смарт пользователь не узнает, ведь таких прог в оперативе множество. Поэтому разработчики вынуждены жертвовать быстродействием смартфона.
На моём смарте около 280 процессов. Думаю, около 100 я на тот момент уже заблокировал. Если посмотреть на названия остальных работающих процессов, то можно увидеть, что присутствует куча ненужного (или редкоиспользуемого) многим хлама. Процессы для bluetooth, VPN, сетевых служб, заставок экрана, фона рабочего стола, шрифтов, принтеров, системных настроек. Заблокировав много чего из перечисленного у меня перестал работать инет и звонки. Пришлось что-то возвращать обратно и блокировать внимательнее. Назначение процессов можно было понять из названий, значков и при помощи гугла.
1. Некоторые приложения при запуске ругаются на отсутствие некоторых гугловских сервисов, но работать ни им, ни мне это не мешает.
3. Не работают приложения Google sheets и Google docs (требуется вагон процессов). Для меня это не большая, но заметная проблема. Поэтому когда приспичит (раз в два месяца), я их использую из браузера.
4. Я заблокировал даже те приложения, которые использую раз в неделю. Соответственно, пару раз в неделю я лезу в Titanium Backup и разблокирую их. На это уходит около 5-10 секунд, но выигрыш от свободной оперативы гораздо больше.
Наша 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 это пока работает. Надеяться или не надеяться — решать читателю.
Device Health Services: что это за программа, как удалить
На современных мобильных устройствах установлено много дополнительных приложений. Некоторые программы нужны для стабильной работы операционной системы. Другие – считаются весьма спорными и замедляют работу гаджета. Кроме того, они становятся причиной быстрого разряда батареи. Многие пользователи после покупки нового устройства обнаруживают приложение Device Health Service. Оно может оказаться полезным, поскольку ведет статистику расхода энергии.
Зачем нужна утилита
Создателем Device Health Service является компания Google. Программа устанавливается по умолчанию на смартфоны Xiaomi, Samsung, Pixel и Nexus. Она позволяет пользователям отслеживать состояние батареи и другую системную статистику.
Перед полным разрядом элемента питания всплывает уведомление. Оно напоминает о необходимости подключения зарядного устройства. Если поблизости нет розетки – рекомендуется изменить параметры электропитания, чтобы продлить время автономной работы. Можно уменьшить яркость или громкость звука.
Еще один способ экономии заряда – отключение всех беспроводных интерфейсов.
Device Health Service позволяет:
Программа не считается обязательной для использования. Она лишь помогает проверять состояние батареи. Владелец устройства способен отслеживать энергопотребление. Эта возможность поможет выявить игры или программы, расходующие слишком много заряда.
С начала утилита устанавливалась только на гаджеты Google. Владельцы любых устройств линейки Pixel могли решать проблемы с энергопотреблением. Утилита гораздо удобнее встроенных инструментов в операционную систему Android. Она позволяет просматривать намного подробную статистику о трате заряда батареи. Через время приложение стало работать с устройствами компании Nexus, выход которых прекратился в 2016 г. Последняя модель называлась Google Pixel 4.
Нужно ли удалять приложение Device Health Services
Решение об удалении утилиты должен принимать только владелец устройства, руководствуясь собственными предпочтениями. Некоторые пользователи заявляют о пользе программы, поскольку она помогает следить за потреблением энергии. Еще встречается мнение, что приложение занимает слишком много оперативной памяти после запуска. Это мешает стабильной работе других программ и игр. Все возможности утилиты доступны только жителям США. Пользователям из других стран мира получают определенные ограничения. Снять запреты можно только патчами.
Важно! Сегодня утилита отсутствует в каталоге Google Play. Поэтому перед удалением рекомендуется сделать резервную копию. Если вы снова захотите пользоваться программой – то сможете провести восстановление. Несмотря, что Device Health Service встречается в других источниках, устанавливать программу оттуда нежелательно. Причина – вероятность заражения устройства вирусами.
Если вы хотите продлить время автономной работы своего гаджета – купите Power Bank (переносной аккумулятор) от надежной компании. Это более действенный совет, чем установка различных утилит.
Чтобы увеличить количество оперативной и постоянной памяти, многие специалисты советуют удалять ненужные приложения. Перечислим список программ, которые не нужны многим пользователям:
Точный список приложений для удаления зависит от производителя вашего устройства. К примеру, на смартфонах Samsung можно найти приложение Link, позволяющее хранить документы в облаке. Сегодня оно не поддерживается. Многие пользователи почти никогда не запускают WatchON (для просмотра телевизионных передач), ChatON (для обмена сообщениями) и AudioTuning (для уменьшения громкости звука). Все перечисленные программы можно удалить, чтобы они не занимали свободное место.
На китайских смартфонах Xiaomi тоже есть несколько ненужных утилит. Они предустанавливаются производителем. Среди них можно выделить Mi Remote Controller для задействования встроенного инфракрасного порта. Приложение позволяет управлять бытовой техникой – телевизорами и кондиционерами. Еще есть программа MiCommunity, созданная для общения владельцев устройств Xiaomi.
Как запретить приложению доступ к интернету
Последний шаг – отключение передачи данных. Снова откройте «Специальный доступ». Нажмите кнопку «Передача данных» – «Сетевые подключения». Пролистайте страницу вниз до появления надписи «Системные приложения». Найдите название утилиты и нажмите по нему.
Перед вами появятся несколько переключателей зеленого цвета. Нажмите по ним, чтобы они стали красными. Затем нажмите по кнопке меню (с тремя точками) и отключите Device Health Service. После перечисленных действий утилита перестанет расходовать системные ресурсы.
Device Health Services: как удалить с телефона
Для удаления приложения не понадобится получать права Root или устанавливать дополнительные загрузчики. Понадобится только компьютер на Windows, кабель USB для подключения и сам смартфон.
После успешного сопряжения устройства выполните несколько шагов:
Совет! Device Health Service встроена в систему только на устройства Google. На смартфонах других производителей утилиту можно удалить обычным способом.
Выводы
Device Health Service – программа для отслеживания заряда аккумулятора. Она позволяет просматривать статистику траты электрической энергии. Если вы не пользуетесь этим приложением, то просто удалите его. Это поможет освободить занимаемую память и продлить время автономной работы.
⛔️Как удалить вирусы и трояны с Андроид
Смартфон сеошнику нужен не только для звонков, так как необходимо работать с мобильными приложениями, без которых работа усложняется. Лично я пользуюсь десятком приложений, среди которых Web Money, Яндекс Деньги, TOTP для Епей и ещё куча всякой всячины. Они позволяют делать платежи вне дома, проверять почту и отслеживать активность на сайте. Большая беда, если на смартфоне завелись вирусы, ведь так могут уплыть данные акков, пароли, да и девайс начинает тупить и брыкаться.
Сегодня я расскажу, как удалить вирусы, трояны со смартфона под управлением Андроид 5. Времени на очистку уйдёт полчаса, после чего за состояние платёжного баланса можно будет не переживать, а девайс перестанет показывать чудеса тупости при серфинге в интернете.
Рождение проблемы
Проблема родилась сразу после Нового Года, когда я с сыном проверял возможности нового смартфона и качал на него разный хлам отовсюду. Первый признак болезни проявился в отказе обновляться по OTA, так как были изменены вирусами системные файлы. Болезнь девайса прогрессировала – при подключении к интернету стали загружаться сами по себе левые приложения, типа AliExpress, процессор от натуги стал перегреваться, а телефон зависать.
В результате на исходе первого месяца жизни пользоваться интернетом без мата стало невозможно, запуск приложений стал мукой и телефону светил полёт в стену, несмотря на гарантию.
Поиск вирусов
Естественно, сидеть сложа руки я не стал и начал искать нечисть на телефоне. Антивирус 360 Total для смартфона разочаровал – при проверке он нашёл 6 опасных файлов, но не показал место их установки и смог только предложить отключить приложения. Удалить он ничего не может из-за отсутствия рут прав. В списке опасных приложений оказались:
В приложениях я нашёл только первые два, остальные удачно маскировались. Нести смарт по гарантии не имело смысла, платить за перепрошивку нового девайса также желания не было. Что же делать, спрашивали глаза у мозга, последний напрягался.
Рабочее решение началось с установки Malwarebytes-anti-malware, дальше пошло по накатанной.
Инструкция по удалению
Для того чтобы полностью удалить все вирусы и трояны на Андроид понадобилось три программы:
Антивирусный сканер Malwarebytes нашёл все вирусы, Kingo позволил получить root-права для удаления, а проводник трояны удалил.
Malwarebytes
Для начала установите Malwarebytes и просканируйте смартфон. Он найдёт всю нечисть, укажет её месторасположение в телефоне и даст краткую характеристику вирусам. Сканер совместим с обычным антивирусом, поэтому перед его установкой ничего удалять не надо. У меня он нашёл в system/priv-app:
Это из того что он не смог удалить в силу отсутствия рут-прав и морального устоя, 4 папки с вредоносным содержимым он сжёг на костре, точно не помню их названия – пепел всё скрыл. Перепишите «координаты» опасных файлов, которые сканер нашёл, но не смог удалить.
Итак, после сканирования вы нашли вирусы, часть из них удалили и знаете точное месторасположение остальных вредоносных файлов. Теперь надо получить рут-права и установить проводник для удаления файлов.
Kingo Root
На моём Андроид 5 удачно стал лишь Kingo Root, поэтому его и рекомендую. Даже хвалённый Bajdo Root не стал. Всё программы, необходимые для удаления вирусов, вы найдёте внизу. Они проверены лично мной, все рабочее и не поломает Андроид.
Перед установкой Kingo рекомендую соблюсти два правила – нормально зарядить телефон и подключиться к сети, так как потребуется загрузка обновлений и установка Super User. Запускаете приложение, нажимаете «получить root» и синеете в ожидании, пока софт устанавливается и обновляется. Есть более сложный способ установки рут-прав с помощью Kingo через компьютер, но не стоит усложнять себе жизнь, когда работает и так.
ES проводник
Получили права? Теперь устанавливайте ES_file_explorer – проводник, способный работать с рут-правами. В проводнике идите в меню (левый верх), ищите вкладку Root-проводник и включайте его. Соглашайтесь с глупыми вопросами от приложения и переходите в пункт меню «Локальное хранилище – устройство».
Остаётся найти вредоносные файлы и удалить их. Выделяем и удаляем.
После удаления вирусов перезагрузите телефон и ещё раз просканируйте его сканером. Если удалили не всё, повторите процедуру для полного выздоровления.
Болезнь требует жертв, так повелось.
Итак, закрепим пройденный материал:
Программу Kingo Root удаляйте сразу после уничтожения вирусов, Super User и ES проводник можете оставить. Если соберётесь в мастерскую на гарантийный ремонт и понадобиться удалить root-права и их следы, то зайдите в меню Super User и воспользуйтесь строкой «удаление root». Если Super User удалили, и у вас остались права рут, которые надо убрать, то ставьте его заново и удаляете права через меню. Иначе до файла SU в system/bin не добраться.
И да, если вы думаете, что у вас на Андроид вирусов нет, но в 90% случаев вы ошибаетесь.
Скачать в одном rar-файле Malwarebytes, ES проводник и Kingo Root можно прямо с блога Zegeberg.