В соответствии с этим: http://developer.android.com/preview/features/runtime-permissions.html#coding приложение может проверять разрешения во время выполнения и запрашивать разрешения, если оно еще не было предоставлено. Затем появится следующий диалог:
В случае, если пользователь отклоняет важное разрешение, в приложении должно отображаться объяснение, почему требуется разрешение и какое влияние имеет снижение. Этот диалог имеет две опции:
- повторите попытку (разрешение запрашивается снова)
- отрицать (приложение будет работать без этого разрешения).
Однако, если пользователь проверяет Never ask again
, второе диалоговое окно с объяснением не должно отображаться, особенно если пользователь уже один раз отказался. Теперь вопрос: как мое приложение узнает, проверил ли пользователь Never ask again
? ИМО onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults)
не дает мне эту информацию.
Второй вопрос: есть ли у Google планы включить пользовательское сообщение в диалог разрешений, которое объясняет, почему приложению нужны разрешения? Таким образом, никогда не будет второго диалога, который определенно улучшил бы UX.
источник
Ответы:
В Developer Preview 2 внесены некоторые изменения в том, как приложение запрашивает разрешения (см. Также http://developer.android.com/preview/support.html#preview2-notes ).
Первый диалог теперь выглядит так:
Нет флажка «Никогда больше не показывать» (в отличие от предварительного просмотра для разработчиков 1). Если пользователь отказывает в разрешении и если разрешение имеет важное значение для приложения, он может представить другой диалог, объясняющий причину, по которой приложение запрашивает такое разрешение, например, так:
Если пользователь снова отказывается, приложение должно либо закрыться, если ему абсолютно необходимо это разрешение, либо продолжить работу с ограниченными функциональными возможностями. Если пользователь пересматривает (и выбирает повторную попытку), разрешение запрашивается снова. На этот раз приглашение выглядит так:
Во второй раз отображается флажок «Никогда больше не спрашивать». Если пользователь снова отказывается и флажок установлен, больше ничего не должно происходить. Установлен ли флажок или нет, можно определить с помощью Activity.shouldShowRequestPermissionRationale (String), например, так:
Вот что говорится в документации Android ( https://developer.android.com/training/permissions/requesting.html ):
Чтобы узнать, отказал ли пользователь в «никогда больше не спрашивать», вы можете еще раз проверить метод shouldShowRequestPermissionRationale в своем onRequestPermissionsResult, когда пользователь не предоставил разрешение.
Вы можете открыть настройки своего приложения с помощью этого кода:
Нет способа отправить пользователя прямо на страницу авторизации.
источник
Вы можете проверить
shouldShowRequestPermissionRationale()
в своемonRequestPermissionsResult()
.https://youtu.be/C8lUdPVSzDk?t=2m23s
Проверьте, было ли разрешение предоставлено или нет
onRequestPermissionsResult()
. Если нет, то проверьтеshouldShowRequestPermissionRationale()
.true
покажите объяснение, почему именно это разрешение необходимо. Затем в зависимости от выбора пользователя сноваrequestPermissions()
.false
покажите сообщение об ошибке, что разрешение не было предоставлено, и приложение не может продолжить работу или определенная функция отключена.Ниже приведен пример кода.
Видимо, Google Maps делает именно это для разрешения местоположения.
источник
Вот хороший и простой способ проверить текущий статус разрешения:
Предостережение: возвращает BLOCKED_OR_NEVER_ASKED при первом запуске приложения, прежде чем пользователь принял / отклонил разрешение через приглашение пользователя (на устройствах sdk 23+)
Обновить:
Библиотека поддержки Android теперь также имеет очень похожий класс,
android.support.v4.content.PermissionChecker
который содержитcheckSelfPermission()
:источник
BLOCKED_OR_NEVER_ASKED
если разрешение еще не было запрошено.android.content.pm
уже определяетPERMISSION_GRANTED = 0
иPERMISSION_DENIED = -1
. Возможно установитьBLOCKED_OR_NEVER_ASKED = PERMISSION_DENIED - 1
или что-то?После того, как пользователь отметил «Не спрашивать снова», вопрос не может быть отображен снова. Но пользователю может быть объяснено, что он ранее отказал в разрешении и должен предоставить разрешение в настройках. И сослаться на него в настройках, используя следующий код:
источник
Может быть кому-то пригодится: -
Я заметил, что если мы проверяем флаг shouldShowRequestPermissionRationale () в методе обратного вызова onRequestPermissionsResult (), он показывает только два состояния .
Состояние 1: -Возврат истины: - Каждый раз, когда пользователь нажимает кнопку «Запретить разрешения» (включая самый первый раз).
Состояние 2: - Возвращает false: - если пользователь выбирает «никогда не спрашивает».
Ссылка подробного рабочего примера
источник
onRequestPermissionsResult
, а не когда фактически запрашиваете разрешение.Вы можете определить это, проверив, должно ли обоснование разрешения показываться внутри
onRequestPermissionsResult()
метода обратного вызова. И если вы обнаружите какой-либо набор разрешений, чтобы никогда больше не запрашивать , вы можете попросить пользователей предоставить разрешения из настроек.Моя полная реализация была бы как ниже. Он работает как для одного, так и для нескольких запросов разрешений. Используйте следующее или напрямую используйте мою библиотеку.
источник
Если вы хотите обнаружить все «состояния» (в первый раз отклонено, только что было отклонено, просто отклонено с помощью «Никогда не спрашивать снова» или окончательно отклонено), вы можете сделать следующее:
Создать 2 логических
Установите первый, прежде чем запрашивать разрешение:
Установите второй в вашем методе onRequestPermissionsResult:
Используйте следующую «таблицу», чтобы сделать все, что вам нужно, в onRequestPermissionsResult () (после проверки, что у вас все еще нет разрешения):
источник
// TRUE FALSE
также происходит, когда пользователь разрешает разрешение, предварительно отказав в нем.У меня была такая же проблема, и я понял это. Чтобы упростить жизнь, я написал класс util для обработки разрешений во время выполнения.
И методы PreferenceUtil заключаются в следующем.
Теперь все, что вам нужно, это использовать метод * checkPermission * с правильными аргументами.
Вот пример,
Если пользователь установил флажок Никогда не спрашивать , вы получите обратный вызов onPermissionDisabled .
Удачного кодирования :)
источник
shouldShowRequestPermissionRationale
, сохранив предпочтение запроса, отправленного пользователю. У меня была такая же идея, и я нашел твой ответ. Хорошая работа человекПолное объяснение для каждого случая разрешения
источник
Полезная функция, чтобы определить, было ли заблокировано произвольное разрешение для запроса (в Kotlin):
Использование этого требует установки логического параметра с общими предпочтениями с именем вашего желаемого разрешения (например
android.Manifest.permission.READ_PHONE_STATE
),true
когда вы впервые запрашиваете разрешение.Объяснение:
Build.VERSION.SDK_INT >= Build.VERSION_CODES.M
так как часть кода может быть запущена только на уровне API 23+.ContextCompat.checkSelfPermission(activity, permission) != PackageManager.PERMISSION_GRANTED
чтобы проверить, у нас еще нет разрешения.!activity.shouldShowRequestPermissionRationale(permission)
чтобы проверить, отклонил ли пользователь приложение снова. Из-за особенностей этой функции , также необходима следующая строка.PreferenceManager.getDefaultSharedPreferences(activity).getBoolean(permission, false)
это используется (наряду с установкой значения true в первом запросе разрешения), чтобы различать состояния «Никогда не спрашивал» и «Никогда не спрашивать», так как предыдущая строка не возвращает эту информацию.источник
Метод shouldShowRequestPermissionRationale () можно использовать для проверки, выбрал ли пользователь параметр «никогда больше не спрашивать» и отказал в разрешении. Существует множество примеров кода, поэтому я бы лучше объяснил, как использовать его для таких целей, потому что я думаю, что его имя и его реализация усложняют его, чем оно есть на самом деле.
Как объясняется в разделе «Запрос разрешений во время выполнения» , этот метод возвращает значение true, если опция «никогда не спрашивать» видна, в противном случае - значение false; поэтому он возвращает ложь в самый первый раз, когда отображается диалоговое окно, затем со второго раза он возвращает истину, и только если пользователь отказывает в разрешении при выборе параметра, в этот момент он снова возвращает ложь.
Чтобы обнаружить такой случай, либо вы можете обнаружить последовательность false-true-false, либо (более просто) у вас может быть флаг, который отслеживает начальное время, когда отображается диалоговое окно. После этого этот метод возвращает true или false, где false позволит вам определить, когда выбран этот параметр.
источник
Пожалуйста, не бросайте в меня камни для этого решения.
Это работает, но немного "взломано".
Когда вы звоните
requestPermissions
, зарегистрируйте текущее время.Затем в
onRequestPermissionsResult
если результат не предоставлен, проверьте время еще раз.
Поскольку пользователь не может нажать кнопку «Отказ» так быстро, мы знаем, что он выбрал «никогда больше не спрашивать», потому что обратный вызов мгновенный.
Используйте на свой страх и риск.
источник
Я написал сокращение для запроса разрешения в Android M. Этот код также обрабатывает обратную совместимость со старыми версиями Android.
Весь уродливый код извлекается во фрагмент, который присоединяется и отключается от действия, запрашивая разрешения. Вы можете использовать
PermissionRequestManager
следующее:Посмотрите: https://gist.github.com/crysxd/385b57d74045a8bd67c4110c34ab74aa
источник
источник
Попробуйте эту простую библиотеку разрешений. Он будет обрабатывать все операции, связанные с разрешением, в 3 простых шага. Это сэкономило мое время. Вы можете закончить все связанные с разрешением работы за 15 минут .
Он может обрабатывать Запретить, может обрабатывать Никогда не спрашивать снова, Может вызывать настройки приложения для разрешения, Может выдавать сообщение Rational, Может выдавать сообщение Отказ, Может давать список принятых разрешений, Может давать список отклоненных. разрешения и т. д.
https://github.com/ParkSangGwon/TedPermission
Шаг 1: добавьте свою зависимость
Шаг 2: Спросите разрешения
Шаг 3: обработать ответ разрешения
источник
Вы можете слушать красавицу.
слушатель
MainClass для разрешения
Используется этим способом
переопределить onRequestPermissionsResult в активности или fragmnet
источник
Вместо этого вы получите обратный вызов
onRequestPermissionsResult()
как PERMISSION_DENIED, когда вы снова запросите разрешение, находясь в ложном состоянииshouldShowRequestPermissionRationale()
Из Android док:
Когда система просит пользователя предоставить разрешение, пользователь имеет возможность сказать системе не запрашивать это разрешение снова. В этом случае, каждый раз, когда приложение
requestPermissions()
снова запрашивает это разрешение, система немедленно отклоняет запрос. Система вызывает вашonRequestPermissionsResult()
метод обратного вызова и передаетPERMISSION_DENIED
его так же, как если бы пользователь снова явно отклонил ваш запрос. Это означает, что когда вы звонитеrequestPermissions()
, вы не можете предполагать, что какое-либо прямое взаимодействие с пользователем имело место.источник
Ты можешь использовать
if (ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA)
метод, чтобы определить, проверен ли никогда запрос или нетДля получения дополнительной информации: проверьте это
Чтобы проверить наличие нескольких разрешений, используйте:
метод объяснения ()
Выше кода также покажет диалоговое окно, которое перенаправит пользователя на экран настроек приложения, откуда он может дать разрешение, если выбрал кнопку «Никогда не спрашивать».
источник
Ты можешь использовать
внутри
Смотрите пример ниже:
Проверьте, есть ли у него разрешение, когда пользователь нажимает кнопку:
Когда пользователь ответит на диалоговое окно прав доступа, мы перейдем к onRequestPermissionResult:
источник
Я также хотел бы получить информацию о том, выбрал ли пользователь «никогда не спрашивать». Я достиг «почти решения» с уродливым флагом, но прежде чем я расскажу вам как, я расскажу вам о моей мотивации:
Я хотел бы предложить разрешение ссылаясь на функциональность изначально. Если пользователь использует его и не имеет прав, он получает 1-й диалог сверху или 2-й и 3-й. Когда пользователь выбрал «Никогда не спрашивать», я хотел бы отключить эту функцию и отобразить ее по-другому. - Мое действие вызвано вводом текста с вращением, я также хотел бы добавить «(Отозвано разрешение)» к отображаемому тексту метки. Это показывает пользователю: «Функциональность есть, но я не могу ее использовать из-за настроек разрешения». Тем не менее, это не представляется возможным, так как я не могу проверить, был ли выбран вариант «Никогда больше не спрашивать».
Я пришел к решению, с которым я могу жить, когда моя функция всегда включена с активной проверкой прав доступа. Я показываю сообщение Toast в onRequestPermissionsResult () в случае отрицательного ответа, но только если я не показывал свое настраиваемое обоснование. Поэтому, если пользователь выбрал «Никогда не спрашивать», он получает только тостовое сообщение. Если пользователь не хочет выбирать «никогда больше не спрашивать», он получает только пользовательское обоснование и всплывающее окно с запросом на разрешение операционной системой, но не тост, поскольку три уведомления подряд будут чересчур болезненными.
источник
Я должен реализовать динамическое разрешение для камеры. Где происходит 3 возможных случая: 1. Разрешить, 2. Отказать, 3. Больше не спрашивать.
источник
Расширяя ответ mVck выше, следующая логика определяет, был ли проверен «Никогда больше не спрашивать» для данного запроса на разрешение:
ниже приводится выдержка (полный пример см. в этом ответе )
источник
Вы можете прочитать официальный документ Android Запрос приложения разрешений
или вы можете найти много популярных библиотек разрешений Android на Github
источник
Чтобы точно ответить на вопрос, что происходит, когда пользователь нажимает «Никогда не спрашивать»?
Переопределенный метод / функция
Массив grantResult оказывается пустым, так что вы можете что-то там сделать? Но не лучшая практика.
Как справиться с «Никогда не спрашивай снова»?
Я работаю с Fragment, для которого требуется разрешение READ_EXTERNAL_STORAGE.
Другие функции тривиальны.
источник