После отзыва разрешения в настройках приложение продолжает считать доступ разрешённым. Как доказать, что причина в устаревшем состоянии приложения, а не в фактическом доступе к ресурсу?
Нужно разделить проверку на два независимых признака: текущий статус разрешения, сообщаемый ОС, и результат реальной операции с защищённым ресурсом. После отзыва разрешения следует повторно получить системный статус, выполнить операцию и проверить обработку отказа; значение, сохранённое приложением ранее, нельзя считать источником истины.
Если приложение показывает старое состояние, но ОС сообщает запрет или операция завершается отказом, проблема находится в кэшировании статуса либо в отсутствии обновления состояния интерфейса. Проверять сценарий следует как минимум после возврата из настроек, возобновления приложения и холодного запуска.
Мобильные ОС постепенно перенесли контроль доступа к камере, микрофону, геолокации, фотографиям и другим ресурсам от момента установки приложения к моменту фактического использования. Это решало проблему чрезмерных постоянных разрешений и давало пользователю возможность изменить решение после первоначального предоставления доступа.
На iOS доступ может иметь разные уровни, например приблизительная геолокация или ограниченный набор фотографий. На Android встречаются одноразовые разрешения, автоматический отзыв неиспользуемых разрешений и различия между версиями ОС. Поэтому результат предыдущего запроса не является гарантией текущего состояния.
Приложение может сохранить локальный флаг вроде «доступ разрешён» и использовать его при следующем отображении экрана. Пользователь тем временем отзывает разрешение в системных настройках, а приложение при возврате продолжает показывать доступный функционал.
Риски зависят от ресурса: камера или микрофон могут не запуститься, геолокация может остаться старой, а пользователь может получить сообщение о готовности функции, которая фактически недоступна. Для чувствительных операций это также создаёт ошибочные предположения о том, какие данные приложение действительно может получить.
Сначала тестировщик фиксирует исходное состояние: разрешение предоставлено, функция успешно работает. Затем приложение переводится в фон, разрешение отзывается или изменяется в настройках ОС, после чего приложение возвращается на экран и повторяет операцию.
Проверяются три слоя:
На iOS важно проверять переходы между уровнями доступа, включая изменение точности геолокации и ограниченного доступа к фотографиям. На Android нужно учитывать различия версий, одноразовый доступ, отзыв разрешений неиспользуемого приложения и отдельные разрешения для разных типов ресурсов.
Проверка только после полного перезапуска недостаточна: ошибка может проявляться именно при возврате из настроек, когда процесс приложения не уничтожен. В то же время повторная проверка при каждом отображении экрана не заменяет обработку ошибки самой операции: статус мог измениться между проверкой и использованием ресурса.
Хорошая реализация использует системный статус как ориентир для интерфейса, но окончательное решение принимает по результату операции. Приложение не должно бесконечно повторять запрос, если пользователь выбрал постоянный запрет; вместо этого нужно объяснить причину и предложить открыть настройки, если такой переход поддерживается сценарием.
В приложении для доставки после возврата из системных настроек экран продолжал показывать адрес курьера, хотя пользователь запретил геолокацию. Рассматривались три варианта: обновлять экран только при полном запуске, проверять статус при каждом появлении экрана или всегда получать геопозицию без предварительной проверки.
Первый вариант был простым, но не исправлял ошибку при возврате из настроек. Третий вариант лучше выявлял фактический отказ, но приводил к лишним системным ошибкам и ухудшал объяснение пользователю. Выбрали комбинацию: обновлять статус при возобновлении приложения и при показе экрана, а результат запроса геопозиции обрабатывать отдельно.
После этого при отзыве разрешения экран скрывал устаревший адрес, показывал причину недоступности геолокации и предлагал ручной ввод. При временном отказе системы или изменении точности приложение также не считало старые координаты актуальными.
1. Достаточно ли проверить только статус разрешения, не выполняя реальную операцию?
Нет. Статус разрешения и возможность конкретной операции не всегда полностью совпадают: влияют точность геолокации, ограниченный набор фотографий, системные ограничения, настройки службы и ошибки самого ресурса. Поэтому нужен тест, который проверяет и системное состояние, и фактический результат использования.
2. Почему проверка только при холодном запуске не гарантирует корректность?
Пользователь может изменить разрешение, пока процесс приложения остаётся в памяти. При возврате из настроек приложение не обязано заново проходить полный запуск, поэтому закэшированный статус и интерфейс могут сохраниться. Проверку нужно связывать с возобновлением приложения или появлением соответствующего экрана, не полагаясь только на событие запуска.
3. Нужно ли каждый раз снова показывать пользователю системный запрос после отказа?
Нет. Повторный запрос не всегда приводит к системному диалогу: поведение зависит от платформы, типа разрешения и истории решений пользователя. После постоянного отказа корректнее показать объяснение и маршрут к настройкам, а перед повторным запросом учитывать текущий системный статус и контекст действия пользователя.