Tee service android что это

8 приложений для Android, которые нужно удалить. Они опасны

Кто бы что ни говорил, но Google Play – это помойка. Не даром её признали самым популярным источником вредоносного софта для Android. Просто пользователи в большинстве своём доверяют официальном магазину приложений Google и скачивают оттуда любое ПО без разбору. А какой ещё у них есть выбор? Ведь их всегда учили, что скачивать APK из интернета куда опаснее. В общем, это действительно так. Но остерегаться опасных приложений в Google Play нужно всегда. По крайней мере, постфактум.

Есть как минимум 8 приложений, которые нужно удалить

Google добавила в Google Play функцию разгона загрузки приложений

Исследователи кибербезопасности из антивирусной компании McAfee обнаружили в Google Play 8 вредоносных приложений с многомиллионными загрузками. Попадая на устройства своих жертв, они скачивают получают доступ к сообщениям, а потом совершают от их имени покупки в интернете, подтверждая транзакции кодами верификации, которые приходят в виде SMS.

Вредоносные приложения для Android

Нашли вирус? Удалите его

В основном это приложения, которые потенциально высоко востребованы пользователями. Среди них есть скины для клавиатуры, фоторедакторы, приложения для создания рингтонов и др.:

• com.studio.keypaper2021
• com.pip.editor.camera
• org.my.famorites.up.keypaper
• com.super.color.hairdryer
• com.celab3.app.photo.editor
• com.hit.camera.pip
• com.daynight.keyboard.wallpaper
• com.super.star.ringtones

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

Как найти вирус на Android

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

• Скачайте приложение для чтения пакетов Package Name Viewer;
• Запустите его и дайте те привилегии, которые запросит приложение;

В красном квадрате приведен пример названия пакета

• Поочерёдно вбивайте в поиск названия пакетов, приведённые выше;
• При обнаружении приложений с такими именами, нажимайте на них и удаляйте.

Package Name Viewer удобен тем, что позволяет не просто найти нужное приложение по названию его пакета, но и при необходимости перейти в настройки для его удаления. Для этого достаточно просто нажать на иконку приложения, как вы попадёте в соответствующий раздел системы, где сможете остановить, отключить, удалить накопленные данные, отозвать привилегии или просто стереть нежелательную программу.

Как отменить подписку на Андроиде

Лучше всего приложение именно удалить. Это наиболее действенный способ защитить себя от его активности. Однако не исключено, что оно могло подписать вас на платные абонементы, поэтому для начала проверьте свою карту на предмет неизвестных списаний, а потом просмотрите список действующих подписок в Google Play:

• Запустите Google Play и нажмите на иконку своего профиля;
• В открывшемся окне выберите раздел «Платежи и подписки»;

Если подписка оформлена через Google Play, отменить её ничего не стоит

• Здесь выберите «Подписки» и проверьте, нет ли среди них неизвестных;
• Если есть, просто нажмите напротив неё на кнопку «Отменить».

В принципе, если подписка была оформлена через Google Play и оплата уже прошла, вы можете потребовать у Google вернуть уплаченные деньги. О том, как это делается, мы описывали в отдельной статье. Но поскольку разработчики таких приложений обычно тщательно продумывают способы воровства денег, как правило, они не используют встроенный в Google Play инструмент проведения платежей, чтобы их в случае чего не могли отозвать.

Источник

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

Источник

DarkNess

Личный блог DarkNess. Только технические темы.

понедельник, июня 24, 2013

Освобождаем память (ОЗУ) Android и ускоряем запуск. Или «Лишние» программы стандартной прошивки Android.

