Android app permission setting

App Permissions в Android – что это и как его использовать

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

Зачем необходим App Permissions на Android и как его удалить.

Что это такое

App Permissions – это и есть разрешения. Когда вы устанавливаете софт из Google Play на устройстве под управлением Android 6.0 или выше, вы контролируете, к каким возможностям или информации может обращаться программа – так называемые разрешения. Например, утилите может потребоваться разрешение на просмотр контактов или местоположения вашего устройства. Вы можете контролировать, к каким разрешениям ПО сможет получить доступ после установки на устройстве. И если «Автоматический запуск программы при загрузке» говорит само за себя, то разобраться в остальных может быть не так просто. Проблема в том, что программы могут иметь веские основания для их использования, потому что одним разрешением может быть охвачено несколько разных вещей. Рассмотрим самые распространённые примеры менеджмента разрешений более подробно.

Совершать и принимать вызовы

Это означает, что ПО может автоматически сделать звонок. Каждая утилита может самостоятельно запускать номеронабиратель и даже вводить номер, но, если это разрешение не предоставлено, пользователю нужно нажать кнопку вызова. Такие вещи, как сторонний номеронабиратель, Google Voice или всё, что связано с вашей телефонной «звонилкой», должно иметь это разрешение. Если ПО его запрашивает, но не должно иметь ничего общего с совершением звонков, отклоните запрос и выясните причину запроса у разработчиков через отзывы на Google Play. Даже если причины использования того или иного разрешения вам не понятны, они могут требоваться для стабильной работы программ.

Получение и отправка SMS или MMS

Подписные SMS-сервисы – лёгкий способ для мошенника заработать деньги, так что за ними нужно следить. Доступ понадобится SMS-приложениям (что очевидно), а также утилитам, которые позволяют редактировать или делать снимки, а также делиться ими. Программы, которые могут совместно использовать любые медиа, скорее всего будут иметь эту настройку. Если софт не может никому ничего отправлять, следует проверить, зачем это нужно разработчикам.

Чтение/запись контактов

Почтовый клиент или мессенджер любого типа использует это разрешение, чтобы делать именно то, о чём говорит его название – читать ваши контакты. Например, Twitter или Facebook – они хотят иметь возможность находить ваших друзей, которые также пользуются их услугами, или упростить для вас рассылку спама тем, кто этого не делает. «Контакты» – это широкий термин, потому что в отдельном контакте может храниться много различной информации. Например, в играх, где также есть списки лидеров. Всё, что может связать вас с другим пользователем, будет нуждаться в этом разрешении. Права на сохранение контактов следует той же логике – если утилита может добавить контакт, ей может потребоваться это разрешение. В этом случае «записать» означает изменить или добавить в список контактов, а не написать сообщение.

Чтение/запись событий календаря

Здесь всё довольно просто. Настройка позволяет делать только одно – автоматически читать календарь. Некоторые утилиты должны иметь доступ к календарю. Это программы, которые могут напоминать о приёме лекарств или автоматически сообщать о предстоящей поездке, считывая данные из календаря. Если программа каким-либо образом связана с планированием, то использование такого доступа вполне оправдано. Если это не так, перед установкой выясните, зачем приложению нужен доступ к календарю. Запись событий календаря является обычным делом. Если неясно, зачем программе нужны эти настройки, описание в магазине Play должно рассказать вам больше. Если вы все ещё не уверены, спросите разработчика.

Phone Status And Identity

Это наиболее распространённое и наименее понятное разрешение из всех. Вы должны понимать, что оно распространяется на две разные вещи, которые не следует путать. Есть много веских причин, чтобы узнать состояние вашего телефона. И игра является отличным примером. Вы можете заниматься своим делом и играть в игру, когда внезапно зазвонит ваш телефон. Игра должна вернуться на главный экран и позволить уведомлению о входящем звонке появиться сверху остальных окон. После этого вызов полностью берёт управление телефоном на себя, но игра должна об этом знать/ Это необходимо для того, чтобы продолжить работу в фоновом режиме, пока вы не закончите разговор.

