Динамические разрешения

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

  • Разрешения, предоставляемые при установке

    (Android 5.1 и более ранние версии) Пользователи предоставляют приложению опасные разрешения при его установке или обновлении. Производители устройств и операторы связи могут предустанавливать приложения с заранее предоставленными разрешениями без уведомления пользователя.

  • Динамические разрешения

    Android 6.0–9. Пользователи предоставляют приложению опасные разрешения во время его работы. Когда запрашиваются разрешения (например, при запуске приложения или когда пользователь обращается к определенной функции), зависит от приложения, но пользователь предоставляет или запрещает приложению доступ к определенным группам разрешений. Производители устройств и операторы связи могут предустанавливать приложения, но не могут предоставлять разрешения заранее, если только не пройдут процедуру исключения. Подробнее о создании исключений…

    (Android 10) Пользователи могут видеть, у каких приложений есть динамические разрешения на распознавание действий, и управлять этими разрешениями. Пользователям предлагается выбрать один из вариантов в диалоговом окне динамических разрешений: "Разрешить всегда", "Разрешить только во время использования приложения" или "Запретить". При обновлении ОС до Android 10 разрешения, предоставленные приложениям, сохраняются, но пользователи могут изменить их в Настройках.

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

Затронутые разрешения

В Android 6.0 и более поздних версий для использования модели разрешений во время выполнения требуются опасные разрешения. Опасные разрешения – это разрешения с более высоким уровнем риска (например, READ_CALENDAR), которые предоставляют запрашивающим приложениям доступ к личным данным пользователя или контроль над устройством, что может негативно повлиять на пользователя. Чтобы посмотреть список опасных разрешений, выполните команду:

adb shell pm list permissions -g -d

В Android 6.0 и более поздних версий поведение обычных разрешений не изменилось. Это все неопасные разрешения, в том числе обычные, системные и разрешения на подпись. Обычные разрешения – это разрешения с низким уровнем риска (например, SET_WALLPAPER), которые предоставляют запрашивающим приложениям доступ к изолированным функциям на уровне приложения с минимальным риском для других приложений, системы или пользователя. Как и в Android 5.1 и более ранних версиях, система автоматически предоставляет обычные разрешения приложению, которое их запрашивает, во время установки и не запрашивает у пользователя подтверждение. Подробную информацию о разрешениях можно найти в документации по элементу<permission>.

Строгие и нестрогие ограничения в Android 10

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

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

При установке приложения установщик (например, Google Play) может не добавить в белый список ограниченные разрешения для приложения. Разрешения ограничиваются платформой и могут быть предоставлены только в том случае, если приложение соответствует специальным критериям согласно правилам платформы. Примеры разрешений с жесткими ограничениями: доступ к SMS и списку вызовов.

Добавление в белый список происходит во время установки и когда

  • приложение уже установлено во время обновления Android с версии 9 до 10.
  • разрешение предоставлено заранее или приложение предустановлено.
  • Для роли, которая уже определена, требуется разрешение, чтобы добавить его в белый список.
  • установщик (например, Google Play) отмечает разрешение как включенное в белый список.

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

Требования

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

  • Модель разрешений во время выполнения должна быть одинаковой на всех устройствах с Android 6.0 и более поздними версиями. Это требование обеспечивается с помощью тестов Android Compatibility Test Suite (CTS).
  • Приложения должны запрашивать у пользователей разрешения для приложения во время выполнения. Подробнее о том, как обновить приложения… Для приложений и обработчиков по умолчанию, которые обеспечивают базовую функциональность устройства, необходимую для его работы, могут быть сделаны исключения. Например, стандартное приложение "Телефона" для обработки ACTION_CALL может иметь доступ к разрешению "Телефон". Подробнее о создании исключений…
  • В предустановленных приложениях с опасными разрешениями должен быть задан целевой уровень API 23 и сохранена модель динамических разрешений. То есть интерфейс при установке приложения не должен отличаться от реализации PermissionController в AOSP, пользователи могут отзывать опасные разрешения у предустановленных приложений и т. д.
  • Приложения без интерфейса должны использовать активность, чтобы запрашивать разрешения или передавать UID другому приложению, у которого есть необходимые разрешения. Подробнее о приложениях без интерфейса…

Перенос разрешений

