Список разрешений для андроид

Android permissions

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

Разрешения могут быть двух типов: normal и dangerous. Отличие между ними в том, что dangerous разрешения опасны, т.к. могут быть использованы для получения ваших личных данных или информации о вас, или еще каким-то способом могут навредить вам. Примеры dangerous разрешений — это доступ к контактам или смс.

Полный список существующих разрешений можно посмотреть здесь. Характеристика Protection level подскажет насколько опасно это разрешение. А здесь можно сразу просмотреть весь список normal разрешений.

Если приложению необходимо получить какое-либо разрешение, то оно должно быть указано в AndroidManifest.xml, в корневом теге . Тег разрешения — .

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

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

В этом материале мы подробно рассмотрим, как происходит это подтверждение.

До Android 6

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

Система показывает разрешения, которые были прописаны в манифесте. Сначала те, которые могут быть опасными с точки зрения приватности (отправка смс, доступ к камере/местоположению/контактам), а затем — обычные (интернет, bluetooth).

Таким образом пользователь видит, на что претендует приложение, и может примерно понять все ли в порядке. Если, например, приложение калькулятор при установке просит у вас доступ к контактам и смс, то скорее всего, что-то не так с этим приложением и оно может быть опасным для ваших данных.

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

Если же в манифесте не указать разрешение READ_CONTACTS, то его не будет и в списке тех разрешений, которые подтверждает пользователь. Соответственно, система не предоставит этому приложению доступ к контактам. И при попытке получить список контактов, будет ошибка:
java.lang.SecurityException: Permission Denial: opening provider com.android.providers.contacts.ContactsProvider2

Android 6

С выходом Android 6 механизм подтверждения поменялся. Теперь при установке приложения пользователь больше не видит списка запрашиваемых разрешений. Приложение автоматически получает все требуемые normal разрешения, а dangerous разрешения необходимо будет программно запрашивать в процессе работы приложения.

Т.е. теперь недостаточно просто указать в манифесте, что вам нужен, например, доступ к контактам. Когда вы в коде попытаетесь запросить список контактов, то получите ошибку SecurityException: Permission Denial. Потому что вы явно не запрашивали это разрешение, и пользователь его не подтверждал.

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

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

Проверка текущего статуса разрешения выполняется методом checkSelfPermission

На вход метод требует Context и название разрешения. Он вернет константу PackageManager.PERMISSION_GRANTED (если разрешение есть) или PackageManager.PERMISSION_DENIED (если разрешения нет).

Если разрешение есть, значит мы ранее его уже запрашивали, и пользователь подтвердил его. Можем получать список контактов, система даст нам доступ.

Если разрешения нет, то нам надо его запросить. Это выполняется методом requestPermissions. Схема его работы похожа на метод startActivityForResult. Мы вызываем метод, передаем ему данные и request code, а ответ потом получаем в определенном onResult методе.

Добавим запрос разрешения к уже имеющейся проверке.

Проверяем разрешение READ_CONTACTS. Если оно есть, то читаем контакты. Иначе запрашиваем разрешение READ_CONTACTS методом requestPermissions. На вход метод требует Activity, список требуемых разрешений, и request code. Обратите внимание, что для разрешений используется массив. Т.е. вы можете запросить сразу несколько разрешений.

После вызова метода requestPermissions система покажет следующий диалог

Здесь будет отображено разрешение, которое мы запросили методом requestPermissions. Пользователь может либо подтвердить его (ALLOW), либо отказать (DENY). Если будет запрошено сразу несколько разрешений, то на каждое из них будет показан отдельный диалог. И пользователь может какие-то разрешения подтвердить, а какие-то нет.

Решение пользователя мы получим в методе onRequestPermissionsResult

Проверяем, что requestСode тот же, что мы указывали в requestPermissions. В массиве permissions придут название разрешений, которые мы запрашивали. В массиве grantResults придут ответы пользователя на запросы разрешений.

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

В итоге схема получения разрешения состоит из трех действий:
— проверка текущего состояния разрешения
— запрос на получение разрешения, если оно еще не было получено
— обработка ответа на запрос

Далее поговорим про некоторые дополнительные возможности, нюансы и прочие мелочи.

Манифест

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

Всегда проверяйте разрешение

Каждый раз (а не только первый) перед выполнением операции, требующей определенного разрешения, необходимо проверять, что это разрешение есть. Потому что, даже если пользователь уже давал это разрешение, он всегда может зайти в настройки приложения и отменить его. И если вы после этого не выполните проверку, то получите ошибку при выполнении операции.

Don’t ask again

Когда вы первый раз делаете запрос на какое-либо разрешение, пользователь может отказать. При последующих запросах этого же разрешения, в диалоге появится чекбокс Don’t ask again

Если пользователь включит этот чекбокс, то при последующих ваших запросах диалог не будет отображаться, а в onRequestPermissionsResult сразу будет приходить отказ.

Объяснение для пользователя

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

Диалог, который показывается при запросе разрешения, — системный, вы не можете менять его содержимое и добавлять туда свой текст. Но вы можете сделать свой диалог или что-то подобное и показать его перед тем, как будете делать запрос разрешения.

Есть метод shouldShowRequestPermissionRationale, который может быть полезен в данной ситуации. Передаете ему название разрешения, а он вам в виде boolean ответит, надо ли показывать объяснение для пользователя.

Т.е. вы сначала проверяете наличие разрешения. Если его нет, то вызываете shouldShowRequestPermissionRationale, чтобы решить, надо ли показывать объяснение пользователю. Если не надо, то делаете запрос разрешения. А если надо, то показываете ваш диалог с объяснением, а после этого диалога делаете запрос разрешения.

Алгоритм работы метода shouldShowRequestPermissionRationale прост.

Если вы еще ни разу не запрашивали это разрешение, то он вернет false. Т.е. перед первым запросом разрешения ничего объяснять не надо.

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

Если пользователь ставил галку Don’t ask again, то метод вернет false. Запрос полномочий все равно не будет выполнен. Объяснять что-то не имеет смысла.

Разумеется, вы можете показывать дополнительную информацию согласно вашим правилам и не использовать метод shouldShowRequestPermissionRationale.

Группы

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

Например, разрешения READ_CONTACTS и WRITE_CONTACTS принадлежат группе CONTACTS. И если пользователь уже подтверждал разрешение на READ_CONTACTS, то при проверке WRITE_CONTACTS вы получите PERMISSION_GRANTED.

Android 6 и targetSdkVersion 23

Схема работы разрешений зависит от версии Android, на которой запущено приложение и от параметра targetSdkVersion приложения.

Новая схема будет работать, если версия Android >= 6 И targetSdkVersion >= 23.

В остальных случаях, т.е. когда targetSdkVersion

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Источник

Опасные разрешения для приложений на Android: как избежать риска

При установке и первом запуске приложения, как правило, запрашивают разрешение на доступ к самым разным функциям и данным: к SMS, списку контактов, календарю, другим компонентам устройства. Как понять, какие из них нужны программе для работы, а какие — излишни и вполне могут быть уловкой мошенников? Давайте разбираться.

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

Безопаснее всего приложения от крупных известных компаний, таких, например, как Google, МТС, «Яндекс» и др. — они вряд ли будут рисковать репутацией и подсовывать потребителю сомнительный продукт.

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

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

Разрешение на отправку, приём и просмотр текстовых и мультимедийных сообщений.

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

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

Камера

Разрешение на работу с камерой, позволяющее делать фотоснимки и записывать видео.

Риски: Приложение сможет снимать фото и записывать видеоролики без предупреждения и согласия пользователя.

Рекомендации: Подумайте, действительно ли приложению нужен доступ к фото- и видеосъёмке. Это так, если вы пытаетесь установить клиента соцсети (например, «Инстаграм»), где выкладка фото — обычное явление. Аналогично со списком покупок, в котором можно фотографировать продукты в супермаркете. Но если это игра вроде «5 в ряд», запрос на работу с камерой выглядит подозрительно.

Чтобы обезопасить себя, загружайте приложения только из проверенного источника — в Android это официальный магазин контента Google Play. Даже если окажетесь на сайте разработчика ПО, поищите ссылку именно на магазин, а не скачивайте напрямую — уже одно это существенно снизит риски.

Контакты

Разрешение на чтение адресной книги, изменение и добавление контактов.

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

Рекомендации: Доступ к контактам оправдан, если программа предусматривает обмен информацией с контактами из вашего списка — например, как у клиентов соцсетей и мессенджеров. Неочевидная потребность в таком разрешении должна заставить вас сомневаться.

Календарь

Разрешение на просмотр событий календаря, редактирование и создание новых событий.

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

Рекомендации: Внимательно присмотритесь к функциональности приложения. Если оно связано с инструментами планирования (например, приложение для составления списка желаний к праздникам или облачный сервис для управления проектами типа Trello), доступ к календарю можно разрешить. Но странно, если о таких правах просит, например, фонарик или диктофон.

Телефон

Разрешение на сканирование журнала вызова.

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

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

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

Системные инструменты

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

Риски: Приложение может в фоновом режиме и без участия пользователя запускать вредоносный код.

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

Память

Разрешение на изменение или удаление содержимого карты памяти.

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

Рекомендации: Убедитесь, что приложение связано с созданием или изменением данных и эту функцию можно логично объяснить (как, например, в случае с графическими редакторами). Проверьте, не запрашивает ли приложение другие, необязательные на первый взгляд разрешения. Если их много, это повод задуматься и изучить репутацию разработчика.

Местоположение

Разрешение на доступ к данным о геолокации устройства на основе информации о базовых станциях сотовой сети, точках доступа а также GPS и ГЛОНАСС.

Риски: Эти сведения приложения могут использовать для совершения реальных преступлений — например, физического преследования. Также разрешение позволяет отправлять пользователю спам или вредоносные программы с учётом его региона.

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

Микрофон

Разрешение на запись звука с микрофона.

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

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

Нательные датчики

Доступ к данным от датчиков состояния здоровья — чаще всего пульсометру.

Риски: Приложение сможет отслеживать изменения здоровья пользователя.

Рекомендации: Узнайте больше о разработчиках, уточните, связаны ли они с медициной. Страховые компании используют подобные приложения, чтобы оценивать стоимость страховки. Также доступ к датчикам может быть у сервисов, работающих с фитнес-браслетами.

Где посмотреть разрешения для уже установленных Android-приложений

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

Вы увидите список разрешений и узнаете, для каких приложений они одобрены. Например, в пункте «Камера» перечислены все приложения, которые имеют к ней доступ.

Открывайте приложение, если хотите изменить статус его разрешений по каждому отдельному компоненту:

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

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

Источник