Разрешения во время выполнения

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

  • Разрешения во время установки

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

  • Разрешения во время выполнения

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

    ( Android 10 ) Пользователи видят повышенную прозрачность и могут контролировать, какие приложения имеют разрешения на выполнение распознавания активности (AR). В диалоговом окне разрешений среды выполнения пользователям предлагается либо всегда разрешать, разрешать во время использования или запрещать разрешения. При обновлении ОС до 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 Store) может исключить из белого списка ограниченные разрешения для приложения. Разрешения ограничены платформой и предоставляются только в том случае, если приложение соответствует особым критериям политики платформы. Примеры жестко ограниченных типов разрешений включают разрешения на SMS и журнал вызовов.

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

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

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

Требования

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

  • Модель разрешений во время выполнения должна быть единообразной на всех устройствах под управлением Android 6.0 и более поздних версий. Это обеспечивается тестами Android Compatibility Test Suite (CTS).
  • Приложения должны предлагать пользователям предоставить разрешения приложению во время выполнения. Подробную информацию см. в разделе Обновление приложений . Ограниченные исключения могут быть предоставлены приложениям и обработчикам по умолчанию, которые обеспечивают базовые функциональные возможности устройства, необходимые для ожидаемой работы устройства. (Например, приложение Dialer по умолчанию для обработки 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 ), используемые PackageInstaller. Однако, поскольку согласованность имеет решающее значение для разработчиков приложений, вы не можете настроить размещение, положение и правила отображения пользовательского интерфейса разрешений.

Чтобы включить строки для дополнительных языков, добавьте их в 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), которые проверяют, сопоставлены ли отдельные разрешения правильным группам. Прохождение этих тестов является обязательным условием для совместимости с Android 6.0 и более поздних версий CTS.

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

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

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

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

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

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