0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Работа с Runtime Permissions в Android 6. Получаем разрешения программно

Содержание

[:ru]Android runtime permissions пример реализации[:en]Android runtime permissions example implementation[:]

[:ru]В этом уроке мы рассмотрим, что такое запросы разрешений во время исполнения приложения и как с ними работать. Я покажу, как инициировать запрос разрешения, как обрабатывать ответы пользователя, а также что делать, если пользователь отказал в разрешении и установил флаг «больше не спрашивать» в диалоге запроса разрешения.

Кто не в теме, немного теории:

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

Теперь все изменилось.

Начиная с Android API 23 разрешения поделили на обычные (normal) и опасные (dangerous).

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

К опасным относятся разрешения на доступ к календарю, камере, контактам, местоположению, микрофону, звонкам, смс, датчикам, а также разрешение на чтение и запись данных во внешнюю память устройства.

Полный список обычных и опасных разрешений можно посмотреть по ссылке.

Во вторых, в связи с этим изменилось поведение приложений при установке, и здесь возможны варианты.

Например, рассмотрим случай, когда устройство работает под управлением Android версии 5.1 или ниже, или целевая версия SDK в файле сборки приложения имеет значение 22 или ниже.

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

Если же устройство работает под управлением Android 6.0 или выше, или целевая версия SDK установлена на 23 или выше, то приложение может быть установлено без запросов разрешений. Но при этом ему будут предоставлены только обычные, безопасные разрешения.

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

Теперь давайте рассмотрим пример работы с разрешениями на практике.

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

Исходный код этого проекта вы можете посмотреть ниже:

В макете экрана одна кнопка.

Также нужен идентификатор для корневого view, это понадобится для работы снекбара.

Поскольку снекбар является компонентом библиотеки материального дизайна, добавьте ее в зависимости файла сборки модуля проекта.

Также нам понадобится разрешение на запись в память, пропишем его в манифесте.

Теперь рассмотрим код класса MainActivity.

Константа PERMISSION_REQUEST_CODE хранит произвольное значение, по которому в дальнейшем можно определить, на какой запрос разрешения вам пришел ответ.

Аналогично мы получали результат от activity, используя startActivityForResult, вспоминаем уроки по этой теме на нашем канале StartAndroid.

В методе onCreate создадим кнопку и присвоим ей слушатель нажатия.

В методе onClick проверяем логический результат метода hasPermissions, и вызываем метод создания папки, makeFolder. В этом методе мы просто создаем новый файл с именем fandroid и выводим несколько тостов с сообщениями, в зависимости от того, удалось или не удалось создать файл, или он уже создан.

Если же результат в методе onClick равен false, то вызываем метод requestPermissionWithRationale, который будет в свою очередь вызывать метод запроса разрешения. Мы перейдем к нему позже.

Ниже метод hasPermissions, который с помощью метода checkCallingOrSelfPermission в цикле проверяет предоставленные приложению разрешения и сравнивает их с тем, которое нам необходимо.

При отсутствии разрешения метод будет возвращать false, а при наличии разрешения — true.

В методе requestPerms создаем массив permissions , который содержит ссылки на константы класса Manifest с кодами разрешений. Поскольку используется массив, то одновременно можно запрашивать несколько разрешений.

После проверки версии устройства Запрос разрешения выполняет метод requestPermissions, которому мы передаем массив нужных нам разрешений и константу PERMISSION_REQUEST_CODE

После вызова этого метода пользователю отображается диалоговое окно с запросом разрешения.

Ответ пользователя приходит в метод onRequestPermissionsResult. Параметры requestCode и permissions содержат данные, которые вы передавали при запросе разрешений. Основные данные здесь несет массив grantResults, в котором находится информация о том, получены разрешения или нет. Каждому i-му элементу permissions соответствует i-ый элемент из grantResults.

Здесь мы обрабатываем ответ — проверяем, если разрешение предоставлено пользователем, о чем будет свидетельствовать ответ PERMISSION_GRANTED, то вызываем метод makeFolder, а если нет, то проверяем версию устройства,

и если она равна Андроид 6.0 или выше — проверяем, отказывался ли ранее пользователь предоставлять это разрешение. В таком случае метод с длинным названием shouldShowRequestPermissionRationale вернет нам true.

Одной из проблем может стать опция “Don’t ask again”, которая появляется при повторном запросе разрешения. При её выборе диалог запроса не будет больше появляться.

Метод shouldShowRequestPermissionRationale в таком случае будет возвращать false, а в onRequestPermissionsResult будет получен результат PERMISSION_DENIED — отказ в получении разрешения.

