Permission Control что это за программа на Андроиде? (com.mediatek.security)
При включении смартфона в верхней строке статуса может быть нарисован замочек. При нажатии — выскакивает ошибка, в тексте которой упоминается Permission Control (идентификатор com.mediatek.security).
Постараемся немного разобраться — что это за программа?
Удалось выяснить
По мнению одного юзера, Permission Control — контроль разрешений для приложений. Данный компонент способен вызывать глюки, лаги, нестабильную работу телефона, увеличенный расход батареи. Для отключения необходимо перейти в настройки > безопасность, найти пункт App Permission > отключить.
Опасность отключенного приложения состоит в том, что все программы получат полные разрешения. Рекомендуется перед отключением просканировать смарт на наличие вирусов/троянов. Для проверки можно использовать антивирусы Касперского, Доктора Веба.
Удаление компонента — только на свой страх и риск.
Однако, один пользователь сообщил что после отключения приложения все равно будут запрашивать доступ на разрешения.
Приложение в списке установленных:
Также может быть ошибка:
permission control произошла ошибка
Можно попробовать данное приложение заморозить при помощи Titanium Backup. Удалять не стоит — могут быть проблемы. Приложение в Титаниуме:
При использовании штатного отключения может выскочить данное сообщение:
Apps will directly get permissions without your confirmation
Сообщение предупреждает — если выключить, тогда приложения будут напрямую получать разрешения без вашего подтверждения.
Также после отключения могут быть проблемы с Play Market (скорее всего связаны с безопасностью).
Еще один человек подтвердил — если вас достает приложение Permission Control, выключите в настройках > безопасность > разрешения для приложений.
Дополнительно удалось выяснить — за запуск сторонних приложений отвечает не только Phone Cleaner (необходим для энергосбережения), но и плагин Permission Control.
Если Permission Control заморозить Титаниумом тогда автостарт в настройках станет неактивным.
По непроверенной информации Permission Control это тоже самое что и Privacy Protect.
Чтобы приложение пермиссион вас больше не доставало, можно поставить галочку Больше не уведомлять.
Другой пользователь написал свой способ отключения
Другой чел написал, что он решил проблему через Гравицапу — там есть блокировка уведомлений.
Странный косяк — когда приложение пытается использовать GPS, то пермиссион контрол отображает GPS как Bluetooth.
Permission Control: что это за программа на Андроид
Операционная система Android представляет собой сложную структуру со специальной системой разрешений, отвечающей за ее безопасность. Разработчики структурировали все таким образом, что доступ к различным опциям предоставляется отдельным приложениям, в то время как функции управления доступны пользователю. Список разрешений определяется экспертами Google и фиксируется в протоколах. На данный момент разработана специальная программа по управлению разрешениями на Android. Некоторые люди находят его бесполезным и энергозатратным, поэтому ищут возможность его отключения.
Что это
Permission Control — это специальная служба Android, которая проверяет подлинность заявленных разрешений, установленных на устройстве. Основной задачей данного программного обеспечения является анализ доступной информации с целью предотвращения доступа к приложениям третьих лиц, если на момент установки отсутствовали данные.
Контроль разрешений регулярно отображается в списке всплывающих уведомлений. Если владелец гаджета обнаруживает такую информацию, это означает, что программа активна и выполняет свои функции. Таким образом, программа реализует задачу блокирования другого приложения от получения незадекларированных прав.
Как отключить
При необходимости разрешительный контроль может быть временно отключен. Пользователь может сделать это самостоятельно, используя стандартное меню настроек Android.
Владельцу гаджета необходимо перейти в раздел «Настройки». Следующим шагом является вкладка «Безопасность», где необходимо перейти в раздел «Права доступа» или «Права доступа» (в зависимости от версии, формулировка может отличаться!). Последнее действие — «Отключить».
Хотя владелец гаджета имеет право приостановить службу разрешений Android, эксперты до сих пор не рекомендуют делать это. Контроль разрешений является важной частью операционной системы. Он сопротивляется несанкционированным действиям приложений. Он способен предотвратить использование памяти устройства или совершение каких-либо вызовов, если в оригинальном приложении не предусмотрено выполнение этих функций.
Работа системы — это хорошо скоординированный механизм, каждый шаг которого подчиняется строгим правилам. Permission Control является стражем за несанкционированными действиями и позволяет приложениям выполнять сторонние операции, которые не являются их собственными или не были указаны во время установки. В некоторых случаях, когда компонент прав доступа отрицательно влияет на функциональность гаджета — увеличивается заряд батареи, ошибки, зависание, его можно отключить.
Сейчас персональная информация очень часто попадает в руки общественности. Истории звонков, ваше месторасположение, данные о серфинге в интернете и многое другое. Но теперь, начиная с Android 3.1, все можно изменить. Современное приложение «App Ops» готово спасти все личные данные от хищения сторонними лицами. Мы расскажем что это такое App Permissions в телефоне или планшете на Андроид и почему не нужно путать его с уведомлениями «App permission management is closed».
Что это такое?
App Permissions Manager (или App ops) – это менеджер уровня разрешений, работающий c ОС Android 4.3 и выше. Приложение создает свою картотеку всего софта на смартфоне. По отдельности может блокировать доступ приложений к разной запрашиваемой информации, к примеру: данным GPS, истории браузера, хранящимся текстовым сообщениям и т.д. Очень удобный интерфейс позволяет в один клик запрещать передачу данных сторонним ресурсам, что очень эффективно против разных шпионских программ.
Приложение App Permissions Manager для Андроид
Преимущества менеджера
Основной упор делается на возможность отключения разных данных по отдельности. Если вам нужно установить ваше месторасположение, то эту конкретную опцию легко будет разрешить. Хотя остальные данные по-прежнему останутся вне досягаемости для установленных приложений.
Также к огромным плюсам можно отнести работу в реальном времени. Зайдя в «App Permissions» и отключая разные характеристики, они тут же вступают в силу. Не нужно производить перезагрузку девайса, все уже будет применено на деле. А процесс запрета происходит посредством перетаскивания ползунка с одной стороны в другую. Все действительно очень просто и не требует особых навыков от пользователя. Для полноценной работы программы, на Андроиде требуется активный root-доступ.
Интерфейс
Весь интерфейс состоит из списка приложений, где возможно установить ограничение на доступ к личной информации. Вверху имеется навигационное меню: Device, Personal, Location, Messaging. Никаких дополнительных настраиваемых меню больше нет.
Замечание
Внимание! Не стоит путать работу этого приложения со всплывающими уведомлениями в версии Андроид 6.0 и выше — «App Permission Management is running» (настройки APM активированы) и «App Permission Management is closed» (настройки APM отключены). Убрать (отключить) уведомления можно в «Настройках» — «Безопасность» (листаем вниз) — перемещаем ползунок против «Разрешения приложений». Если уведомление появляется при запуске определенного приложения, тогда войдите в его сведения в Диспетчере приложений и там в пункте «Разрешения» активируйте или снимите все ползунки.
Уведомление App Permission Management is running
Как инсталлировать в смартфон
Распространяется «App Permissions Manager» официально через Google Play. Он совершенно бесплатный, поэтому нет смысла скачивать его с других источников в интернете. Сам процесс установки ничем не отличается от стандартного приложения, всего в пару кликов все уже будет инсталлировано к вам в телефон. Аналогов также предостаточно в Маркете, но качество их не всегда лучшее.
Часто при установке приложения на Android нам приходилось видеть, что оно запрашивает какое-то немыслимое количество разрешений. Например:
Хорошо, если вы устанавливаете приложение от какого-то известного разработчика, которому можете доверять. Но весьма подозрительно, если вы устанавливаете новый музыкальный плеер, а ему для работы требуется, например, получать ваше местоположение. Или, тем более, фонарик, требующий доступ к смс и звонкам.
Некоторые разработчики, чтобы уменьшить недоверие, добавляют в описание приложения на Google Play информацию о том, зачем нужно то или иное разрешение.
К шестой версии Android ситуация поменялась. Теперь разрешения нужно запрашивать в процессе работы. О том, как этой новой возможностью пользоваться и ее некоторых подводных камнях будет рассказано далее.
Общая информация
Подобно тому, как это происходит в iOS, при запросе появится системный диалог с запросом разрешения.
Отличие в том, что после нажатия на кнопку “Deny” разрешение не будет полностью запрещено для приложения, как это происходит у Apple. Его можно будет запросить повторно, но в этом случае появится опция “Never ask again”, после выбора которой “Deny” работает как “Don’t allow” в iOS.
Разрешения делятся на два типа (есть и другие, но они нас не интересуют):
Можно увидеть, что доступ к интернету не считается опасным. Все, кто использует рекламу в своих программах, могут вздохнуть с облегчением: отключить её, просто отобрав разрешение, не получится (все еще можно просто отключить интернет, но факт остается фактом).
Для того чтобы отозвать разрешение, которое было выдано ранее (или предоставить его, если вы выбрали “Never ask again”) нужно перейти в настройки приложения (Settings->Apps->*AppName*) в раздел Permissions и кликнуть по соответствующим переключателям. В этом меню также можно посмотреть все разрешения этой программы, выбрав пункт “All permissions” из контекстного меню. Еще есть возможность просматривать, каким приложениям выдано конкретное разрешение (и соответственно предоставить или отобрать его). Для этого в настройках в разделе Apps нужно кликнуть по меню с иконкой шестеренки и в открывшемся разделе выбрать App permissions. Далее, выбрав нужное разрешение, можно увидеть все приложения, которым оно нужно.
Взаимодействие с пользователем
Посмотрим, как нужно производить взаимодействие с пользователем. Начнем непосредственно с запроса разрешения. С обычными разрешениями все понятно, это дело установщика приложений, нас это не интересует, а то, как мы будем запрашивать опасные разрешения, зависит от двух вещей.
Первая из них — это важность данного разрешения для вашего приложения, от этого зависит, когда нужно производить запрос. Если функция критична и без нее программа не будет иметь смысла, то смело просите разрешения прямо при запуске приложения. Например, если вы разрабатываете приложение для обмена sms, то без соответствующих разрешений с ним ничего не получится сделать, оно теряет всякий смысл. А если пользователь отказал, то не пропускаем его дальше, но даем возможность снова вызвать диалог запроса и даем инструкции что нужно делать.
Если же разрешения требует некая вторичная функция, то не нужно просить о нем сразу. Делайте это только тогда, когда пользователь захочет воспользоваться этой возможностью.
Второй момент заключается в том, насколько ясно будет человеку, для чего нужно это разрешение. Зачем приложению для смс доступ к календарю? Наверное, для какой-то классной функции, которая облегчит перенос дат из сообщений в календарь и тому подобное. Но знаете об этом только вы, поэтому сначала нужно объяснить причину запроса и показать какие возможности даст доступ к этому разрешению. Это относится и к первичным и к вторичным разрешениям.
Логичным вопросом будет: а что же произойдет, если запустить ваше неадаптированное под runtime разрешения приложение на Android Marshmallow? Ответ зависит от того осмелились ли вы изменить targetSdk на 23 версию (compileSdk и buildTools нас в данном случае не интересуют). Если да, то у меня не лучшие новости для вас: очень вероятно, что вы получите SecurityException. Это не обязательно будет так, возможно где-то вы получите null вместо запрошенной информации, но вероятность далеко не нулевая. Если же вы используете targetSdk версии 22 и ниже, то все разрешения будут, как и прежде выданы приложению при установке, включая опасные. Это не отменяет того, что пользователь может отозвать любое из них после установки. При этом он получит предупреждение, что приложение не адаптировано под runtime разрешения и может работать некорректно. Насколько некорректно оно будет работать, полностью зависит от вас, то есть если вы проверяли возвращаемые значения на null или были готовы к нулю вместо вменяемого значения, то ничего страшного не произойдет: приложение просто не будет полноценно функционировать (что выглядит все же лучше чем падение из-за NullPointerException).
Но даже если у вас все хорошо с проверками и нет возможности заниматься внедрением новых возможностей, стоит перепроверить, все ли правильно работает, потому что иногда можно получить null не там, где его ожидаешь. Так, например, при использовании Environment.getExternalStorageDirectory() без наличия разрешения из группы Storage, мы получим File, но list() вернет нам заветный null. В документации такой исход описан, но для ситуации, когда File не является директорией. Так что проверка в любом случае лишней не будет.
В процессе отладки часто приходится включать/отключать разрешения. Заходить для этого каждый раз в настройки приложения не очень удобно. К счастью, это можно сделать с помощью adb:
И еще несколько полезных команд, смысл которых ясен из названия:
Перейдем к непосредственной реализации (предварительно не забудем обновить compileSdkVersion и targetSdkVersion до версии 23).
До момента, когда Marshmallow станет минимальной версией андроида для ваших приложений, еще далеко, поэтому нужно позаботиться об обратной совместимости. Конечно, можно делать проверки версии sdk, но зачем, если все реализовано за нас в support library v4 (ActivityCompat) и v13 (FragmentCompat). Если все же вам понадобятся оригинальные методы, то найти их не составит труда.
Во всех примерах используется ActivityCompat, так как они были сделаны для activity. Для fragment нужно использовать FragmentCompat. Если вы по какой-то причине не используете activity и fragment из support библиотек, то вам нужно реализовать интерфейс ActivityCompat.OnRequestPermissionsResultCallback или FragmentCompat.OnRequestPermissionsResultCallback соответственно.
Каждый раз, когда мы хотим использовать метод, требующий опасного разрешения, необходимо проверить есть ли оно у нас. Для этого используем метод ContextCompat.checkSelfPermission(Context context, String permission), который возвращает нам одно из int значений: PackageManager.PERMISSION_GRANTED в случае если разрешение есть или PackageManager.PERMISSION_DENIED если его нет. Именем разрешения является одна из констант класса Manifest.permission.
Далее, если разрешение есть, выполняем нужное нам действие, а если нет, то его нужно запросить. Одновременно можно запросить несколько разрешений (пользователю по очереди будет показан запрос на каждое из них), если это необходимо.
Стоит упомянуть, что если разрешения находятся в одной permission group, то запросить достаточно одно из них, так как все остальные элементы этой группы станут также доступны. Но так делать не нужно. Потому что в будущем состав групп может поменяться, поэтому при запросе разрешений не нужно делать предположений относительно того находятся ли они в одной группе или нет.
UPD будто в подтверждение предыдущего параграфа, начиная с Android 8.0 разрешения из одной permission group не выдаются сразу — каждое разрешение нужно запрашивать отдельно, но все разрешения из одной группы будут выданы автоматически, без участия пользователя при первом же их запросе.
UPD2 это же поведение было замечено на Android 7.0 — если часть разрешений из группы выдана (не могу сказать с уверенностью, имеет ли значение какие именно), то остальные будут выдаваться по запросу сразу же без показа диалога. Это может вызвать проблемы, если ваше приложение объясняет пользователю зачем ей нужно то или иное разрешение еще до его запроса. В реальной жизни такое редко когда может возникнуть (только при использовании adb комманд), но стоит учитывать это при отладке приложения.
Для запроса используется метод ActivityCompat.requestPermissions(Activity activity, String[] permissions, int requestCode). Массив permissions соответственно содержит названия разрешений, которые вы хотите запросить. Отсюда видно, что одновременно можно запрашивать несколько разрешений. requestCode — значение, по которому в дальнейшем можно будет определить, на какой запрос разрешения вам пришел ответ подобно тому как мы получаем результат от activity, используя startActivityForResult. Кстати, если посмотреть на код requestPermission, то обнаружится, что это всего лишь особая версия startActivityForResult.
Как видите, напрямую запрашивать разрешения можно только из Activity или Fragment. Если разрешение требуется сервису, то придется запускать Activity, из которой уже можно будет сделать запрос. Лучше всего перед этим будет показать уведомление, содержащее информацию о недостающем разрешении с кнопкой для запуска этой самой Activity.
Результат запроса разрешения следует обрабатывать в onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults). Параметры requestCode и permissions содержат данные, которые вы передавали при запросе разрешений. Основные данные здесь несет массив grantResults, в котором находится информация о том, получены разрешения или нет. Каждому i-му элементу permissions соответствует i-ый элемент из grantResults. Их возможные значения аналогичны результату checkSelfPermission.
Размер массива grantResults проверяется для того, чтобы удостовериться, что запрос разрешения не был прерван (в этом случае permissions и grantResults не будут содержать элементов). Такую ситуацию следует рассматривать не как запрет разрешения, а как отмену запроса на него.
Если вы ранее уже запрашивали разрешение, но пользователь отказался предоставить его, необходимо объяснить ему причину запроса. Этого не нужно делать, если причина, по которой вы запрашиваете разрешение, абсолютно ясна. Если же есть вероятность, что вопрос “А зачем приложению это нужно?” возникнет, то объяснить это крайне желательно. Для того чтобы узнать, нужно ли показывать объяснение есть метод shouldShowRequestPermissionRationale(@NonNull Activity activity, @NonNull String permission), который возвращает boolean. Само же объяснение можно реализовать, например, с помощью Snackbar с кнопкой действия, по клику на которой происходит запрос разрешения, или диалогового окна, если разрешение критично необходимо.
Never ask again
Одной из проблем может стать опция “Never ask again”, которая появляется при повторном запросе разрешения, после того как пользователь уже отказал ранее. Как видно из названия, при её выборе диалог запроса не будет больше появляться. shouldShowRequestPermissionRationale будет выдавать false, а в onRequestPermissionsResult будет получен результат PackageManager.PERMISSION_DENIED. И получим разрешение мы, только если включить его непосредственно через настройки приложения в разделе Permissions.
Что с этим можно сделать? В первую очередь, конечно, сообщить пользователю, что для выполнения действия нет нужных прав. Далее возможным действием может быть предложение перейти в настройки и предоставить это разрешение вручную. Не лучший вариант, но лучше чем ничего. Реализовать это можно вновь с использованием Snackbar с кнопкой действия.
Перейти непосредственно на страницу с разрешениями не получится, поэтому лучшее, что вы можете сделать, это открыть настройки своего приложения. После этого можно, например, показать Toast с информацией, что нужно сделать.
В примере используются startActivityForResult и onActivityResult чтобы определить, что пользователь вернулся из activity настроек обратно в приложение и попробовать выполнить действие, которое нельзя было сделать без нужного разрешения. В методе showExtDirFilesCount нужно снова проверить есть ли разрешение для уверенности, что пользователь его все-таки выдал.
Здесь может возникнуть ситуация, которая не особенно мешает, если вы используете Snackbar для показа rationale, но портит UX, если вы решили использовать диалоги (причины этого решения мы не затрагиваем). А именно двойное появление rationale, до запроса разрешения и после него. Как это может произойти? У нас всего два метода, по которым мы можем судить о состоянии разрешения. Проблема в том, что до запроса разрешения ситуация, когда мы еще никогда не запрашивали это разрешение, и ситуация, когда пользователь ранее выбрал “Never ask again”, абсолютно одинаковы по значениям. А именно checkSeflPermission возвращает нам PERMISSION_DENIED, a shouldShowRequestPermissionRationale — false. Значит, показывать диалог для открытия настроек мы будем в onRequestPermissionsResult, где значение shouldShowRequestPermissionRationale точно будет разным для этих двух ситуаций. Все отлично? Не совсем. В этом callback’e никак нельзя определить была ли показана rationale или нет. Поэтому если вы показываете причину запроса, а далее пользователь просит больше его не спрашивать об этом разрешении, после нажатия на кнопку DENY он получит очередной rationale диалог, приглашающий его в настройки программы. Хорошие программы так себя не ведут.
Что делать в такой ситуации? В сети есть пара не очень красивых решений: одно из них — сохранять в SharedPreferences информацию о том имеется ли разрешение или нет, другое — хранить флаг о том была показана rationale или нет внутри класса. Первое решение не хорошо тем, что пока приложение не работает, пользователь может изменить настройки разрешений и информация в preferences будет неактуальной. Второй же способ не особо красивый.
Хорошим вариантом (на мой взгляд) будет завести два requestCode для каждого запроса, один для использования в rationale другой в остальных случаях. Этот способ так же не идеален и не особенно красив, но помогает придерживаться существующих методов, не внося ничего нового.
Intent
Есть еще одна важная рекомендация при использовании runtime разрешений. Не используйте их. Точнее, используйте, но только тогда, когда функционал, который вы собираетесь реализовать с их помощью, не сделал уже кто-то до вас.
В качестве самого показательного примера чаще всего вспоминают камеру. Используйте стандартное приложение камеры (или другие приложения, умеющие это делать), если вам нужно всего лишь сделать фотографию без какой-то особой логики. В этом вам помогут Intent’ы (подробнее).
Таким образом, вы сможете избавиться от некоторых опасных разрешений и упростите работу с приложением.
При включении смартфона в верхней строке статуса может быть нарисован замочек. При нажатии — выскакивает ошибка, в тексте которой упоминается Permission Control (идентификатор com.mediatek.security).