Внимание — без рута это не работает !
Это касается по большей части стандартных прошивок. Во многих «кастомных» все «лишние программы» просто вычищены изначально.
Как я уже сказал ранее, я по возможности стараюсь избегать «инвазивных» методов, типа установок «кастомных прошивок», или замены ядра. Да и вариант со «свапом на SD карточку» не только требует замены ядра, но еще и чреват ускоренным «отходом карточки в небытие», вместе со всем что на ней, что тоже «не совсем рулез» 🙂 Но если не хватает ОЗУ, то кое что можно сделать и без вышеописанных «радикальных методов». Поможет нам та же программа System Tuner (https://play.google.com/store/apps/details?id=ccc71.pmw&hl=ru) которую мы использовали в предидущий раз для переноса на SD карточку «непереносимых» программ, и длля освобождения места во внутренней памяти. В ней же есть возможность «отключить автозапуск» любой программы. Для этого заходим в пункт ‘Startups». Все программы, которые «автоматически запускаются при старте системы» отмечены галочками. Просмотрев что же там у нас «автозапускается», мы обнаружим огромное количество программ, как системных так и нами установленных, которые стоят на «автозапуск», и каждый раз запускаются, тормозя перезагрузку и занимая место в RAM, которого обычно, если у Вас ОЗУ метров 512 всегда и катастрофически не хватает. Просматриваем, и снимаем галочки «автозапуска» с тех, автозапуск которых нам не нужен или вообще бессмысленен, и сделан авторами просто чтобы программа» докладывалась» автору что «она установлена и используется». Главное не трогайте системные программы, типа «Система Android», «Графический интерфейс системы», «телефон» итд — ато последствия могут быть непредсказуемыми, вплоть до «умирания тела». Но в общем, там половину если не больше можно спокойно убрать из автозапуска, и весь «побочный эффект» будет — ускорение старта телефона и меньше занятой памяти.

А теперь о лишних «системных» програмах.
Их можно тоже убрать из «автозапуска» но это не поможет, они еще стартуют и по «событиям», и поэтому все равно запустятся. Поэтому возвращаемся в главное меню, и нажимаем пункт «System».
После чего, выбираем «лишние», по одной, и выбрав, нажимаем кнопоку «Freeze» внизу. И так для каждой. Вот перечень программ, которые вообще не влияют на работу, и некоторые нужны для слежения за юзером, некоторые для функций, которые Вы скорее всего никогда в жизни использовать не будете:
«Лишние» системные программы, кушающие ОЗУ:
Atci_Service — Отключайте спокойно, никаких побочных эффектов вообще не заметите. Она используется для тестирования Fm радио из инженерного меню. Смысла в ее «постоянном висении в памяти» — вообще никакого.
Голосовой поиск — если Вы им не пользуетесь — отключайте — это сразу несколько метров, и он имеет привычку висеть в памяти, пользуетесь Вы им или нет.
Живые обои Android — по вкусу. Вообще они и батарею дополнительно жрут и несколько метров памяти, и имеют привычку занимать ОЗУ, даже если Вы их реально не используете. Замораживаем.
Каталог живых обоев — если не нужны «живые обои», то и он тоже — замораживаем.
Настройка Google Patrner — Большинство людей в нете, сходится на том, что это просто программа-шпион, для сбора статистики, а также для установки программ на Ваш Андроид без Вашего ведома, и для Вас собсно бесполезна, если Вы не любите чтобы за Вами лишний раз следили, и не готовы платить за это удовольствие потерей места в ОЗУ и доп разрядом батареи 🙂
Отзывы о Маркете — Зачем она вооще нужна для меня загадка. Можно спокойно отключать — на реальной фукнциональности не скажется.
Поиск — Вы часто пользуетесь строкой поиска в верху экрана ? Я обычно вызываю браузер, чтобы что то поискать в гогл. И не вижу никакого смысла в том, чтобы тратилось несколкьо метров ОЗУ за сомнительное удовольствие наблюдать занимающую место на десктопе строку поиска, которой не пользуюсь 🙂 — Freeze 🙂 После этого можете убрать с экрана и гаджет «поиска» и поместить на это место что нибудь более полезное.
Службы Exchange — Нужны толкьо тем, кто забирает почту с Microsoft Exchange, используя «нативный» почтовый клиент. Если Вы пользуетесь стандартными SMTP/POP3/IMAP они Вам вообще не нужны, но место в памяти «жруть справно» — Freeze.
Фейсконтроль — Если Вы не используете авторизацию по своему фотоснимку (следует заметить достаточно ненадежную) — freeze. Потому что память она время от времени «кушает» — используете Вы ее или нет.
MobileLog — Пишет логи работы радиомодуля (GSM, bluetooth и т.д) на sd-карту, в
папку /mnt/sdcard/mtklog/mobilelog, вызывается из инженерного меню. Можно спокойно замораживать, если Вы не используете логи, записанные на SD карту. Работе LogCat ее заморозка никак не мешает.
Поставщик средств поиска. Для чего она нужна, я толком не нашел описаний. Предполагаю что связана с возможностью «поиска прямо с десктопа Андроид», который для меня лично бесполещен, и платить за то что он занимает место на экране лишними несколькими десятками метров ОЗУ. Кое кто пишет что она-же используется «для поиска установленных программ». Где, если после ее заморозки и маркет продолжает работать нормально, и списки установленных программ в настройках отображаются ? В общем я ее заморозил — побочных эффектов пока не заметил.

Условно-ненужные.
Сервисы Google Play — Реально я заметил только одну программу на которую они влияют — Google Keep. Если Вы ее не используете — можете «замораживать». В памяти они висят постоянно, не зависимо от использования или не использования. А если Вы всеже найдете программу, которой они нужны, то при ее запуске увидите ошибку и предложение «установить сервисы google play» — тогда просто идете и «размораживаете их».

Заодно я обычно «замораживаю» и часть других программ, например тот же, рекомендованный мною «Lucky Patcher» — размораживая» только если мне его нужно использовать, и потом замораживая вновь — если этого не делать он будет «атвозапускаться» и висеть в памяти (проверяет обновления). Так же можно «замораживать» и антивирус, если Вы не ставите никаких программ, и «размораживать» его когда собираетесь что то ставить.

Все «замороженные» программы Вы можете в любой момент «разморозить», нажав кнопку «Boil», которая появится в меню на том месте где была «Freeze«, после того как программа была «заморожена» — действие полностью «обратимо». Но естественно, не замораживайте ядро системы и системные приложения, на счет которых Вы не уверены насколько они влияют на работоспособность, чтобы не получить «кирпич для перепрошивки».

Суммарно так мы освободим 40-100 метров ОЗУ.

Источник