И останется единственный способ — попросить пользователя включить разрешение непосредственно через настройки приложения в разделе Permissions.

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

настройки открывает метод openApplicationSettings(), где мы создаем и отправляем соответствующий интент. В примере используются startActivityForResult и onActivityResult чтобы определить, что пользователь вернулся из activity настроек обратно в приложение и попробовать выполнить действие, которое нельзя было сделать без нужного разрешения.

Если вы ранее уже запрашивали разрешение, но пользователь отказался предоставить его, необходимо объяснить ему причину запроса.

это мы обыграем в методе requestPermissionWithRationale() — Запрос разрешения с обоснованием

Здесь также проверяем ответ метода shouldShowRequestPermissionRationale и если он true, создаем снекбар с сообщением для пользователя и кнопкой, по нажатию на которую будем вызывать метод получения разрешения.

Здесь же будет вызываться метод получения разрешения в случае первого запроса.

Теперь установим приложение на устройство и проверим его работу на эмуляторе с Андроид 6.0 (процесс тестирования смотрите в видео выше).

При нажатии кнопки появляется запрос разрешения.

Если пользователь отказал, то приложение продолжает работу, но папка не создается.

При повторном нажатии кнопки всплывает снекбар с объяснением необходимости предоставления запроса и кнопкой, при нажатии которой вновь отображается запрос.

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

После установки разрешения и возврата в приложение папка успешно создается.

На этом все. Вопросы задавайте в комментариях к уроку.[:en]In this lesson we will look at what the permission requests during the execution of the application and how to work with them. I’ll show you how to initiate a request for permission, how to handle the user’s answers and what to do if the user refused permission and planted the flag of «don’t ask» in the dialog asking permission.

In my life, a little theory:

As you remember, to Android 6.0, all the requested permissions is displayed to the user when the application is installed. And if the user does not provide the application to at least one solution from the list, the application could not be installed.

Now everything has changed.

Starting with Android 23 API permissions were divided into normal (normal) and hazardous (dangerous).

Regular permissions are those that are not a direct threat to user privacy. These include permissions to access Internet and network connections, access to wireless modules, management alerts, sound, etc.

Threat to include permissions to access calendar, camera, contacts, location, microphone, calls, SMS, sensors, as well as permission to read and write data to the external memory device.

Full list of normal and dangerous permissions, you can view the link.

Secondly, in connection with this changed the behavior of applications when you install, there may be options.

For example, consider the case when the device is running Android version 5.1 or lower, or target SDK version in the Assembly file of the application has a value of 22 or below.

When you install this app all the usual permissions specified in the manifest will be provided without prompting.
If the manifest is a dangerous permission to grant you will be prompted to the user. And if the user refuses, the application will not be installed.

If the device is running Android 6.0 or higher, or target SDK version set to 23 or higher, the application can be installed without your permission requests. But it received only conventional, safe solutions.

Dangerous permissions may be requested at the time of the application, when the user tries to use a feature that requires this permission. The user may refuse permission and the app will quietly continue to work with limited functions.

Now let’s look at an example of working with permissions in practice.

This application with one button which creates a folder in the storage device for which the app needs permission to write to external memory.

The source code of this project you can watch below:

Программирование на C, C# и Java

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

ОСТОРОЖНО МОШЕННИКИ! В последнее время в социальных сетях участились случаи предложения помощи в написании программ от лиц, прикрывающихся сайтом vscode.ru. Мы никогда не пишем первыми и не размещаем никакие материалы в посторонних группах ВК. Для связи с нами используйте исключительно эти контакты: vscoderu@yandex.ru, https://vk.com/vscode

Читать еще:  Установка ssd диска в системный блок

Запрос App Permissions в Android у пользователя

Начиная с Android 6 Marshmallow стало необходимо во время работы приложения запрашивать у пользователя разрешение на доступ к функциям устройства, связанным с персональными данными (например, к контактам или микрофону). На примере доступа к камере разберем данный вопрос.

Проверка наличия и запрос разрешений (App Permissions) в Android

В общем случае необходимые разрешения (App Permissions) для приложения указываются в файле AndroidManifest.xml. Для камеры это будет так:

До Android 6 этого было бы достаточно. Но теперь используя так называемые опасные разрешения (Dangerous permissions) перед каждым моментом использования функциональности разрешения необходимо проверять его наличие.

При этом для получения безопасных разрешений (не связанных с персональными данными пользователя, например, доступ в Интернет) достаточно uses-permission в Манифесте.