Важно знать, какой идентификатор запрашивает программа. Каждый телефон имеет идентификатор устройства, который отличается от любого другого, и его можно раскрыть, не передавая никакой личной информации. Когда вы видите, сколько людей используют определённую версию Android на графике от Google, они используют этот идентификатор устройства, чтобы помочь получить эти цифры. Когда вы заходите в Google Play и скачиваете программу, вас подсчитывают, и при этом только один раз. Идентификатор смартфона также является лучшим способом для синхронизации облачных данных и настроек ПО со смартфоном. Разрешение указывает только на то, какой у вас телефон и какое на нём программное обеспечение, поэтому ваши данные не будут доступны.

Разрешение также позволяет прочитать другой уникальный идентификатор – IMEI. Номер IMEI – это то, как телефонная компания подключает телефон – ваш адрес, ваше имя и всё остальное, что вам нужно будет предоставить, чтобы купить телефон, который сможет доказать, кто вы. Эти данные трудно получить – между ними и любыми данными вашей учётной записи есть минимум три разных защищённых и зашифрованных сервера базы данных, но получить доступ к ним не невозможно. Поскольку у вас нет возможности узнать, какой идентификатор требует приложение, выберите «Нет», если не знаете, почему разработчики этого хотят и что они с ним делают.

GPS и сетевое местоположение

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

Изменять/Удалять содержимое SD-карты

Это разрешение, которое позволяет приложению читать или записывать данные на внешнюю память смартфона. Необходимо, чтобы дать приложению возможность свободно просматривать данные, изменять их, удалять и добавлять дополнительную информацию данные в любое место на SD-карте. Сбивает с толку тот факт, что под SD-картой подразумевается не только флешка. В файловой системе Android память телефона также называется SD-картой. Google многое сделал, чтобы сделать это разрешение безвредным. В каждой версии они уточняют, как приложение может получить доступ только к той информации, которая ему нужна. Но все ещё есть пользователи, использующие старые версии программ и ОС. Если вы один из них, убедитесь, что вы доверяете приложению, прежде чем устанавливать его. Любое приложение, написанное для API уровня 4 (Android 1.6 Donut) или ниже, получает это разрешение по умолчанию. Таких приложений не так много. Какой вред это может принести, зависит от того, какие данные хранятся в памяти вашего телефона. Телефоны под управлением Android 7 Nougat и приложения, созданные для телефонов под управлением Android 7, используют доступ к каталогу в заданной области, что гораздо удобнее и безопаснее.

Полный доступ к сети

Это разрешение означает именно то, что оно говорит. Приложение хочет иметь возможность отправлять запросы и получать ответ через сеть (Wi-Fi или подключение для передачи данных по мобильной сети). Помимо приложений, которые используют Интернет для чего-то очевидного, в них нуждаются в этом приложения с рекламой. Разрешение довольно безвредное, но, когда речь заходит о вашей личной информации, оно может использовать данные без вашего ведома. Мы ненавидим платить за дополнительные данные так же, как и вы. Если вы найдёте приложение, которое должно работать в автономном режиме, но не работает, удалите его.

Как удалить App Permissions

Чтобы найти свои приложения и их разрешения на Android, откройте «Настройки», а затем нажмите «Приложения и уведомления», «Информация о приложении» и выберите интересующее вас приложение. Выберите пункт «Разрешения», чтобы просмотреть, какими из них обладает приложение. Вы можете отключить любое из них в любое время, передвинув переключатель рядом с этой записью. Другой вариант – просматривать по разрешению, а не по приложению. Откройте «Настройки» и перейдите в раздел «Приложения и уведомления», как и в предыдущем случае. Но на этот раз выберите «Разрешения приложения». Откроется список разрешений, который включает датчики, календарь, камеру, контакты, местоположение, микрофон, SMS, память, телефон и многое другое. Нажмите любую запись, чтобы увидеть, какие приложения могут получить доступ к этой функции. Здесь также с помощью переключателей можно убрать любые настройки. Прежде чем начинать отключать разрешения, помните, что для выполнения своей работы некоторые приложения полагаются на этот доступ. Например, если приложение может просматривать ваши контакты, оно использует их, чтобы помочь вам обмениваться контентом, файлами или приглашать друзей на мероприятия, а не собирать ваши данные для получения прибыли.

