Что это Handler Service
Handler Service — это новая разновидность вредоносной программы, которая препятствует нормальной работе установленных браузеров. Замечено, что этот троян Handler Service маскируется под полезную утилиту, предназначенную для контроля системных служб и обеспечения стабильной работы операционной системы. В данной статье я расскажу, что это такое Handler Service и приведу практические рекомендации по удалению данного вируса.
Как происходит заражение Handler Service
Вредоносная программа Handler Service попадает на компьютер классическими путями. Чаще всего Хандлер Сервис устанавливается путем бандлинга (bundling), т. е. — через пакеты программ. Зачастую при установке программ от проверенных производителей инсталлятор предлагает скачать и установить дополнительное ПО «от партнеров». При выборе стандартного режима установки (для неопытных пользователей) дополнительные программы скачиваются и инсталлируются автоматически. Расчет идет на банальную невнимательность или неопытность пользователя.
Также нередки случая заражения вирусом Handler Service через установку браузерных дополнений и всевозможных баров. При посещении сомнительных сайтов пользователь может по ошибке дать согласие на инсталляцию расширений. Поэтому никогда нельзя соглашаться на установку плагинов от сомнительных производителей.
Просмотрите посты написанные мной ранее об удалении подобного софта: MPC Cleaner, yoursites123.com и goinf.ru.
Признаки заражения трояном Handler Service
Ясно, что это Handler Service представляет собой источник распространения агрессивной рекламы, которую невозможно убрать стандартными способами. Проявляется это тем, что реклама и автоматические редиректы устанавливаются на всех без исключения сайтах. Во время загрузки операционной системы автоматически запускается два процесса «handler_service.ехе и hhandler.ехе». Происходит замена всех ярлыков браузеров, за счет которых изменяется стартовая страница.
Handler Service не только значительно ухудшает комфорт интернет-сёрфинга, но и тормозит работу всего компьютера. Процессы потребляют память, ресурсы ЦП, а большое количество рекламных баннеров требует дополнительного сетевого трафика, что замедляет скорость открытия веб-страниц.
Как удалить вирус Handler Service
Для удаления Handler Service в первую очередь следует просканировать операционную систему на наличие вирусов с помощью антивирусного сканера. Dr Web Curelt! является оптимальным решением — эта утилита бесплатная.
Во-вторых, следует завершить процессы в диспетчере задач процессы «handler_service.ехе и hhandler.ехе», найти и удалить все файлы с таким названием. Для окончания лечения следует отредактировать все измененные ярлыки браузеров: в поле «объект» окна свойств должен находиться прямой путь к файлу программы. Если там находятся какие-либо дополнительные записи, например, адрес сайта, то это результат действия вируса.
990x.top
Простой компьютерный блог для души)
ShellHWDetection — что это за служба? (Shell Hardware Detection)
Приветствую. Данный материал расскажет о службе ShellHWDetection. Узнаем насколько нужна и можно ли отключить.
ShellHWDetection — что за служба?
Определение оборудования оболочки, необходима для корректного функционирования CD/DVD-дисков, USB-флешек, автоматического подключения карт памяти.
Полное название — Shell Hardware Detection.
Данная служба контролирует и предоставляет уведомления об аппаратных событиях автозапуска. То есть имеет прямое отношение к обнаружению содержимого накопителя (диска, флешки), например картинки, видео, аудио, после чего помогает понять системе какие нужно предложить действия. Например аудио — воспроизвести, картинки — открыть в редакторе или просмотрщике.
Простыми словами — эта служба нужна чтобы Windows могла определить что именно находится на флешке, диске, внешнем жестком диске. После определения — Windows сама предложит на выбор действия.
Работает под процессом svchost.exe, который запускается с таким параметром:
Без данной службы может не работать некоторый софт, например HP Scan (для принтера или МФУ).
Данный выбор действия — предположительно осуществляется при помощи ShellHWDetection.
Иногда при загрузке системы не запускаются службы ShellHWDetection и BITS. Оказывается причина может быть в утилите Punto Switcher (для орфографии).
ShellHWDetection — можно ли отключить?
Лучше не отключать, особенно если часто подключаете к ПК внешние устройства.
Однако при желании — можно попробовать отключить. Еще лучше заранее создать точку восстановления.
Также можно отключить используя реестр (Win + R > regedit) — откройте раздел:
Внутри найдите раздел ShellHWDetection, разверните — внутри будет параметр Start, для отключения задайте ему значение 4.
Заключение
Ускорить смартфон
Все нижеописанные операции с лёгкостью могут превратить ваш смартфон в кирпич! 100 раз подумайте и изучите нюансы, прежде чем что-то делать. И всё забекапить, да.
По умолчанию андроид хрен даст что заблокировать и удалить кроме какого-нить вконтактика. Поэтому я рутанул телефон. Пришлось часов 5 потратить на изучение нюансов и опыта других людей для минимизации косяков. Во время рутования ладошки немного вспотели, но всё обошлось.
Для начала я досконально посмотрел на оперативу, что до рута было мне недоступно: оказалось, что в ней сидит куча хлама, который я использую раз в год и закрываю сразу после использования. Даже если закрыть принудительно процесс в оперативе, то он всё равно скоро сам запустится. Причём это не какой-нить индийский говнософт. Ща уже забылось, но помню яндекс-карты жрали около 50 МБ оперативы. Для масштаба: после загрузки смарта доступны около 500 МБ. И я могу их понять: каждая прога хочет сидеть в оперативе, чтобы быстро запускаться и всякие свои служебные дела делать. Если прога позаботится о пользователе и будет выгружать себя из оперативы, то высок риск что пользователь сменит её на другую, которая быстро запускается, так как сидит в оперативе. А то, что именно из-за неё тормозит смарт пользователь не узнает, ведь таких прог в оперативе множество. Поэтому разработчики вынуждены жертвовать быстродействием смартфона.
На моём смарте около 280 процессов. Думаю, около 100 я на тот момент уже заблокировал. Если посмотреть на названия остальных работающих процессов, то можно увидеть, что присутствует куча ненужного (или редкоиспользуемого) многим хлама. Процессы для bluetooth, VPN, сетевых служб, заставок экрана, фона рабочего стола, шрифтов, принтеров, системных настроек. Заблокировав много чего из перечисленного у меня перестал работать инет и звонки. Пришлось что-то возвращать обратно и блокировать внимательнее. Назначение процессов можно было понять из названий, значков и при помощи гугла.
1. Некоторые приложения при запуске ругаются на отсутствие некоторых гугловских сервисов, но работать ни им, ни мне это не мешает.
3. Не работают приложения Google sheets и Google docs (требуется вагон процессов). Для меня это не большая, но заметная проблема. Поэтому когда приспичит (раз в два месяца), я их использую из браузера.
4. Я заблокировал даже те приложения, которые использую раз в неделю. Соответственно, пару раз в неделю я лезу в Titanium Backup и разблокирую их. На это уходит около 5-10 секунд, но выигрыш от свободной оперативы гораздо больше.
Выполнение задач в бэкграунде
На Stackoverflow часто встречаются вопросы по выполнению на Android фоновых задач, в т.ч. и повторяющихся с заданным промежутком времени. Как правило, первое, что используется, это Service.
Такой подход в некоторых случаях может привести к тормозам и низкой скорости ответа пользовательского интерфейса. Расскажу когда так бывает и как с этим бороться…
Почему может «тормозить» Service
Каждое Android-приложение по-умолчанию запускается в отдельном процессе. В каждом процессе запускаются потоки (Thread). По-умолчанию все компоненты приложения (Activity, Service, BroadcastReceiver) запускаются в одном «main» потоке (он же UI-thread). Если внутри сервиса запустить, например, долгий сетевой вызов или какую-то тяжелую инициализацию, мы получим тормоза всего приложения, его интерфейса и, скорее всего, предложение сделать Force close… Впрочем, работа службы в том же потоке, что и остальное приложение, имеет свои плюсы — у вас есть доступ к элементам интерфейса. Если бы служба работала в другом потоке, доступ к UI у вас бы отсутствовал.
Что делать?
Для решения данной проблемы стоит для тяжелых задач использовать отдельный поток. На самом деле его даже не обязательно создавать внутри службы…
Запускаем свой поток
Поток создать просто…
Все просто, но проблемы начинаются, когда после выполнения длинного задания нам захочется обновить UI.
В результате выполнения получим ошибку. «Чужой» поток попытался обратиться к UI! Как вылечить? Надо использовать Handler. Доработаем код…
AsyncTask — все проще
Для реализации подобных задач в Android SDK имеет встроенное средство — AsyncTask. Данный класс позволяет не думать о том, в каком потоке выполняется ваш код, все происходит автоматически. Рассмотрим пример выше переписанный на AsyncTask.
Таймер. Самый простой подход к периодическому запуску.
Java предоставляет Timer для запуска повторяющихся задач. Сделаем так, чтобы AsyncTask из предыдущего примера выполнялся раз в минуту…
Стоит заметить, что все упрощается если «долгоиграющая» задача не требует доступ к UI. В этом случае не требуются ни Handler’ы, ни AsyncTask’и.
Кстати, у таймера есть еще метод scheduleAtFixedRate(). Различия между ним и schedule() описаны в документации.
Более гибкий способ. ScheduledThreadPoolExecutor.
Класс ScheduledThreadPoolExecutor указан как рекомендуемая альтернатива использованию Timer. Данный класс позволяет организовать пул потоков и планировать выполняемые задачи относительно него. Т.е. класс для организации очереди заданий один, но тем не менее он может выполнять одновременно несколько заданий, если это позволяет имеющееся количество доступных потоков. Более подробно о преимуществах — в документации.
Для каждого заплаированного задания доступен его «дескриптор» — ScheduledFuture с помощью которого можно, например, отменить выполнения одного конкретного задания не трогая весь остальной пул.
Задание со звездочкой. Велосипед. Thread, Looper, Handler.
А еще можно собрать свой велосипед поток с очередью.
Данный поток, будучи единожды запущенным, выполняется вечно. Для общения с ним (отправки заданий) можно использовать метод getHandler() для получения хандлера и дальнейшей отправкой «событий» в него. CountdownLatch используется для синхронизации, чтобы поток, желающий получить Handler, не получил его ранее того момента, когда поток-работник запустится и Handler буде создан.
Как работает SystemUI в Android
В этой статье я разберу архитектуру и принцип работы основного приложения Android — SystemUI. Меня заинтересовала эта тема, потому что мне интересно, как устроена система, которой пользуется такое огромное количество пользователей и для которой ежедневно выкатываются тысячи приложений в Google Play или просто на просторы интернета. Помимо этого меня интересует вопрос информационной безопасности Android и создаваемых под него приложений.
В системе Android, SystemUI — это приложение, путь к исходному коду которого находится в platform_frameworks_base/packages/SystemUI/, на девайсе оно находится в system/priv-app/-SystemUI.
priv-app — это каталог, где хранятся привилегированные приложения. К слову, по пути system/app лежат предустановленные приложения, а обычные приложения, которые мы устанавливаем на свой девайс самостоятельно, хранятся в data/app.
Тут сразу возникает вопрос: почему нельзя засунуть все предустановленные и привилегированные приложения в один каталог, зачем нужно это разделение?
Дело в том, что некоторые приложения более системные, чем другие:) И это разделение необходимо для того чтобы уменьшить покрытие эксплойтами системных приложений, для получения доступа к защищенным операциям. Можно создавать приложение, которое будет иметь специальный ApplicationInfo.FLAG_SYSTEM и в системе получит больше прав, однако apk файл с таким разрешением будет помещен в раздел system.
Итак, SystemUI — это apk-файл, который по сути своей обычное приложение. Однако, если посмотреть на сложное устройство SystemUI, перестает казаться, что это всего лишь простое приложение, верно?
Данное приложение выполняет весьма важные функции:
Запуск SystemUI
Как я и говорила выше, SystemUI не похож на обычное приложение, так что его запуск не сопровождается запуском активности, как это происходит у большинства приложений. SystemUI — это глобальный пользовательский интерфейс, который запускается во время процесса загрузки системы и не может быть завершен.
Если мы залезем в SystemServer, который является одним из двух столпов в мире Android (второй — Zygote, но об этом я расскажу как-нибудь в другой раз), то мы можешь найти место, где стартует SystemUI при загрузке системы.
Тут мы видим как запускается сервис SystemUI с помощью непубличного API startServiceAsUser. Если бы вы захотели использовать это, то вам пришлось бы обратиться к рефлексии. Но если вы решите использовать reflection API в Android — подумайте несколько раз, стоит ли это того. Подумайте раз сто:)
Итак, тут создается отдельный процесс для приложения и по факту каждый раздел SystemUI является отдельным сервисом или независимым модулем.
Метод start() вызывается для запуска каждой службы, которые перечислены ниже.
Регулирование громкости
Мы регулярно пользуемся кнопками громкости на своих устройствах, но не задумываемся какие процессы должны произойти в системе для того чтобы мы могли прибавить или убавить звук. Операция кажется довольно простой на словах, но если заглянуть в VolumeUI, который находится в подпапке SystenUI/volume, в разных режимах интерфейс имеет свою вариацию.
Я уже говорила о том, что сервисы SystemUI запускаются методом start(). Если мы посмотрим на класс VolumeUI, то он тоже наследуется от SystemUI.
Тут мы видим что с помощью mEnabled мы определяем, следует ли нам показывать панель с настройкой звука. И судя по VolumeDialogComponent, VolumeUI отображает звуковую панель в виде диалога. Но все действия относительно нажатия на клавиши громкости обрабатываются в PhoneWindow.
Насколько мы видим, KEYCODE_VOLUME_UP (+) не обрабатывается и перейдет в обработку KEYCODE_VOLUME_DOWN (-). И в обоих событиях, как в onKeyDown, так и в onKeyUp вызывается метод dispatchVolumeButtonEventAsSystemService.
Итак, тут у нас вызывается метод adjustVolume, для того чтобы мы могли проверить наш direction, которому будет присвоен параметр события.
В итоге когда мы доберемся до AudioService, где будет вызван sendVolumeUpdate, где помимо вызова метода postVolumeChanged, будет установлен интерфейс HDMI.
RingtonePlayer
RingtonePlayer в Android выполняет роль проигрывателя. Он так же наследуется от SystemUI и в методе start() мы видим:
Здесь у нас устанавливается mCallback, который по сути является экземпляром IRingtonePlayer.
В итоге можно управлять RingtonePlayerService с помощью Binder для воспроизведения звуковых файлов.
PowerUI
PowerUI отвечает за управление питанием и уведомлениями. Аналогично наследуется от SystemUI и имеет метод start().
Как мы видим из приведенного выше кода, происодит подписка на изменения Settings.Global.LOW_POWER_MODE_TRIGGER_LEVEL, а после — вызов mReceiver.init().
Тут регистрируется широковещательный приемник, с помощью которого происходит отслеживание изменений.
Задачи
Recents — это основная и часто используемая функция в мобильных устройствах на базе Android.
Главные функции:
Помимо этого Recents так же наследуется от SystemUI. В RecentsActivity происходит создание и обновление последних задач, чтобы мы могли увидеть их на нашем экране.
А в с помощью RecentTaskInfo мы можем получить информацию о конкретной задаче.
Вообще, запущенные задачи можно вынести в отдельную тему. Я изучила ее со всех сторон, так как хотела размывать экран приложения перед переходом приложения в background, чтобы в RecentsTask отображалась нечитаемая версия снапшота. Однако, проблема заключается в том, что снапшот приложения берется раньше, чем вызывается onPause(). Эту проблему можно решить несколькими способами. Либо выставлять флаг, чтобы система просто скрывала содержимое экрана с помощью
О чем я говорила в предыдущей статье, посвященной как раз снапшотам.
Можно вообще сделать так, чтобы конкретная activity приложения не отображалось в задачах, проставив в манифесте
Либо можно воспользоваться хитростью с помощью
Можно задать основной активности выше приведенный флаг excludeFromRecents = true, для того чтобы ее экран отсутствовал в запущенных задачах, но во время загрузки приложения запустить отдельную задачу, которая будет показывать либо размытый скриншот с основной активности, либо любое другое изображение. Более подробно, как это можно сделать описано в официальной документации на примере Google Drive.
Экран блокировки
Keyguard уже посложнее всех вышеприведенных модулей. Он представляет из себя сервис, который запускается в SystemUI, а управляется при помощи KeyguardViewMediator.
Однако на самом деле KeyguardService самостоятельно не работает с интерфейсом экрана блокировки, он лишь передает информацию в модуль StatusBar, где уже и производятся действия относительно визуального вида экрана и отображения информации.
Панель уведомлений
То мы видим ссылку на ресурс из которого читается имя класса и создается его экземпляр.
Таким образом мы видим что тут вызывается StatusBar, который будет работать с выводом уведомлений и UI.
Я думаю никто и не сомневался в том, что Android устроен очень сложно и заключает в себе много хитростей, которые описаны в огромном количестве строчек кода. SystemUI является одной из самых важных частей этой системы и мне понравилось изучать ее. Из-за того что материала на эту тему очень мало, если вы заметите какие-либо ошибки, прошу исправить меня.
