Permission controller на Андроид что это за программа

Диспетчер разрешений — одно из лучших приложений, помогающих отслеживать разрешения приложений и управлять ими.

ФУНКЦИИ
* Перечислите опасные разрешения, которые запросило приложение.
* Предоставляйте или запрещайте приложениям разрешения для каждого приложения.
* Показать предоставленное разрешение при открытии приложения.
* Специальное разрешение быстрого доступа..

ОТЗЫВЫ
Если у вас возникли проблемы при использовании приложения, пожалуйста, дайте нам несколько комментариев
мы проверим и обновим как можно скорее.

Большое спасибо!

Последнее обновление
16 июн. 2022 г.
Инструменты

Безопасность данных

arrow_forward

Чтобы контролировать безопасность, нужно знать, как разработчики собирают ваши данные и передают их третьим лицам. Методы обеспечения безопасности и конфиденциальности могут зависеть от того, как вы используете приложение, а также от вашего региона и возраста. Информация ниже предоставлена разработчиком и в будущем может измениться.

зачем нужен app permission?

Источник: play.google.com

Permission Control на Андроид

Permission Control на Андроид бесплатно вы можете найти по ссылке ниже.

Мобильные устройства Андроид – это технически сложный аппарат, за безопасность которого отвечает специальная система от компании Google. Однако, несмотря на все ее возможности, гарантии полной сохранности данных она предложить не может. Особенно данный аспект касается мобильных приложений, устанавливаемых с сервиса Play Market или интернет-портала. Каждый пользователь, совершавший эту процедуру, сталкивался с разрешениями доступа к различным областям смартфона.

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

Данное приложение работает в автоматическом режиме, поэтому пользователю не придется на него отвлекаться. В фоновом режиме программа будет отслеживать «жизнедеятельность» установленных софтов и проверять чистоту их функционирования. При возникновении вопросов, она своевременно уведомит юзера о проблемных ситуациях. Случается это чаще всего, когда утилита пытается несанкционированно проникнуть к личным данным владельца смартфона.

Еще одной функцией приложения является отслеживание неиспользуемых утилит. Если пользователь давно не работает с той или иной программой, то Permission Control уведомит об этом и предложит ее отключить.

Особенности

К интересным особенностям Permission Control можно отнести:

• Полноценное анализирование работы всех приложений;
• Оперативная блокировка опасных проникновений;
• Автоматический режим работы;
• Экономия батареи в фоновом режиме;
• Обработка всех разрешений приложений;
• Компактный размер и стабильная работа;
• Поддержка актуальных версий Андроид.

Скачать

Android runtime permissions. Почему, зачем и как

Часто при установке приложения на Android нам приходилось видеть, что оно запрашивает какое-то немыслимое количество разрешений. Например:

Permission controller | Permissions removed for unused apps | Remove permission for unused app

Хорошо, если вы устанавливаете приложение от какого-то известного разработчика, которому можете доверять. Но весьма подозрительно, если вы устанавливаете новый музыкальный плеер, а ему для работы требуется, например, получать ваше местоположение. Или, тем более, фонарик, требующий доступ к смс и звонкам.

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

К шестой версии Android ситуация поменялась. Теперь разрешения нужно запрашивать в процессе работы. О том, как этой новой возможностью пользоваться и ее некоторых подводных камнях будет рассказано далее.

Общая информация

Разрешения делятся на два типа (есть и другие, но они нас не интересуют):

• обычные (normal);
• опасные (dangerous).

Можно увидеть, что доступ к интернету не считается опасным. Все, кто использует рекламу в своих программах, могут вздохнуть с облегчением: отключить её, просто отобрав разрешение, не получится (все еще можно просто отключить интернет, но факт остается фактом).

Взаимодействие с пользователем

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

Первая из них — это важность данного разрешения для вашего приложения, от этого зависит, когда нужно производить запрос. Если функция критична и без нее программа не будет иметь смысла, то смело просите разрешения прямо при запуске приложения. Например, если вы разрабатываете приложение для обмена sms, то без соответствующих разрешений с ним ничего не получится сделать, оно теряет всякий смысл. А если пользователь отказал, то не пропускаем его дальше, но даем возможность снова вызвать диалог запроса и даем инструкции что нужно делать.

