Зачем нужен файл permissions

Обновлено: 25.01.2025

PermissionsEX (PEX) — плагин который позволяет легко разграничивать полномочия игроков на сервере. Имеет встроенные дополнения Modifyworld, которое дает возможность определять что игроки могут или не могут изменять в игровом мире.

Содержание

Установка

Использование

Для распределения прав игрокам нужно отредактировать файл permissions.yml по адресу plugins/PermissionsEx. Это можно сделать с помощью любого текстового редактора, но для удобности рекомендуется использовать Notepad++
Открыв его мы увидим:

Значение этих строк следующее:
groups: — указывает, что ниже будут идти группы и их права.
default: — название группы, куда попадают все только что зашедшие на сервер игроки, если они не прописаны в других группах. Вы можете менять это название на какое захотите.
default: true — параметр, который задаёт группу, как группу по-умолчанию. То есть, все права этой группы будет иметь любой игрок, для которого не определены другие группы и/или исключения.
permissions: — все, что идёт ниже, это и есть сами "права" для группы, сюда нужно прописывать permissions от различных плагинов установленных на вашем сервере. Значение null означает, что у группы/игрока нет никаких прав.
- modifyworld.* — возможность "модифицировать" мир. Если Вы не намерены конкретно определять, что игроки могут или не могут изменять в игровом мире, то это право лучше оставить как есть, а если намеренны, то смотрите в Modifyworld.

Рассмотрим как мы можем отредактировать данный файл:

Здесь мы добавили новую группу Admins, а также права для отдельного игрока BigBoss:.
default: false — означает, что данная группа не является группой по-умолчанию.
inheritance: — параметр, с помощью которого можно установить наследственность прав определённой группы, в данном случае — это группа default. Это значит, что Вам не придётся еще раз прописывать права группы default для группы Admins.
Звездочка ('*') означает, что у группы/игрока есть абсолютно все права на все плагины, установленные на сервере.
users: — означает, что ниже идут права отдельных игроков.
BigBoss: — имя игрока для которого настраиваются отдельные права.
group: Admins — указывает на то, что игрок входит в группу Admins
rank: — ранг игрока.

Если Вы хотите раскрасить ники игроков и добавить к ним префиксы и суффиксы то нужно включить и настроить в permissions.yml Chat Manager.

Важно! В YAML нужно чётко соблюдать последовательность, один лишний пробел — и параметр работать не будет. Поэтому для проверки permissions.yml рекомендуется использовать этот сайт. Там в левое окошко нужно вставить ваш код из permissions.yml, и если в правом окне не выдаст ошибок, то код написан правильно и он будет работать, если будут ошибки, то оно выдаст номер забракованной строки.

Команды и права

С помощью следующих команд вы можете управлять PEX прямо через консоль или игровой чат, не редактируя файл permissions.yml

Добавление префиксов и суффиксов будет работать только если включен Chat Manager или EssentialsChat (начиная с 1.6.4).
Значение параметров: <такой> параметр обязателен для указания; [такой] параметр — опциональный.
Параметр [world] позволяет локализировать действие команды в определенном мире.
Там где упоминается единственное/множественное можно перечислять параметры через запятую.

Служебные

Управление правами игроков

Команда	Permission	Описание
/pex users	permissions.manage.users	Показывает список всех записанных пользователей. И игроков сервера
/pex user <user> [world]	permissions.manage.users	Показывает права игрока <user>
/pex user <user> prefix [newprefix] [world]	permissions.manage.users.prefix.<user>	Установить игроку <user> префикс [newprefix]
/pex user <user> suffix [newsuffix] [world]	permissions.manage.users.suffix.<user>	Установить игроку <user> суффикс [newsuffix]
/pex user <user> delete	permissions.manage.users.<user>	Удалить игрока <user> из бэкенда, используемого на данный момент.
/pex user <user> add <permission> [world]	permissions.manage.users.permissions.<user>	Дать право <permission> игроку <user>
/pex user <user> remove <permission> [world]	permissions.manage.users.permissions.<user>	Забрать право <permission> у игрока <user>
/pex user <user> timed add <permission> [lifetime] [world]	permissions.manage.users.permissions.timed.<user>	Дать временное право <permission> игроку <user> на время [lifetime] (в сек.) Выставите значение на "" (две двойные скобки) если вы хотите использовать право во всех мирах!
/pex user <user> timed remove <permission>	permissions.manage.users.permissions.timed.<user>	Забрать у игрока <user> временное право <permission>
/pex user <user> set <option> <value> [world]	permissions.manage.users.permissions.<user>	Выставить опцию <option> на значение <value>. Выставите значение на "" (две двойные кавычки) если вы хотите убрать опцию <option>

Управление правами групп игроков

Команда	Permission	Описание
/pex user <user> group list [world]	permissions.manage.membership.<user>	Показать список групп в которых состоит игрок <user>
/pex user <user> timed add <group> [*][min\hour\day] = [3min]	permissions.manage.membership.<user>	Добавить игрока <user> в группу <group> на время [lifetime]
/pex user <user> group set <group> [world]	permissions.manage.membership.<user>	Установить группу <group> для игрока <user> (удалит его из остальных групп)
/pex user <user> group remove <group> [world]	permissions.manage.membership.<user>	Удалить игрока <user> из группы <group>

Управление правами групп

Управление игроками в группах

Управление наследственностью миров