Разрешения при загрузке софта

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

1. Откройте приложение Play Store.
2. Перейти на страницу сведений о приложении. Чтобы просмотреть разрешения перед установкой, пролистайте до раздела «Разработчик» и нажмите «Сведения о разрешениях».
3. Нажмите «Установить».

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

Если приложение уже установлено

Для приложений, созданных для Android 6.0 и выше, просматривать или принимать изменения разрешений при каждом обновлении не нужно. Достаточно указать необходимые права при первом запуске программы. Если при обновлении приложению требуется доступ к новым группам разрешений или разрешениям в группе «Другие», вам будет предложено заново подтвердить решение, даже если вы настроили автоматические обновления. Если вы предпочитаете просматривать каждое обновление вручную, вы можете отключить автоматическое обновление, следуя приведённым ниже инструкциям:

1. Откройте приложение Play Store.
2. Нажмите кнопку Меню – Мои приложения и игры – Установленные.
3. Выберите приложение.
4. Нажмите Больше (вертикальная линия из 3-х точек).
5. Снимите флажок «Автообновление», если он ещё не снят.

Чтобы отключить автообновление для всех приложений:

1. Откройте приложение Play Store.
2. Нажмите кнопку Меню – Настройки – Автообновление приложений – Никогда не обновлять автоматически.

Есть также много других, менее подозрительных разрешений. Приложение, которое делает снимки, должно контролировать ваше оборудование. Netflix должен держать ваш экран активным в течение всего времени, пока вы его не касаетесь. Виджет профиля звонков нуждается в доступе к вашим настройкам. Разобраться с разрешением, которое кажется неуместным, обычно помогает немного логики. Если нет, то читайте комментарии в Google Play и задавайте вопросы на форумах. Большинство приложений в Google Play не могут украсть ваши данные или ваши деньги. Помните, что большинство людей, пишущих приложения, просто хотят заработать немного денег или делают это ради удовольствия. Приложений, которые существуют для обработки ваших данных, не так много. Но иногда разработчики допускают ошибку – нетрудно заставить Android запрашивать разрешение, которое не используется приложением, и легко игнорировать эти ошибки при их создании.

Источник

Android permissions for system developers

This document targets system developers. App developers should refer to the public documentation.

Definitions

Each app (often called package) has a unique name called package name. Each package has a manifest file describing properties of the package. The android system server is in a special package named “android”.

When a package gets installed the package is (usually) assigned a unique identifier called uid . This is the same as a uid in Linux, but this often leads to confusion. It is easiest to see a uid as a unique identifier for a package.

Usually an app is running in a container called a process. Each process has a unique id called pid, but unlike the uid the pid changes each time the process is restarted and app that are not currently running don’t have a pid. The process container makes sure that other apps cannot negatively interact with an app. Processes can only interact via controlled interactions called remote procedure calls (RPCs). Android’s RPC mechanism is called Binder.

As no app code can be trusted the permission need to be checked on the receiving side of the Binder call.

For more details please take a look at Android’s security model.

Permissions for regular apps

Install time permissions

The purpose of install time permissions is to control access to APIs where it does not makes sense to involve the user. This can be either because the API is not sensitive, or because additional checks exist.

Another benefit of install time permissions is that is becomes very easy to monitor which apps can access certain APIs. E.g. by checking which apps have the android.permission.INTERNET permission you can list all apps that are allowed to use APIs that can send data to the internet.

Defining a permission

Any package can define a permission. For that it simply adds an entry in the manifest file

Any package can do this, including the system package. When talking about permissions for system apps we will see that it is important which package defines a permission.

It is common good practice to prefix the permission name with the package name to avoid collisions.

Requesting a permission

Any app can request any permission via adding an entry in the manifest file like