• важные разрешения запрашиваем при запуске, вторичные — при первом использовании соответствующей функции;
• если понять, зачем нужно разрешение тяжело, предоставляем объяснение.

Код

Логичным вопросом будет: а что же произойдет, если запустить ваше неадаптированное под runtime разрешения приложение на Android Marshmallow? Ответ зависит от того осмелились ли вы изменить targetSdk на 23 версию (compileSdk и buildTools нас в данном случае не интересуют). Если да, то у меня не лучшие новости для вас: очень вероятно, что вы получите SecurityException.

Это не обязательно будет так, возможно где-то вы получите null вместо запрошенной информации, но вероятность далеко не нулевая. Если же вы используете targetSdk версии 22 и ниже, то все разрешения будут, как и прежде выданы приложению при установке, включая опасные. Это не отменяет того, что пользователь может отозвать любое из них после установки. При этом он получит предупреждение, что приложение не адаптировано под runtime разрешения и может работать некорректно. Насколько некорректно оно будет работать, полностью зависит от вас, то есть если вы проверяли возвращаемые значения на null или были готовы к нулю вместо вменяемого значения, то ничего страшного не произойдет: приложение просто не будет полноценно функционировать (что выглядит все же лучше чем падение из-за NullPointerException).

Но даже если у вас все хорошо с проверками и нет возможности заниматься внедрением новых возможностей, стоит перепроверить, все ли правильно работает, потому что иногда можно получить null не там, где его ожидаешь. Так, например, при использовании Environment.getExternalStorageDirectory() без наличия разрешения из группы Storage, мы получим File, но list() вернет нам заветный null. В документации такой исход описан, но для ситуации, когда File не является директорией. Так что проверка в любом случае лишней не будет.

Есть возможность добавить разрешение только для Android M и выше. Для это в манифесте нужно использовать новый тег (ранее называвшийся ). Его синтаксис аналогичен обычному . Это может быть полезно, если вы хотите добавить в существующее приложение возможность, которая требует дополнительного разрешения. Как вы помните, если новая версия программы требует дополнительных прав, пользователь должен вручную подтвердить ее обновление. Этого можно избежать, если новая функция не очень важна, отключив ее для более ранних версий системы, используя описанный ранее тег. В таком случае это разрешение будет вовсе отсутствовать.

В процессе отладки часто приходится включать/отключать разрешения. Заходить для этого каждый раз в настройки приложения не очень удобно. К счастью, это можно сделать с помощью adb:

adb shell pm grant adb shell pm revoke

И еще несколько полезных команд, смысл которых ясен из названия:

adb shell pm reset-permissions adb shell pm list permission-groups adb shell pm list permissions

Перейдем к непосредственной реализации (предварительно не забудем обновить 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.

public void requestMultiplePermissions() < ActivityCompat.requestPermissions(this, new String[] < Manifest.permission.READ_EXTERNAL_STORAGE, Manifest.permission.READ_SMS >, PERMISSION_REQUEST_CODE); >

Как видите, напрямую запрашивать разрешения можно только из Activity или Fragment. Если разрешение требуется сервису, то придется запускать Activity, из которой уже можно будет сделать запрос. Лучше всего перед этим будет показать уведомление, содержащее информацию о недостающем разрешении с кнопкой для запуска этой самой Activity.

Размер массива grantResults проверяется для того, чтобы удостовериться, что запрос разрешения не был прерван (в этом случае permissions и grantResults не будут содержать элементов). Такую ситуацию следует рассматривать не как запрет разрешения, а как отмену запроса на него.

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’ы (подробнее).

Таким образом, вы сможете избавиться от некоторых опасных разрешений и упростите работу с приложением.

Заключение

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

• Java
• Разработка мобильных приложений
• Разработка под Android

Источник: habr.com