Команда	Permission	Описание
/pex worlds	permissions.manage.worlds	Показать загруженные миры
/pex world <world>	permissions.manage.worlds	Показать информацию о наследственности мира <world>
/pex world <world> inherit <parentWorlds>	permissions.manage.worlds.inheritance	Установить родительский мир/миры <parentWorlds> для мира <world>

Критика

PermissionsEX (PEX) — плагин для Bukkit, который позволяет легко разграничивать полномочия игроков на сервере. Имеет встроенные дополнения Modifyworld, которое даёт возможность определять, что игроки могут или не могут изменять в игровом мире, а также ChatManager с помощью которого можно разделить чат на локальный и глобальный, раскрасить ники игроков и добавить к ним префиксы и суффиксы.

Содержание

Установка [ ]

Использование [ ]

Рассмотрим как мы можем отредактировать данный файл:

Команды и права [ ]

Добавление префиксов и суффиксов будет работать только если включен Chat Manager или EssentialsChat (начиная с 1.6.4).
Значение параметров: <такой> параметр обязателен для указания; [такой] параметр — опциональный.
Параметр [world] позволяет локализировать действие команды в определенном мире.
Там где упоминается единственное/множественное можно перечислять параметры через запятую.

Служебные [ ]

Управление правами игроков [ ]

Команда	Permission	Описание
/pex users	permissions.manage.users	Показывает список всех записанных пользователей. И игроков сервера
/pex user <user> [world]	permissions.manage.users	Показывает права игрока <user>
/pex user <user> prefix [newprefix] [world]	permissions.manage.users.prefix.<user>	Установить игроку <user> префикс [newprefix]
/pex user <user> suffix [newsuffix] [world]	permissions.manage.users.suffix.<user>	Установить игроку <user> суффикс [newsuffix]
/pex user <user> delete	permissions.manage.users.<user>	Удалить игрока <user> из бэкенда, используемого на данный момент.
/pex user <user> add <permission> [world]	permissions.manage.users.permissions.<user>	Дать право <permission> игроку <user>
/pex user <user> remove <permission> [world]	permissions.manage.users.permissions.<user>	Забрать право <permission> у игрока <user>
/pex user <user> group add <permission> [world] [lifetime]	permissions.manage.users.permissions.timed.<user>	Дать временное право <permission> игроку <user> на время [lifetime] (в сек.) Выставите значение на "" (две двойные скобки) если вы хотите использовать право во всех мирах!
/pex user <user> group remove <permission>	permissions.manage.users.permissions.timed.<user>	Забрать у игрока <user> временное право <permission>
/pex user <user> set <option> <value> [world]	permissions.manage.users.permissions.<user>	Выставить опцию <option> на значение <value>. Выставите значение на "" (две двойные кавычки) если вы хотите убрать опцию <option>

Управление правами групп игроков [ ]

Команда	Permission	Описание
/pex user <user> group list [world]	permissions.manage.membership.<user>	Показать список групп в которых состоит игрок <user>
/pex user <user> group add <group> [*] [lifetime]	permissions.manage.membership.<user>	Добавить игрока <user> в группу <group> на время [lifetime]= [min\hour\day] = [3min]
/pex user <user> group set <group> [world]	permissions.manage.membership.<user>	Установить группу <group> для игрока <user> (удалит его из остальных групп)
/pex user <user> group remove <group> [world]	permissions.manage.membership.<user>	Удалить игрока <user> из группы <group>

Управление правами групп [ ]

Управление игроками в группах [ ]

Управление наследственностью миров [ ]

Команда	Permission	Описание
/pex worlds	permissions.manage.worlds	Показать загруженные миры
/pex world <world>	permissions.manage.worlds	Показать информацию о наследственности мира <world>
/pex world <world> inherit <parentWorlds>	permissions.manage.worlds.inheritance	Установить родительский мир/миры <parentWorlds> для мира <world>

Критика [ ]

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

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

Что это такое

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

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

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

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

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

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

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

Здесь всё довольно просто. Настройка позволяет делать только одно – автоматически читать календарь. Некоторые утилиты должны иметь доступ к календарю. Это программы, которые могут напоминать о приёме лекарств или автоматически сообщать о предстоящей поездке, считывая данные из календаря. Если программа каким-либо образом связана с планированием, то использование такого доступа вполне оправдано. Если это не так, перед установкой выясните, зачем приложению нужен доступ к календарю. Запись событий календаря является обычным делом. Если неясно, зачем программе нужны эти настройки, описание в магазине 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 и более поздних версий, вы можете предоставить или запретить разрешения непосредственно во время установки. Чтобы просмотреть разрешения той или иной утилиты перед установкой, сделайте следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перейдем к непосредственной реализации (предварительно не забудем обновить compileSdkVersion и targetSdkVersion до версии 23).

До момента, когда Marshmallow станет минимальной версией андроида для ваших приложений, еще далеко, поэтому нужно позаботиться об обратной совместимости. Конечно, можно делать проверки версии sdk, но зачем, если все реализовано за нас в support library v4 (ActivityCompat) и v13 (FragmentCompat). Если все же вам понадобятся оригинальные методы, то найти их не составит труда.

Во всех примерах используется ActivityCompat, так как они были сделаны для activity. Для fragment нужно использовать FragmentCompat. Если вы по какой-то причине не используете activity и fragment из support библиотек, то вам нужно реализовать интерфейс ActivityCompat.OnRequestPermissionsResultCallback или FragmentCompat.OnRequestPermissionsResultCallback соответственно.

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

Стоит упомянуть, что если разрешения находятся в одной 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’ы (подробнее).

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