Если опасное разрешение отсутствует, то его нужно запросить:

Где MY_PERMISSIONS_REQUEST_CAMERA – пользовательская константа с кодом запроса. Этот код в дальнейшем используется для отслеживания ответа пользователя на запрос разрешения.

В результате запроса пользователь увидит примерно следующее окно на своем устройстве:

Ответ пользователя на запрос нужно обработать. Для этого переопределим метод Активности onRequestPermissionsResult.

Ответ на запрос отслеживается как раз по константе MY_PERMISSIONS_REQUEST_CAMERA.

Объясняем пользователю необходимость запроса доступа к функциям устройства

Если пользователь во время первого запроса разрешений на доступ к функции смартфона/планшета ответил отрицательно, Google рекомендует при последующем запросе показать окно с объяснениями – для чего и зачем вашему приложению понадобился доступ, например, к камере.

При этом для проверки необходимости показа объяснений есть специальный метод shouldShowRequestPermissionRationale. Логика в коде будет следующая:

Разрешения Android 6.0 в защите и нападении

Содержание статьи

Каждый день в мобильных устройствах выявляют уязвимости, которые могут быть проэксплуатированы злоумышленниками. Они могут отправить СМС на платный номер, могут собрать большую базу данных контактов и продать ее, а могут и скомпрометировать конкретного человека. Удачная эксплуатация уязвимости обычно предполагает соблюдение целого ряда условий. Но ведь можно пойти и другим путем! Дать пользователю вполне нужное приложение (игрушку с птичками), у которого в манифесте будет записан список интересной нам информации на устройстве. В данной статье мы рассмотрим способы получения и сохранения важной информации с Android-устройства.

Архитектура ОС Android построена таким образом, что позволяет обмениваться разного рода информацией между приложениями. Приложению, работающему с картами, нужно местоположение, диктофону — доступ к микрофону. Таким образом, с виду все ясно и прозрачно.

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

Задолго до всем известного разоблачения я понимал, что игрушка со злыми птичками на твоем устройстве — это стукач, так как оно, помимо всего прочего, хочет читать идентификатор устройства и данные о вызовах. Простой вопрос «Тебе эти данные зачем?» обнажает истинные намерения ее создателей.

Пользователь при установке приложения ставится в положение «или разрешай все, что оно хочет, или останешься без программы». Только единицы пойдут в магазине искать приложение со сходной функциональностью, но с меньшими запросами (аналогов может вовсе не быть), поэтому у пользователей быстро входит в привычку жать «да-да-да» на все вопросы. Согласись, легко привыкать, когда за долгие годы офлайн-жизни у пользователей вырабатывался рефлекс автоматически подписывать многостраничные договоры, по принципу «ну, все же подписывают, наверное, тут ничего плохого, да и выход всего один — либо я подписываю тут, либо не получаю того, за чем пришел».

Если мы отберем все разрешения у приложения, ОС во избежание падения программы может просто отдать ему пустые значения. Можно обмануть приложение, подсунув ему заведомо ложные данные (местоположение Северного полюса) или просто нули. Например, приложение может спросить список контактов на устройстве, и разработчик предполагает в своей архитектуре, что он может быть пустым (совсем новое устройство). Тут даже и заподозрить нечего — и данные спасены, и приложение не сломалось.

На такие ухищрения приходилось идти вплоть до версии Android 6.0 Marshmallow. В ней появился новый механизм работы с разрешениями.

Он позволяет давать и забирать разрешения во время работы самого приложения. Для обратной совместимости старых аппликух (то есть у которых значение targetSdkVersion меньше 23) работает старый механизм запроса разрешений при установке. Обновленные приложения должны запрашивать разрешения в процессе работы. В настройках приложения мы можем посмотреть, к чему у приложения есть доступ, и при желании отозвать этот самый акцесс.

Рассмотрим работу данного механизма на устройстве с версией Android 6.0.

Давай установим птичек, но перед первым запуском отберем у них все права. При запросе прав при установке из гуглплея мы видим, что targetSdkVersion у приложения меньше 23. Экран настроек говорит нам о несколько завышенных интересах создателей приложения.

Как насчет того, чтобы немного их укоротить?

Информационный портал по безопасности

Информационный портал по безопасности » Программирование » Веб-разработка » Android 6.0: Doze Mode, App Standby, Runtime Permissions. Всё, что необходимо знать каждому разработчику

Android 6.0: Doze Mode, App Standby, Runtime Permissions. Всё, что необходимо знать каждому разработчику

Автор: admin от 3-11-2015, 10:43, посмотрело: 459

