Google android app permissions

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 запрашивать разрешение, которое не используется приложением, и легко игнорировать эти ошибки при их создании.

Источник

Request app permissions

Every Android app runs in a limited-access sandbox. If your app needs to use resources or information outside of its own sandbox, you can declare a permission and set up a permission request that provides this access. These steps are part of the workflow for using permissions.

If you declare any dangerous permissions, and if your app is installed on a device that runs Android 6.0 (API level 23) or higher, you must request the dangerous permissions at runtime by following the steps in this guide.

If you don’t declare any dangerous permissions, or if your app is installed on a device that runs Android 5.1 (API level 22) or lower, the permissions are automatically granted, and you don’t need to complete any of the remaining steps on this page.

Basic principles

The basic principles for requesting permissions at runtime are as follows:

• Ask for permissions in context, when the user starts to interact with the feature that requires it.
• Don’t block the user. Always provide the option to cancel an educational UI flow related to permissions.
• If the user denies or revokes a permission that a feature needs, gracefully degrade your app so that the user can continue using your app, possibly by disabling the feature that requires the permission.
• Don’t assume any system behavior. For example, don’t assume that permissions appear in the same permission group. A permission group merely helps the system minimize the number of system dialogs that are presented to the user when an app requests closely-related permissions.

Workflow for requesting permissions

Before you declare and request runtime permissions in your app, evaluate whether your app needs to do so. You can fulfill many use cases in your app, such as taking photos, pausing media playback, and displaying relevant ads, without needing to declare any permissions.

If you conclude that your app needs to declare and request runtime permissions, complete these steps:

1. In your app’s manifest file, declare the permissions that your app might need to request.
2. Design your app’s UX so that specific actions in your app are associated with specific runtime permissions. Users should know which actions might require them to grant permission for your app to access private user data.
3. Wait for the user to invoke the task or action in your app that requires access to specific private user data. At that time, your app can request the runtime permission that’s required for accessing that data.

Check whether the user has already granted the runtime permission that your app requires. If so, your app can access the private user data. If not, continue to the next step.

You must check whether you have that permission every time you perform an operation that requires that permission.

Check whether your app should show a rationale to the user, explaining why your app needs the user to grant a particular runtime permission. If the system determines that your app shouldn’t show a rationale, continue to the next step directly, without showing a UI element.

If the system determines that your app should show a rationale, however, present the rationale to the user in a UI element. This rationale should clearly explain what data your app is trying to access, and what benefits the app can provide to the user if they grant the runtime permission. After the user acknowledges the rationale, continue to the next step.

Request the runtime permission that your app requires in order to access the private user data. The system displays a runtime permission prompt, such as the one shown on the permissions overview page.

Check the user’s response, whether they chose to grant or deny the runtime permission.

If the user granted the permission to your app, you can access the private user data. If the user denied the permission instead, gracefully degrade your app experience so that it provides functionality to the user, even without the information that’s protected by that permission.

Figure 1 illustrates the workflow and set of decisions associated with this process:

Figure 1. Diagram that shows the workflow for declaring and requesting runtime permissions on Android.

Determine whether your app was already granted the permission

To check if the user has already granted your app a particular permission, pass that permission into the ContextCompat.checkSelfPermission() method. This method returns either PERMISSION_GRANTED or PERMISSION_DENIED , depending on whether your app has the permission.

Explain why your app needs the permission

If the ContextCompat.checkSelfPermission() method returns PERMISSION_DENIED , call shouldShowRequestPermissionRationale() . If this method returns true , show an educational UI to the user. In this UI, describe why the feature, which the user wants to enable, needs a particular permission.

Additionally, if your app requests a permission related to location, microphone, or camera, consider explaining why your app needs access to this information.

Request permissions

After the user views an educational UI, or the return value of shouldShowRequestPermissionRationale() indicates that you don’t need to show an educational UI this time, request the permission. Users see a system permission dialog, where they can choose whether to grant a particular permission to your app.

Traditionally, you manage a request code yourself as part of the permission request and include this request code in your permission callback logic. Another option is to use the RequestPermission contract, included in an AndroidX library, where you allow the system to manage the permission request code for you. Because using the RequestPermission contract simplifies your logic, it’s recommended that you use it when possible.

Allow the system to manage the permission request code

To allow the system to manage the request code that’s associated with a permissions request, add dependencies on the following libraries in your module’s build.gradle file:

You can then use one of the following classes:

• To request a single permission, use RequestPermission .
• To request multiple permissions at the same time, use RequestMultiplePermissions .

The following steps show how to use the RequestPermission contract. The process is nearly the same for the RequestMultiplePermissions contract.

In your activity or fragment’s initialization logic, pass in an implementation of ActivityResultCallback into a call to registerForActivityResult() . The ActivityResultCallback defines how your app handles the user’s response to the permission request.

Keep a reference to the return value of registerForActivityResult() , which is of type ActivityResultLauncher .