A requested permission does not necessarily mean that the permission is granted. When and how a permission is granted depends on the protection level of the permission. If no protection level is set, the permission will always be granted. Such “normal” permissions can still be useful as it will be easy to find apps using a certain functionality on app stores and by checking dumpsys package .

Checking a permission

Context.checkPermission(permission, pid, uid) returns if the pid/uid has the permission. By far the most common case is to check the permission on the receiving end of a binder call. In this case the pid can be read as Binder.callingPid() and the uid as Binder.callingUid() . The uid is a mandatory argument as permissions are maintained per uid. The pid can be set to -1 if not pid is available. The context class contains handy wrappers for checkPermission , such as enforeCallingPermission which calls checkPermission with Binder.callingPid / Binder.callingUid and throws a SecurityException when the permission is not granted.

Verifying an app has an install time permission

In dumpsys package my.package.name there are two sections. In requested permissions all permissions of the uses-permission tags are listed. In install permission the permissions with their grant state are listed. If an install time permission is not listed here, it is not granted.

End-to-end: Protecting an RPC call via a permission

Service Manifest

Service code

Caller Manifest

Runtime permissions

Runtime permission must be granted by the user during runtime. This is needed if the API protects data or functionality that is sensitive for the user. E.g. the users current location is protected by a runtime permission.

Users want a system that is secure and privacy focused by default. User can also often not make a good choice when asked at the wrong time without enough context. Hence in general runtime permissions should be avoided and the API should be built in a way where no private data needs to be leaked.

Defining a runtime permission

Runtime permissions are defined in the same way as install time permissions. To tag them as runtime permissions the protectionLevel needs to be set to dangerous. Dangerous is a synonym for runtime permissions in the Android platform.

Requesting a runtime permission

Similar to install time permissions any app can request a runtime permission by adding the to the manifest.

By default runtime permissions are not granted. The app needs to call Activity.requestPermissions during runtime to ask the user for the permission. The user might then grant or deny and once the decision is made the activity is called by via Activity.onPermissionGranted .

During development and testing a runtime permission can be granted via the pm shell command or by using the UiAutomator.grantRuntimePermission API call. Please note that this does not grant the app-op synchronously. Unless the app needs to test the actual permission grant flow it is recommended to grant the runtime permissions during install using adb install -g /my/package.apk .

Checking a runtime permission

For runtime permissions defined by 3rd party apps it is fine to check a runtime permission like an install time permission. For system defined permissions you need to check all runtime permissions by using the PermissionChecker utility. It is good practice to use the tool anywhere possible.

The permission checker might return PERMISSION_DENIED_APP_OP which should lead to a silent failure. This can only happen for system defined runtime permissions.

Runtime permissions and app-ops

The PermissionChecker code fundamentally looks like this:

For each platform defined runtime permission there is a matching app-op. When calling AppOpsManager.noteOp this returns either MODE_ALLOWED or MODE_IGNORED .

This value is then used to decide between PERMISSION_DENIED_APP_OP and PERMISSION_GRANTED .

The primary purpose of the special PERMISSION_DENIED_APP_OP state was to support apps targeting an SDK lower than 23. These apps do not understand the concept of denied runtime permissions. Hence they would crash when getting a SecurityException . To protect the users’ privacy while still not crashing the app the special PERMISSION_DENIED_APP_OP mandates that the API should somehow silently fail.

A secondary use case of the AppOpsManager.noteOp calls is to track which apps perform what runtime protected actions.

Verifying an app has a runtime time permission

In dumpsys package my.package.name the runtime permissions are listed per uid. I.e. different users might have different runtime permission grants and shared uids share a grant-set. If a runtime permission is listed as requested but not in the runtime permission section it is in its initial state, i.e. not granted.

End-to-end: Protecting an RPC call via a runtime permission

Service Manifest

Service code

Caller Manifest

Caller code

Restricted permissions

Some runtime permissions are restricted. They are annotated in the platforms AndroidManifest.xml as hardRestricted or softRestricted .

Restricted permissions behave uncommon when not whitelisted. When whitelisted the permissions behave normally. What uncommon means depends on the whether they are hard or soft restricted.

They can either be whitelisted during upgrade P->Q by the system or need to be whitelisted by the installer via PackageInstaller.SessionParams.setWhitelistedRestrictedPermissions . If this method is not used all permissions will be whitelisted.

Afterwards the app that originally installed the app can change the whitelisting state via PackageManager.addWhitelistedRestrictedPermission and PackageManager.removeWhitelistedRestrictedPermission .

The system tracks the source of the whitelisting by having three different flags RESTRICTION_SYSTEM_EXEMPT , RESTRICTION_UPGRADE_EXEMPT , and RESTRICTION_INSTALLER_EXEMPT ,

The flags can be checked in dumpsys package my.package.name

Hard restricted

Hard restricted permissions need to be whitelisted to be grant-able.

Soft restricted

The behavior of non-whitelisted soft restricted permissions is not uniform. The behavior is defined in the SoftRestrictedPermissionPolicy .

System fixed permission

Some runtime permissions are required for normal operation of the device. In this case the system can grant the permission as SYSTEM_FIXED . In this case the permission can be seen in the permission management settings but cannot be revoked by the user.

The flag can be checked in dumpsys package my.package.name

Background access

Whether the app is currently visible to the user is reflected in the ActivityManager ‘s proc state. There is a lot of granularity to this, but runtime permissions are using the app-ops services’ definition of foreground and background.

Most runtime permissions are not affected by foreground/background-ness. Microphone and Camera are foreground-only while Location is usually foreground-only, but background access can be added by granting the ACCESS_BACKGROUND_LOCATION modifier runtime permission.

Microphone and Camera

Currently these only allow access while the app is in foreground. There is a manual whitelist for e.g. the voice interaction service.

This is currently (Mar 2020) reworked and will behave like location soon.

Location

As described above the app-op mode for granted permissions is MODE_ALLOWED to allow access or MODE_IGNORED to suppress access.

The important case is the case where the permission is granted and the app-op is MODE_IGNORED . In the case of location this state causes the LocationManagerService to stop delivering locations to the app. This is not a breaking behavior as the same scenario happens if e.g. no satellites could be found.

This behavior is used to implement the foregound/background behavior for location. If the app is in the foreground the app-op mode is MODE_ALLOWED and works normally. If the app goes into background the app-op mode changes to MODE_IGNORED . This means that locations are delivered while the app is in foreground and while the app is background, the app won’t get any locations.

The automatic switching between MODE_ALLOWED and MODE_IGNORED is done inside of AppOpsManager .

Background access can be enabled by also granting the ACCESS_BACKGROUND_LOCATION to the app. In this case the app-op mode will always be MODE_ALLOWED .

Granting

An app following the best practices does not ask for any runtime permissions until absolutely needed. Once needed the request should be made in context. I.e. the user should understand from the current state of the app and the user’s action why the request is made. E.g. if the user presses a “show me the next ATM”-button the user is most likely expecting a request for the location permission.

This is central premise to the runtime permission UI. It is the app’s responsibility to avoid showing permission requests dialogs to the user which might get denied. These dialogs are not meant to be user-choices, they are meant to be user-confirmations.

Hence any denied permission dialog is probably due to the app asking for permissions the user does not expect. If too many permission requests get denied the app is apparently trying to get more than the user wants to give to the app. In this case the permission gets permanently denied and all future requests will be denied automatically without showing a UI.

Context.requestPermission calls for more than one permission are allowed and might result in multiple dialogs in sequence. This might make sense for e.g. getting microphone and camera permission when starting a video call.

Each time the the user makes a choice (either to grant or the deny) a permission request the permission is marked as USER_SET . If a permission gets permanently denied the permission is marked as USER_FIXED .

This can be found in dumpsys package my.package.name

Settings

By far most interactions with the permission system are via the permission grant flow. The main purpose of the permission settings is to show the user the previous choices and allow the user to revisit previous choices. In reality few users do that.

Grouping

There are too many runtime permissions for the user to individually manage. Hence the UI bundles the permissions into groups. Apps should never assume the grouping. The grouping might change with SDK updates, but also at any other time. Certain form factors or locales might use other permission models and sometimes some of the permissions of a group cannot be granted for various reasons. The grouping is defined inside the permission controller app.

If two permissions belong to a group and the first permission is already granted the second one will be granted on request of the app without user interaction. For that reason a permission group with at least one individual permission granted will show up as granted in the UI.

Alternate permission management

It is not allowed to build alternate permission management UIs. While restricting innovation is not a good choice this is a required one to enforce a consistent, predictable, but flexible permission model for users and app developers.

Further some data needed for permission management (e.g. the grouping) is not available outside the permission controller app.

Hence all permission management UI needs to be integrated with AOSP.

Pre granting

Runtime permissions protect user private data. It is a violation of user trust to give the data to an app without explicit user consent (i.e. the user granting the permission). Still the user expects certain functionality (e.g. receiving a phone call) to work out of the box.

Hence the DefaultPermissionGrantPolicy and roles allow to grant permission without the user . The default permission grant policy grants permissions for three categories of apps

• Apps running in well defined uids as they are considered as part of the platform
• Apps that are in certain predefined categories, e.g. the browser and the SMS app. This is meant for the most basic phone functionality, not for all pre-installed apps.
• Apps that are explicitly mentioned as pre-grant-exceptions. This is meant to be used for setup and other highly critical use cases, not to improve the user experience. The exceptions are listed in xml files in etc/ and follow the following syntax

Pre-granted runtime permissions can still be revoked by the user in settings unless they are granted as SYSTEM_FIXED .

Whether a permission was granted by the default can be checked in the permission flags of dumpsys package my.package.name

Permission restricted components

As publicly documented it is possible to restrict starting an activity/binding to a service by using permission.

It is a common pattern to

• define a permission in the platform as signature
• protect a service in an app by this permission using the android:permission attribute of the tag

Then it is guaranteed that only the system can bind to such service. This is used for services that provide extensions to platform functionality, such as auto-fill services, print services, and accessibility services.

This does not work for app-op or runtime permissions as the way to check these permissions is more complex than install time permissions.

End-to-end A service only the system can bind to

Make sure to set the android:permission flag for this service. As developers can forget this it is a good habit to check this before binding to the service. This makes sure that the services are implemented correctly and no random app can bind to the service.

The result is that the permission is granted only to the system. It is not granted to the service’s package, but this has no negative side-effects.

Permission definition

Service definition

Manifest of the service providing the functionality:

System server code binding to service

Permissions for system apps

System apps need to integrate deeper with the system than regular apps. Hence they need to be able to call APIs not available to other apps. This is implemented by granting permissions to these system apps and then enforcing the permissions in the API similar to other install time permissions.

System apps are not different from regular apps, but the protection levels (e.g. privileged, preinstalled) mentioned in this section are more commonly used by system apps.

Multiple permission levels

It is possible to assign multiple protection levels to a permission. Very common combinations are for example adding signature to all permissions to make sure the platform signed apps can be granted the permission, e.g. privileged|signature .

The permission will be granted if the app qualifies for any of the permission levels.

App-op permissions

App-op permissions are user-switchable permissions that are not runtime permissions. This should be used for permissions that are really only meant to be ever granted to a very small amount of apps. Traditionally granting these permissions is intentionally very heavy weight so that the user really needs to understand the use case. For example one use case is the INTERACT_ACROSS_PROFILES permission that allows apps of different users within the same profile group to interact. Of course this is breaking a very basic security container and hence should only ever be granted with a lot of care.

Warning: Most app-op permissions follow this logic, but most of them also have exceptions and special behavior. Hence this section is a guideline, not a rule.

Defining an app-op permission

Only the platform can reasonably define an app-op permission. The permission is defined in the platforms manifest using the appop protection level

Almost always the protection level is app-op | something else, like signature (in the case above) or privileged.

Checking an app-op permission

The PermissionChecker utility can check app-op permissions with the same syntax as runtime permissions.

The permission checker internally follows this flow

Granting an app-op permission

The permission‘s grant state is only considered if the app-op’s mode is MODE_DEFAULT . This allows to have default grants while still being overridden by the app-op.

The permission is then granted by setting the app-op mode. This is usually done via dedicated APIs for each use case. Similarly whether and how an app can request the permission is different for each app-op permission.

When implementing a new app-op permission, make sure to set the app-op mode using AppOpsManager.setUidMode to make sure the permission is granted on the uid as this is the security domain.

During development app-ops can be grated to app via the appops set shell command. E.g.

sets the INTERACT_ACROSS_PROFILES app-op for uid 10187 to allow thereby granting apps in this uid the ability to interact across profiles.

Most UIs for app-op permissions are in the “Special app access” section of the settings app.

In most cases the permission should only be granted with the user’s explicit agreement, usually by allowing the app to directly open the “Special app access” page for this permission and app.

To repeat: this is a guideline for app-op permissions and there are many exceptions.

Signature permissions

Only apps signed with the defining app’s certificate will be granted the permission. This is used to restrict APIs to apps of the same developer.

This is frequently used to restrict permissions defined by the platform to apps also signed with the platform’s certificate. As this is a very tight restriction this is recommended for permissions that are only used by apps built out of AOSP which are signed with the platform certificate.

Please note that OEMs sign their platform themselves. I.e. OEMs can implement new apps using these permissions. It is unlikely that 3rd party apps will be able to use APIs protected by signature permissions as they are usually not signed with the platform certificate.

If possible, role protected permissions should also be considered as an alternative to better restrict which apps may get the permission.

Such permissions are defined and checked like an install time permission.

Preinstalled permissions

This means that the app has to be pre-installed. There is no restriction what apps are pre-installed on a particular device install there. Hence it can be really any app including 3rd party apps.

Hence this permission level is discouraged unless there are further restrictions.

If possible, role protected permissions should also be considered as an alternative to better restrict which apps may get the permission.

Such permissions are defined and checked like an install time permission.

Privileged permissions

This means that the app has to be pre-installed and in the system/priv directory in the filesystem. There is no restriction what apps are in this directory on a particular device. Hence it can be really any app including 3rd party apps.

An app is only ever granted privileged permissions requested by the pre-installed apk. I.e. privileged permissions added in updates will never be granted.

Hence this permission level is discouraged unless there are further restrictions.

If possible, role protected permissions should also be considered as an alternative to better restrict which apps may get the permission.

Such permissions are defined and checked like an install time permission.

Restricted by tests

As all apps that might get preinstalled or privilidged permissions need to be pre-installed and new images need to pass compliance tests it is possible to use a test to whitelist the apps that can request the permission.

Example of such a test:

Whitelist

As mentioned above it is not suggested, but still common practice to install 3rd party apps as privileged. To verify and restrict which privileged permissions those apps get granted all privileged permissions need to be explicitly whitelisted in a file /etc .

If the pre-installed apk of an app requests a privileged permission that is not mentioned in any whitelist or that is not denied the system will refuse to boot. As mentioned above privileged permissions added in updates to the pre-installed app will never be granted.

Limited permissions

E.g. installer, wellbeing, documenter, etc. This allows the system to restrict the permission to a well defined app or set of apps. It is possible to add new types in PackageManagerService .

Which apps qualify for such a permission level is flexible and custom for each such level. Usually they refer to a single or small set of apps, usually — but not always — apps defined in AOSP.

This type of permission is deprecated in favor of role protected permissions.

These permissions are defined and checked like an install time permission.

Role protected permissions

Development permissions

By adding the development protection level to any permissions the permission can be granted via the pm grant shell command. This appears to be useful for development and testing, but it is very highly discouraged. Any user can grant them permanently via adb, hence adding this tag removes all guarantees the permission might otherwise provide.

Other protection levels

There are other levels (such as runtime ) but they are for special purposes on should not be used by platform developers.

Источник