Всем привет!
В этой статье мы рассмотрим три самых важных изменения в новом Android, которые не могут быть проигнорированы ни одним разработчиком, который поставил у себя в проекте targetSdk = 23 и выше.
Doze Mode — режим «отключки», в который переходят все устройства на Marshmallow после некоторого времени обездвижения без зарядки.
App Standby — автоматическое лишение приложений доступа к ресурсам устройства, всех которые давно не открывал пользователь.
Runtime Permissions — новая модель запроса разрешений. Теперь мы, как разработчики, каждый раз обращаясь, например, к микрофону устройства, должны проверять, есть ли у нашего приложения разрешение на доступ к нему.

В Google в новом релизе Android сделали очень важный шаг в сторону оптимизации работы батареи. Все мы знаем, как пользователи любят повонять в комментариях высказываниями: «Дурацкие Google Play Services» жрут 25% батареи моего ******* S III, гопники, верните мне мой драгоценный айфон, нет сил, терпеть издевательства от Гугл». Только вот эти пользователи не ставили себе никогда Battery Historian и не в курсе, что жрут батарею бесплатные игры от сомнительных авторов и такие же сделанные на коленке живые обои, например. Но пользователь этого не знает, и как бороться с кучей левых приложений, беcпощадно съедающих батарею, он не в курсе.

Ну теперь пользователям об этом заботиться и не придется. С приходом двух новых режимов Doze Mode и App Standby операционная система перекрывает кислород всем чрезмерно жрущим заряд приложениям. Как? Читаем далее:

Doze Mode

Когда устройство на Android Marshmallow лежит без движения и без зарядки, спустя час оно переходит в Doze Mode. Режим отключки, когда почти все приложения перестают жрать батарею.

Это происходит не сразу, а по шагам:

ACTIVE — Устройство используется или на зарядке
INACTIVE — Устройство недавно вышло из активного режима (пользователь выключил экран, выдернул зарядку и т.п.)
. 30 минут
IDLE_PENDING — Устройство готовится перейти в режим ожидания
. 30 минут
IDLE — Устройство в режиме бездействия
IDLE_MAINTENANCE — Открыто короткое окно, чтобы приложения выполнили свою работу

Мы можем продебажить наши приложения, переключаясь последовательно между этими шагами с помощью:

В момент, когда устройство переходит в состояние IDLE:

  • Доступ приложению к сети отключен, пока приложение не получит high-priority GCM-push.
  • Система игнорирует Wake lock’и. Приложения могут сколько угодно пытаться запросить пробуждение процессора — они их не получат.
  • Alarm’ы запланированные в AlarmManager не будут вызываться, кроме тех, которые будут обновлены с помощью setAndAllowWhileIdle().
  • Система не производит поиска сетей Wi-Fi.
  • NetworkPolicyManagerService: пропускает только приложения из белого списка.
  • JobSchedulerService: все текущие задачи отменяются. Новые откладываются до пробуждения.
  • SyncManager: все текущие отменяются, новые откладываются до пробуждения.
  • PowerManagerService: только задачи приложений из белого списка вызовутся.

Соответственно, если наше приложение чат, то мы можем отправить с сервера push с полем priority = high.
А если у нас приложение будильник, то мы должны обязательно вызвать для Alarm setAndAllowWhileIdle() или setExactAndAllowWhileIdle().

Во многих других случаях мы вообще не должны об этом переживать, после того, как пользователь возьмет устройство в руки, все заснувшие alarm’ы и SyncAdapter’ы проснутся и сделают свою работу. (Да-да я знаю, что после выхода из doze mode все начинает синкаться и даже Nexus 9 минуты две тормозит)

App Standby

Но не только при попадании устройство в Doze Mode наши приложения будут лишены возможности разряжать батарею. Второй режим под название App Standby отправляет в такую же изоляцию приложения, которые не подходят под условия:

  • Пользователь явно запустил приложение.
  • Приложение имеет процесс, работающий в данный момент на переднем плане (Activity или foreground service, или используется другой activity или foreground service’ом).
  • Приложение создало уведомление, которое висит в списке уведомлений.
  • Пользователь принудительно добавил приложение в список исключений оптимизации в настройках системы

Исключения

Возможно сейчас разработчики коммерческих voip нервно начали продумывать, как запретить обновляться своим пользователям на пугающий своей жесткостью Android Marshmallow. Но не волнуйтесь, есть специальный Whitelist, в который пользователь руками может добавить исключения. Приложениям из Whitelist не страшны ни Doze Mode ни App Standby.