To display the system permissions dialog when necessary, call the launch() method on the instance of ActivityResultLauncher that you saved in the previous step.

After launch() is called, the system permissions dialog appears. When the user makes a choice, the system asynchronously invokes your implementation of ActivityResultCallback , which you defined in the previous step.

Note: Your app cannot customize the dialog that appears when you call launch() . To provide more information or context to the user, change your app’s UI so that it’s easier for users to understand why a feature in your app needs a particular permission. For example, you might change the text in the button that enables the feature.

Also, the text in the system permission dialog references the permission group associated with the permission that you requested. This permission grouping is designed for system ease-of-use, and your app shouldn’t rely on permissions being within or outside of a specific permission group.

The following code snippet shows how to handle the permissions response:

Kotlin

And this code snippet demonstrates the recommended process of checking for a permission, and requesting a permission from the user when necessary:

Kotlin

Manage the permission request code yourself

As an alternative to allowing the system to manage the permission request code, you can manage the permission request code yourself. To do so, include the request code in a call to requestPermissions() .

Note: Your app cannot customize the dialog that appears when you call requestPermissions() . The text in the system permission dialog references a permission group, but this permission grouping is designed for system ease-of-use. Your app shouldn’t rely on permissions being within or outside of a specific permission group.

The following code snippet demonstrates how to request a permission using a request code:

Kotlin

After the user responds to the system permissions dialog, the system then invokes your app’s implementation of onRequestPermissionsResult() . The system passes in the user response to the permission dialog, as well as the request code that you defined, as shown in the following code snippet:

Kotlin

Handle permission denial

If the user denies a permission request, your app should help users understand the implications of denying the permission. In particular, your app should make users aware of the features that don’t work because of the missing permission. When you do so, keep the following best practices in mind:

Guide the user’s attention. Highlight a specific part of your app’s UI where there’s limited functionality because your app doesn’t have the necessary permission. Several examples of what you could do include the following:

• Show a message where the feature’s results or data would have appeared.
• Display a different button that contains an error icon and color.

Be specific. Don’t display a generic message; instead, mention which features are unavailable because your app doesn’t have the necessary permission.

Don’t block the user interface. In other words, don’t display a full-screen warning message that prevents users from continuing to use your app at all.

At the same time, your app should respect the user’s decision to deny a permission. Starting in Android 11 (API level 30), if the user taps Deny for a specific permission more than once during your app’s lifetime of installation on a device, the user doesn’t see the system permissions dialog if your app requests that permission again. The user’s action implies «don’t ask again.» On previous versions, users would see the system permissions dialog each time your app requested a permission, unless the user had previously selected a «don’t ask again» checkbox or option.

In certain situations, the permission might be denied automatically, without the user taking any action. (Similarly, a permission might be granted automatically as well.) It’s important to not assume anything about automatic behavior. Each time your app needs to access functionality that requires a permission, you should check that your app is still granted that permission.

To provide the best user experience when asking for app permissions, also see App permissions best practices.

One-time permissions

Starting in Android 11 (API level 30), whenever your app requests a permission related to location, microphone, or camera, the user-facing permissions dialog contains an option called Only this time, as shown in Figure 2. If the user selects this option in the dialog, your app is granted a temporary one-time permission.

Your app can then access the related data for a period of time that depends on your app’s behavior and the user’s actions:

• While your app’s activity is visible, your app can access the data.
• If the user sends your app to the background, your app can continue to access the data for a short period of time.
• If you launch a foreground service while the activity is visible, and the user then moves your app to the background, your app can continue to access the data until that foreground service stops.
• If the user revokes the one-time permission, such as in system settings, your app cannot access the data, regardless of whether you launched a foreground service. As with any permission, if the user revokes your app’s one-time permission, your app’s process terminates.

When the user next opens your app and a feature in your app requests access to location, microphone, or camera, the user is prompted for the permission again.

Android auto-resets permissions of unused apps

If your app targets Android 11 (API level 30) or higher and isn’t used for a few months, the system protects user data by automatically resetting the sensitive runtime permissions that the user had granted your app. Learn more in the guide about app hibernation.

Request to become the default handler if necessary

Some apps depend on access to sensitive user information related to call logs and SMS messages. If you want to request the permissions specific to call logs and SMS messages and publish your app to the Play Store, you must prompt the user to set your app as the default handler for a core system function before requesting these runtime permissions.

For more information on default handlers, including guidance on showing a default handler prompt to users, see the guide on permissions used only in default handlers.

Grant all runtime permissions for testing purposes

To grant all runtime permissions automatically when you install an app on an emulator or test device, use the -g option for the adb shell install command, as demonstrated in the following code snippet:

Additional resources

For additional information about permissions, read these articles:

To learn more about requesting permissions, download the following sample apps:

• Android RuntimePermissionsBasic Sample Java | Kotlin

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник