Если приложение хочет получить доступ к операционной системе и устройству — у него на это должны быть разрешения от пользователя. Это сделано для того, чтобы защитить юзера от злоумышленников и дать понять что именно программа хочет использовать.
Разработчик должен «публично» в AndroidManifest.xml объявить какие разрешения требуется его программе. По сути даже использовать интернет без ведомо пользователя не получится. Для этого нужно объявить необходимое разрешение:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.package">
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<application ...>
...
</application>
</manifest>Типы разрешений для приложений в Android
Сами разрешения бывают двух типов, normal и dangerous. «Обычные» разрешения «безвредны» для пользователя, в то время как «опасные» могут получать доступ к личным данным и приватной информации человека. К dangerous разрешениям относятся, например, доступ к камере, смскам и файлам на телефоне.
Dangerous Permissions в Андроид
Если с обычными разрешениями все понятно, то над опасными Google все время работает и направляет усилия, чтобы всеми возможными способами защитить приватность своих пользователей. Со временем этот раздел претерпел существенные изменения.
Разрешения до Android 6.0 Marshmallow
Раньше, когда пользователь устанавливал приложение, он просто видел простыню разрешений, которые запрашивало приложение.
Мы же с вами прекрасно знаем как часто люди вообще читают что их просят… Особенно если они и так хотят получить то, за чем пришли. По этому, начиная с Android 6.0 Google ввел контекстные, точечные разрешения.
Получение разрешений начиная с Android 6.0
Вся затея изменений была в том, чтобы спрашивать пользователя о критичных разрешениях именно в тот момент, когда юзер совершает действие. К примеру человек нажал на кнопку камеры в приложении. Именно в этот самый момент приложение должно запросить разрешения на доступ к камере. Пользователь и защищен и ему понятно почему приложение просит доступ. Ведь до этого самого момента программа не могла физически получить доступ к камере. К тому же юзер всегда может отказать в запросе.
Важно чтобы мы, как разработчики позаботились о том, чтобы приложение работало корректно, даже если пользователь отказал в разрешении. Необходимо объяснить зачем оно нам нужно и что приложение может не работать, если разрешение не будет получено. Сложно представить, например, приложение — камеру без доступа к камере.
Для нас, как разработчиков, необходимо лишь запросить разрешения и ждать callback с результатом. Весь процесс подробно описан в официальной документации.
Как уже обсудили, Google постоянно улучшает защиту приватности пользователей. Так в Android 11 запрос разрешений получил еще ряд изменений.
Получение разрешений начиная с Android 11
One-time permissions
Местоположение, камера и микрофон — самые опасные разрешения, так как содержат крайне конфиденциальные данные. Именно по этому, начиная с Android 11 вводятся one-time permissions. Если пользователь согласился на использование своих данных, то вы можете сделать это единожды. В следующий раз придется снова спрашивать.
Автоматический сброс разрешений
Если ваше приложение не используется в течение нескольких месяцев, то система может сбросить критичные для приватности разрешения. Придется их получать заново. Хорошая новость в том, что если вы и так используете best practices для получения runtime permissions, то для вас ничего особо поменяться не должно.
Запрет доступа по умолчанию
Обычно, когда мы спрашиваем пользователя разрешения у него есть 2 опции — принять и отклонить. Если получили отказ, то мы можем снова запросить доступ. В таких случаях появляется опция «отвали, больше не спрашивать». Начиная с Android 11, если пользователь несколько раз запретил доступ — это автоматически считается как выбор опции «больше не спрашивать».
Я согласен с гуглом. Приватность и безопасность пользователя должна быть на первом месте. А вы что думаете? Для нас это конечно подкидывает больше работы. Особенно важно проверять edge case. К примеру, что при deeplink в ваше приложение вы также учитываете необходимость проверки разрешений.
