Определите пользовательское разрешение приложения

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

Фон

Android — это операционная система с разделением привилегий, в которой каждое приложение запускается с отдельным идентификатором системы (идентификатор пользователя Linux и идентификатор группы). Части системы также разделены на отдельные идентичности. Таким образом, Linux изолирует приложения друг от друга и от системы.

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

Подписание приложения

Все APK-файлы должны быть подписаны сертификатом , закрытый ключ которого хранится у их разработчика. Сертификат не обязательно должен быть подписан центром сертификации. Для приложений Android допустимо и типично использовать самозаверяющие сертификаты. Целью сертификатов в Android является различение авторов приложений. Это позволяет системе предоставлять или запрещать приложениям доступ к разрешениям на уровне подписи , а также разрешать или отклонять запрос приложения на предоставление того же идентификатора Linux, что и другое приложение.

Предоставление разрешений на подпись после изготовления устройства

Начиная с Android 12 (уровень API 31), knownCerts для разрешений уровня подписи позволяет ссылаться на дайджесты известных сертификатов подписи во время объявления.

Вы можете объявить knownCerts и использовать knownSigner в атрибуте protectionLevel вашего приложения для определенного разрешения на уровне подписи. Затем система предоставляет это разрешение запрашивающему приложению, если какая-либо подписывающая сторона в линии подписи запрашивающего приложения, включая текущую подписывающую сторону, соответствует одному из дайджестов, объявленных с разрешением в knownCerts .

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

Идентификаторы пользователей и доступ к файлам

Во время установки Android присваивает каждому пакету отдельный идентификатор пользователя Linux. Идентификация остается неизменной на протяжении всего срока службы пакета на этом устройстве. На другом устройстве тот же пакет может иметь другой UID — важно, чтобы каждый пакет имел отдельный UID на данном устройстве.

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

Любым данным, хранящимся в приложении, присваивается идентификатор пользователя этого приложения и обычно они недоступны для других пакетов.

Дополнительные сведения о модели безопасности Android см. в разделе Обзор безопасности Android .

Определение и применение разрешений

Чтобы обеспечить соблюдение собственных разрешений, вы должны сначала объявить их в файле AndroidManifest.xml используя один или несколько элементов <permission> .

Соглашение об именах

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

Мы рекомендуем добавлять к разрешениям префикс имени пакета приложения, используя именование в стиле обратного домена, за которым следует .permission. а затем описание возможности, которую представляет это разрешение, в верхнем SNAKE_CASE. Например, com.example.myapp.permission.ENGAGE_HYPERSPACE .

Следование этой рекомендации позволяет избежать конфликтов имен и помогает четко определить владельца и назначение специального разрешения.

Пример

Например, приложение, которому необходимо контролировать, какие другие приложения могут запускать одно из его действий, может объявить разрешение на эту операцию следующим образом:

<manifest
  xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.example.myapp" >
    
    <permission
      android:name="com.example.myapp.permission.DEADLY_ACTIVITY"
      android:label="@string/permlab_deadlyActivity"
      android:description="@string/permdesc_deadlyActivity"
      android:permissionGroup="android.permission-group.COST_MONEY"
      android:protectionLevel="dangerous" />
    ...
</manifest>

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

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

Вам необходимо предоставить как метку, так и описание разрешения. Это строковые ресурсы, которые пользователь может видеть, просматривая список разрешений ( android:label ) или сведения об одном разрешении ( android:description ). Ярлык короткий: несколько слов, описывающих ключевую часть функциональности, которую защищает разрешение. Описание представляет собой пару предложений, описывающих, что разрешение позволяет делать владельцу. Наше соглашение представляет собой описание из двух предложений, где первое предложение описывает разрешение, а второе предложение предупреждает пользователя о том, что может пойти не так, если приложению будет предоставлено разрешение.

Вот пример метки и описания разрешения CALL_PHONE :

<string name="permlab_callPhone">directly call phone numbers</string>
<string name="permdesc_callPhone">Allows the app to call non-emergency
phone numbers without your intervention. Malicious apps may cause unexpected
calls on your phone bill.</string>

Создать группу разрешений

Как показано в предыдущем разделе, вы можете использовать атрибут android:permissionGroup , чтобы помочь системе описать разрешения для пользователя. В большинстве случаев вы устанавливаете стандартную системную группу (перечисленную в android.Manifest.permission_group ), но вы также можете определить свою собственную группу с помощью <permission-group> .

Элемент <permission-group> определяет метку для набора разрешений — как объявленных в манифесте с помощью элементов <permission> , так и объявленных где-либо еще. Это влияет только на то, как разрешения группируются при представлении пользователю. Элемент <permission-group> не определяет разрешения, принадлежащие группе, но дает группе имя.

Вы можете поместить разрешение в группу, присвоив имя группы атрибуту permissionGroup элемента <permission> .

Элемент <permission-tree> объявляет пространство имен для группы разрешений, определенных в коде.

Рекомендации по пользовательским разрешениям

Вы можете определить специальные разрешения для своих приложений и запросить специальные разрешения у других приложений, определив элементы <uses-permission> . Однако тщательно оцените, необходимо ли это делать.

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

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