Разрешения, предоставленные приложениям в Android 5.x, сохраняются после обновления до Android 6.0 или более поздней версии, но пользователи могут отозвать их в любое время.

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

Интеграция

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

Как обновлять приложения

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

Предустановленные приложения

В Android 9 и более ранних версиях предустановленные приложения, использующие опасные разрешения, должны быть предназначены для целевого уровня API 23 или более поздней версии и поддерживать модель разрешений AOSP для Android 6.0 и более поздних версий. Например, интерфейс установки приложения не должен отличаться от реализации PermissionController в AOSP. Пользователи могут даже отзывать опасные разрешения у предустановленных приложений.

В Android 6.0–9 некоторые разрешения предоставляются во время установки. Однако начиная с версии 10 процесс установки (выполняемый приложением Package Installer) отделен от предоставления разрешений (в приложении Permission Controller).

Приложения без интерфейса

Запрашивать разрешения могут только действия. Сервисы не могут запрашивать разрешения напрямую.

  • В Android 5.1 и более ранних версий приложения без интерфейса могут запрашивать разрешения при установке или если они были предустановлены без использования действий.
  • В Android 6.0 и более поздних версий приложения без интерфейса должны использовать один из следующих методов для запроса разрешений:
    • Добавьте задание, чтобы запросить разрешения. (рекомендуемый способ).
    • Передать UID другому приложению, у которого есть необходимые разрешения. Этот метод следует использовать только в том случае, если вам нужно, чтобы платформа обрабатывала несколько APK-файлов как одно приложение.

Цель – не показывать пользователям запросы разрешений, которые не имеют отношения к их действиям.

Как настроить интерфейс PackageInstaller

При необходимости вы можете настроить тему интерфейса разрешений, изменив темы устройства по умолчанию (Theme.DeviceDefault.Settings и Theme.DeviceDefault.Light.Dialog.NoActionBar), которые использует установщик пакетов. Однако для разработчиков приложений очень важна согласованность, поэтому вы не можете настраивать место размещения, положение и правила показа интерфейса запроса разрешений.

Чтобы добавить строки для других языков, отправьте их в AOSP.

Как создавать исключения

Вы можете заранее предоставить разрешения приложениям, которые по умолчанию обрабатывают или предоставляют основные функции ОС, используя класс DefaultPermissionGrantPolicy.java в PackageManager. Примеры:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone

SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

Установка специальных разрешений

Вы можете задавать специальные разрешения и группы как обычные или опасные, а также добавлять разрешения для OEM и операторов связи в существующие группы разрешений, как и в Android 5.x и более ранних версиях.

В Android 6.0 и более поздних версий при добавлении нового опасного разрешения оно должно обрабатываться так же, как и другие опасные разрешения (запрашиваться во время выполнения приложения и отзываться пользователями). А именно:

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

Проверка прав доступа

В Android есть тесты Compatibility Test Suite (CTS), которые проверяют, правильно ли отдельные разрешения сопоставлены с группами. Прохождение этих тестов является обязательным требованием для совместимости с CTS в Android 6.0 и более поздних версиях.

Как отозвать разрешения

В Android 13 и более поздних версиях вы можете отзывать предоставленные разрешения на доступ к данным во время выполнения с помощью метода Context.revokeSelfPermissionsOnKill(). Отзыв происходит асинхронно и запускается, когда это безопасно для пользователя. При отзыве разрешения все процессы, запущенные в вызывающем UID, завершаются.

Важно понимать, что отзыв одного разрешения может не отразиться в интерфейсе настроек, поскольку разрешения там сгруппированы. Как правило, группа разрешений отображается как предоставленная, если предоставлено хотя бы одно разрешение в этой группе. Если вам важно, чтобы пользователи могли подтвердить отзыв в настройках, отзовите все разрешения в группе разрешений. Чтобы узнать, какие разрешения относятся к определенной группе, можно использовать PackageManager.getGroupOfPlatformPermission и PackageManager.getPlatformPermissionsForGroup.

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

Отзыв не запускается, пока процесс остается на переднем плане, но его можно запустить сразу, вручную завершив все процессы, запущенные в текущем uid, например с помощью System.exit(). Однако рекомендуется позволить системе самой определять, когда запускать эту функцию.

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