Чтобы проверить, попало ли наше приложение в Whitelist вызываем метод isIgnoringBatteryOptimizations().

Пользователь может сам руками добавить/удалить из списка в настройках Settings > Battery > Battery Optimization
Но мы можем его сами попросить с помощью интента ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS или запросив пермишен REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, который покажет диалог на автоматическое добавление в вайтлист с разрешения пользователя.

Runtime Permissions

Да-да, каждый раз, когда наше приложение обращается, например, с запросом на местоположение пользователя, мы должны проверить, есть ли у приложения разрешение от пользователя на это действие. Если есть — обращаемся к нужным нам системным ресурсам, если нет — запрашиваем. Так же пользователь может навсегда приложению запретить доступ, тогда единственный наш шанс — это попросить его самого зайти в настройки и снять запрет, показав ему объясняющее сообщение, зачем нам нужен доступ.

Стоит отметить, что Permissions в Android делятся на два типа:

  • Нормальные разрешения, вроде доступа к сети и bluetooth.
  • Опасные разрешения. В этот список входят разрешения на: календарь, камеру, контакты, местоположение, микрофон, телефон, сенсоры, смс и внешнее хранилище

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

    И так последовательность наших шагов:

    • Описать только PROTECTION_NORMAL запросы в manifest
    • Пользователь их все подтвердит при установке
    • Когда приложению нужен доступ к одному или нескольким разрешениям из группы опасных, проверить, нет ли разрешения
    • Если разрешения нет — запросить
    • Если разрешения не будет — объяснить, на что это повлияет
    • Если разрешение получено — продолжить работу

    Чтобы проверить доступность разрешения дергаем ContextCompat.checkSelfPermission (Context context, String permission).
    Чтобы запросить разрешения, показав системный диалог, вызывываем ActivityCompat.requestPermissions();
    Результат этого запроса придет в асинхронный колбэк в активити onRequestPermissionsResult(), в нем мы узнаем решение пользователя по каждому из запрошенных разрешений.

    Читать еще:  Синхронизация папок с помощью Total Commander

    Запрашивать лишь те разрешения, которые действительно нужны. До сих пор в Google Play находятся разработчики, которые запрашивают все подряд
    Если есть возможность, вместо запроса воспользоваться внешним Intent. Например, для фото или видео часто нет смысла встраивать камеру в приложение, гораздо проще воспользоваться внешним приложением
    Запрашивать разрешение, только перед тем, когда оно понадобится. Запрашивать при старте приложения все разрешения нелогично (из тех, которые нам нужны), их смысл как раз в том, что мы запрашиваем их в контексте их использования.Например, пользователю становится понятно зачем его банковскому клиенту доступ к контактам — чтобы выбрать одного при шаринге по ФИО
    Пояснять пользователю, для чего запрашивается разрешение. Если пользователь все же запретил приложению доступ, а без него оно не может, оно должно максимально понятно объяснить, что без этого разрешения оно работать дальше не будет

    Сегодня мы поговорили о самых заметных изменениях в Android Marshmallow. На днях я добавлю статью про остальные фичи и изменения, важные для нас, как для разработчиков. Спасибо за внимание и скорейшую оптимизацию ваших приложений под новый Android!

    Android Working with Marshmallow (M) Runtime Permissions

    Android is a privilege separated operating system, i.e. each application in android is separated from another through a distinct id, and each application file / data is private to that application only. Each Android application is started in its own process thus are isolated from all other applications (even from system / default applications). As a result an Android application can’t access any file or data outside its scope until and unless the file or data is shared with the application.

    So, the conclusion is that if an application needs anything outside its scope, then it should request for permission to the user. Android comes with a set of predefined permissions (System permissions) for certain tasks. Every application can request required permissions. For example, an application may declare that it requires network access. It can also define new permissions.

    1. Permission Workflow before and from M (API 23)

    Now the question arises how an application can request for or get permission? Or rather, what workflow the developer should follow to request and get permission for the app? Let us have a look. The permission model / workflow has been changed from API 23 – Android M.

    > Permission Model before M (API 23): Before API 23, the permission model was simpler to the developer but offered less control and security to the user – requested permissions are presented to the user before installing the application. The user needs to decide whether to give these permissions to the application and install it or to deny as a whole and don’t install the application. Permissions cannot be denied or granted after the installation. Thus developers were required only to declare all needed permissions in the manifest and then just forget; if the app is running then it has all the requested permissions.

    > Permission Model from M (API 23): With Android 6.0 Marshmallow (API 23), a new runtime permission model has been introduced. According to this model users are not prompted for permission at the time of installing the app, rather developers need to check for and request permission at runtime (i.e. before performing any action that may require the particular permission), users can then allow or deny the permission, users can also grant or revoke permission anytime from settings. Making the user experience very secure on an Android device. But inversely this feature imposes a great deal of effort on development. Therefore developers have to handle all the use cases. Thankfully, requesting Android runtime permissions, is not that difficult.

    Note: According to Google, beginning with Android 6.0 (API level 23), users can revoke permissions from any app at any time, even if the app targets a lower API level. You should test your app to verify that it behaves properly when it’s missing a needed permission, regardless of what API level your app targets.

    2. Permission levels

    System permissions have different protection levels. The two most important protection levels are normal and dangerous permissions.

    Normal Permissions: Those permissions which will have very little or zero effect on users privacy or security are categorized as normal permissions. The system itself grants normal permissions when requested instead of prompting to the user. Examples would be ACCESS_WIFI_STATE, WAKE_LOCK etc.

    Dangerous Permissions: Those permissions which may have a greater effect on users privacy or security are categorized as dangerous permissions. Examples would be the ability to read the user’s contacts READ_CONTACTS. If an app requests a dangerous permission, the user has to explicitly grant the permission to the app.

    Here is the detailed information about permissions and their groups.

    So now let us start with creating a sample app.

    3. Creating Android Project

    1. Create a new project in Android Studio from File ⇒ New Project and fill the project details.

    2. Open strings.xml and add the below string values.

    3. Open build.gradle (app level) and make sure that you have set minSdkVersion and targetSdkVersion as we have to support the permissions model in lower versions also. I am keeping minSdkVersion to 17 and targetSdkVersion to 23.

    3.1 Requesting Single Permission

    4. Though we will request the permissions at runtime, we should add it to the Manifest also, so that the user will be prompted first time when going to use the permission, and then the system will remember user’s decision until user updates from the settings. We will start with the WRITE_EXTERNAL_STORAGE_PERMISSION. Add the storage permission to your AndroidManifest.xml just before the application tag.

    5. Open the layout file of main activity (activity_main.xml) and add the below xml. This layout contains few buttons to test various permission scenarios.

    The above layout generates a screen something like this.

    6. Now open MainActivity.java and add the below code in FAB click event.

    Explanation:

    > We checked for permission with checkSelfPermission() Method to check if the app already has permission to write on external storage. If it has then continue to else part, otherwise go to next step.

    > Here we used shouldShowRequestPermissionRationale() method to check if we should show the explanation for the permission or not, if this returns true then we showed an alert dialog with explanation, and on the positive button click we requested the permission. If shouldShowRequestPermissionRationale returns false then we requested permission straightforward.

    > We have successfully requested permission so far. We just need to override the method onRequestPermissionsResult to receive the result. In that method first we checked the requested code with our declared constant requestCode == EXTERNAL_STORAGE_PERMISSION_CONSTANT then checked if length of grantResult is greater than 0, so that it contains the user’s decision, then we cheked if the value of 0 index of the grant result, if the value is equal to PackageManager.PERMISSION_GRANTED then it means that the user has authorised the permission and we can continue our work, otherwise in the else part we can again request for permission with explanation.

    > Add SharedPreferences, think of a situation where the user has denied permission by checking “Never Ask Again”. In that scenario the shouldShowRequestPermissionRationale method will return false and requestPermissions method will do just nothing. So we need to remember whether we ave priorly requested for permission or not, even after the app restarts. For that purpose we will use SharedPreferences, we will use the permission string as the key and boolean true or false as value.

    Below is the complete code of MainActivity.java

    3.2 Requesting Multiple Permissions

    Think of a scenario where you might need to ask for multiple permissions. For this, instead of requesting multiple permissions in multiple dialogs, we can prompt all the permissions in a single dialog where permissions will be scrolled through one after another. Now we’ll test this case by creating a new activity.

    7. Create a new Activity and name it as MultiplePermissionsActivity.java. Open the layout file this activity (activity_multiple_permissions.xml) and add the below layout code.

    8. Initialize btnLaunchMultiplePermission inside oncreate on MainActivity.java, and implement onClickListener to open MultiplePermissionsActivity on click.

    9. Add the below permissions to AndroidManifest.xml file.

    10. Open MultiplePermissionsActivity.java and modify the code as below.

    What we’ve done here is that created and string array with required permissions. While checking for permissions, checked by all elements of the array. The only exception is in while checking with SharedPreferences, here we’ve checked with only the first string, the reason is that for storing shared preferences on string is enough and only one shared preference can tell us whether we’ve already requested for permissions or not (as we are requesting for all permissions in one go).

    In the onRequestPermissionsResult() method we used a for loop to determine whether all permissions are granted or not. If a single permission is not granted then we will not proceed further.

    3.3 Requesting Permission From Fragment

    We will now move forward to requesting permission from Fragments. Now let us take a different approach. We will request for Phone State permission (we will actually do nothing with the permissions, we just ask for the permissions and will show the permission we’ve got).

    11. Create a new Activity and name it as FragmentPermissionActivity.java. Fill the required details and check Use a Fragment.

    12. Initialize btnLaunchPermissionFragment inside oncreate on MainActivity.java, and implement onClickListener to open FragmentPermissionActivity on click.

    13. Add below permission to AndroidManifest.xml

    14. Open PermissionsFragment.java and modify the code as below.

    So everything here is almost same when you request for permission from fragment or activity, except for that you should not use ActivityCompat.requestPermissions when requesting from Fragment instead use the inbuilt method of fragment.

    I hope this article gave you very good overview of Marshmallow permission model. Feel free to ask any queries / doubts in comments section below.

    What’s Next?

    Although this article explains very well about Runtime Permissions, it’s still very tedious task implementing permissions and its needs lot of code. If you want to quickly add runtime permissions, consider using Dexter library.

    App Permissions в Android – что это и как его использовать

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

    Зачем необходим App Permissions на Android и как его удалить.

    Что это такое

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

    Читать еще:  EncryptOnClick — инструмент для быстрого шифрования файлов, совместимый с популярными архиваторами

    Совершать и принимать вызовы

    Это означает, что ПО может автоматически сделать звонок. Каждая утилита может самостоятельно запускать номеронабиратель и даже вводить номер, но, если это разрешение не предоставлено, пользователю нужно нажать кнопку вызова. Такие вещи, как сторонний номеронабиратель, Google Voice или всё, что связано с вашей телефонной «звонилкой», должно иметь это разрешение. Если ПО его запрашивает, но не должно иметь ничего общего с совершением звонков, отклоните запрос и выясните причину запроса у разработчиков через отзывы на Google Play. Даже если причины использования того или иного разрешения вам не понятны, они могут требоваться для стабильной работы программ.

    Получение и отправка SMS или MMS

    Подписные SMS-сервисы – лёгкий способ для мошенника заработать деньги, так что за ними нужно следить. Доступ понадобится SMS-приложениям (что очевидно), а также утилитам, которые позволяют редактировать или делать снимки, а также делиться ими. Программы, которые могут совместно использовать любые медиа, скорее всего будут иметь эту настройку. Если софт не может никому ничего отправлять, следует проверить, зачем это нужно разработчикам.

    Чтение/запись контактов

    Почтовый клиент или мессенджер любого типа использует это разрешение, чтобы делать именно то, о чём говорит его название – читать ваши контакты. Например, Twitter или Facebook – они хотят иметь возможность находить ваших друзей, которые также пользуются их услугами, или упростить для вас рассылку спама тем, кто этого не делает. «Контакты» – это широкий термин, потому что в отдельном контакте может храниться много различной информации. Например, в играх, где также есть списки лидеров. Всё, что может связать вас с другим пользователем, будет нуждаться в этом разрешении. Права на сохранение контактов следует той же логике – если утилита может добавить контакт, ей может потребоваться это разрешение. В этом случае «записать» означает изменить или добавить в список контактов, а не написать сообщение.

    Чтение/запись событий календаря

    Здесь всё довольно просто. Настройка позволяет делать только одно – автоматически читать календарь. Некоторые утилиты должны иметь доступ к календарю. Это программы, которые могут напоминать о приёме лекарств или автоматически сообщать о предстоящей поездке, считывая данные из календаря. Если программа каким-либо образом связана с планированием, то использование такого доступа вполне оправдано. Если это не так, перед установкой выясните, зачем приложению нужен доступ к календарю. Запись событий календаря является обычным делом. Если неясно, зачем программе нужны эти настройки, описание в магазине Play должно рассказать вам больше. Если вы все ещё не уверены, спросите разработчика.

    Phone Status And Identity

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

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

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

    GPS и сетевое местоположение

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

    Изменять/Удалять содержимое SD-карты

    Это разрешение, которое позволяет приложению читать или записывать данные на внешнюю память смартфона. Необходимо, чтобы дать приложению возможность свободно просматривать данные, изменять их, удалять и добавлять дополнительную информацию данные в любое место на SD-карте. Сбивает с толку тот факт, что под SD-картой подразумевается не только флешка. В файловой системе Android память телефона также называется SD-картой. Google многое сделал, чтобы сделать это разрешение безвредным. В каждой версии они уточняют, как приложение может получить доступ только к той информации, которая ему нужна. Но все ещё есть пользователи, использующие старые версии программ и ОС. Если вы один из них, убедитесь, что вы доверяете приложению, прежде чем устанавливать его. Любое приложение, написанное для API уровня 4 (Android 1.6 Donut) или ниже, получает это разрешение по умолчанию. Таких приложений не так много. Какой вред это может принести, зависит от того, какие данные хранятся в памяти вашего телефона. Телефоны под управлением Android 7 Nougat и приложения, созданные для телефонов под управлением Android 7, используют доступ к каталогу в заданной области, что гораздо удобнее и безопаснее.

    Полный доступ к сети

    Это разрешение означает именно то, что оно говорит. Приложение хочет иметь возможность отправлять запросы и получать ответ через сеть (Wi-Fi или подключение для передачи данных по мобильной сети). Помимо приложений, которые используют Интернет для чего-то очевидного, в них нуждаются в этом приложения с рекламой. Разрешение довольно безвредное, но, когда речь заходит о вашей личной информации, оно может использовать данные без вашего ведома. Мы ненавидим платить за дополнительные данные так же, как и вы. Если вы найдёте приложение, которое должно работать в автономном режиме, но не работает, удалите его.

    Как удалить App Permissions

    Чтобы найти свои приложения и их разрешения на Android, откройте «Настройки», а затем нажмите «Приложения и уведомления», «Информация о приложении» и выберите интересующее вас приложение. Выберите пункт «Разрешения», чтобы просмотреть, какими из них обладает приложение. Вы можете отключить любое из них в любое время, передвинув переключатель рядом с этой записью. Другой вариант – просматривать по разрешению, а не по приложению. Откройте «Настройки» и перейдите в раздел «Приложения и уведомления», как и в предыдущем случае. Но на этот раз выберите «Разрешения приложения». Откроется список разрешений, который включает датчики, календарь, камеру, контакты, местоположение, микрофон, SMS, память, телефон и многое другое. Нажмите любую запись, чтобы увидеть, какие приложения могут получить доступ к этой функции. Здесь также с помощью переключателей можно убрать любые настройки. Прежде чем начинать отключать разрешения, помните, что для выполнения своей работы некоторые приложения полагаются на этот доступ. Например, если приложение может просматривать ваши контакты, оно использует их, чтобы помочь вам обмениваться контентом, файлами или приглашать друзей на мероприятия, а не собирать ваши данные для получения прибыли.

    Разрешения при загрузке софта

    Когда вы загружаете программы из Play Store, некоторые из них перед установкой запрашивают разрешение на использование информации. При загрузке приложений, созданных для Android 6.0 и более поздних версий, вы можете предоставить или запретить разрешения непосредственно во время установки. Чтобы просмотреть разрешения той или иной утилиты перед установкой, сделайте следующее:

    1. Откройте приложение Play Store.
    2. Перейти на страницу сведений о приложении. Чтобы просмотреть разрешения перед установкой, пролистайте до раздела «Разработчик» и нажмите «Сведения о разрешениях».
    3. Нажмите «Установить».

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

    Если приложение уже установлено

    Для приложений, созданных для Android 6.0 и выше, просматривать или принимать изменения разрешений при каждом обновлении не нужно. Достаточно указать необходимые права при первом запуске программы. Если при обновлении приложению требуется доступ к новым группам разрешений или разрешениям в группе «Другие», вам будет предложено заново подтвердить решение, даже если вы настроили автоматические обновления. Если вы предпочитаете просматривать каждое обновление вручную, вы можете отключить автоматическое обновление, следуя приведённым ниже инструкциям:

    1. Откройте приложение Play Store.
    2. Нажмите кнопку Меню – Мои приложения и игры – Установленные.
    3. Выберите приложение.
    4. Нажмите Больше (вертикальная линия из 3-х точек).
    5. Снимите флажок «Автообновление», если он ещё не снят.

    Чтобы отключить автообновление для всех приложений:

    1. Откройте приложение Play Store.
    2. Нажмите кнопку Меню – Настройки – Автообновление приложений – Никогда не обновлять автоматически.

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

  • Ссылка на основную публикацию
    Статьи c упоминанием слов:
    Adblock
    detector