Android permissions read phone

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

Источник

Работа с Runtime Permissions в Android 6. Получаем разрешения программно

В этой статье мы рассмотрим работу с получением разрешений во время выполнения, которые были добавлены в Android 6 (API 23).

Runtime Permissions в Android API 23. Теория

Одним из основных изменений в Android API 23 является новая система разрешений. В более ранних версиях разрешения объявляли в файле AndroidManifest.xml и больше никаких действий не требовалось. Но с Android 6 мы должны запрашивать разрешения из категории «Опасных» во время выполнения.

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

Прежде чем запрашивать разрешения, нам нужно описать их в файле AndroidManifest.xml .

Процесс получения разрешений:

1). Узнать, получено ли в приложении необходимое разрешение. Например, так:

2). Если разрешения нет, то запросить его с помощью метода requestPermissions() :

Сразу несколько разрешений можно запросить так:

3). Обработать результат запроса на получение разрешений можно так:

Обратите внимание на массив grantResults[] — здесь хранятся результаты по каждому из запрашиваемых разрешений. Если в методе requestPermissions() мы запрашивали 1 разрешение, то обрабатываем только 1 значение массива результатов: grantResults[0] .

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

Давайте на примере посмотрим на разные способы получения разрешений.

Runtime Permissions в Android API 23. Практика

В нашем тестовом приложении мы будем получать данные телефона, поэтому нам нужно запрашивать разрешение на получение Manifest.permission.READ_PHONE_STATE .

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

Идем в файл AndroidManifest.xml и добавляем разрешение на работу со звонками:

Теперь идем в MainActivity.java и описываем процесс получения разрешений и обработку результатов:

Если запустить приложение, то получим такой результат:

На первом экране мы запрашиваем разрешение. 2 — успешное их получение. 3 — Разрешение не получено

Задумка с разрешениями сводится к тому, что если пользователь не разрешит приложению доступ к чему-то, то мы должны отключить эту функциональность в приложении и работать с остальным функционалом приложения. А как же быть, если запрашиваемое разрешение является критическим для нашего приложения?

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

Новую функциональность я специально выделил:

Источник

Предупреждения Ваш Apk использует разрешения, требующие политики конфиденциальности: (android.permission.READ_PHONE_STATE)

В манифесте не добавлен android.permission.READ_PHONE_STATE. разрешение.

Почему ошибка возникает, когда я загружаю новую версию ошибки apk, ниже.

В вашем приложении есть apk с кодом версии 1, который запрашивает следующие разрешения: android.permission.READ_PHONE_STATE. Приложения, использующие эти разрешения в APK, должны иметь политику конфиденциальности.

Я приложил скриншот к моей учетной записи в Google Play.

Мой файл манифеста.

У вашего приложения manifest.xml есть такое разрешение для доступа к информации с вашего устройства, но у вас нет ссылки на политику конфиденциальности при отправке в магазин воспроизведения. Поэтому вы получаете это предупреждение.

Необходимость политики конфиденциальности для приложения Если ваше приложение обрабатывает личные или конфиденциальные пользовательские данные

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

Просто попробуйте добавить эту строку в файл манифеста:

Зависимости, которые у вас есть в вашем проекте, добавят свои собственные разрешения. Пожалуйста, сделайте следующее, чтобы найти, откуда «READ_PHONE_STATE».

1. Перестройте приложение для Android
2. Нажмите «Ctrl + Shift + F» в студии Android (в основном выполните поиск в редакторе по вашему желанию).
3. Найдите «READ_PHONE_STATE», вы найдете запись в обновленном файле манифеста (а не том, который вы изначально создали). По пути вы можете узнать, от какой зависимости добавляется разрешение.

Это может быть из-за какой-либо третьей стороны, которая может включать это разрешение, поэтому из моего опыта в этом поле. Вы должны добавить политику конфиденциальности, относящуюся к этой конкретной информации, это означает, что если вы попросите разрешение на получение аккаунта в своем приложении, то вы должны объявить, что С вашим файлом политики конфиденциальности мы используем эти данные, т. Е. Адрес электронной почты или что-то еще с такими причинами, как вход в игру Google Play.

Надейтесь, что это поможет вам. Что вы можете сделать для этого предупреждения, создайте политику конфиденциальности для своего приложения и прикрепите ее к списку магазинов.

Если вы тестируете свое приложение на устройстве> android 6.0, вы также должны прямо попросить пользователя предоставить разрешение.

Как вы можете видеть здесь, READ_PHONE_STATE имеет опасный уровень.

Если разрешение имеет опасный уровень, пользователь должен принять или не разрешить это разрешение вручную. У вас нет выбора, вы ДОЛЖНЫ делать это

Для этого выполните следующие действия:

Если пользователь использует Android M и еще не предоставил разрешение, он попросит об этом.

Затем переопределить onRequestPermissionsResult в вашей деятельности

Вы должны прочитать эту статью, чтобы узнать больше об этом

Используете ли вы AdSense или другие объявления в своем приложении или, возможно, Google Analytics? Я думаю, что если вы это сделаете, даже если у вас нет андроида.permission.READ_PHONE_STATE в вашем манифестах, это добавляется в библиотеку объявлений.

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

Это письмо, которое я получил от Google:

Привет, разработчик Google Play, наши записи показывают, что ваше приложение xxx с именем пакета xxx в настоящее время нарушает нашу политику пользовательских данных в отношении личной и конфиденциальной информации. Проблема с политикой. Google Play требует от разработчиков предоставления правильной политики конфиденциальности, когда приложение запрашивает или обрабатывает конфиденциальную информацию о пользователе или устройстве. Ваше приложение запрашивает конфиденциальные разрешения (например, камеру, микрофон, учетные записи, контакты или телефон) или данные пользователя, но не включает действительную политику конфиденциальности. Необходимое действие. Включите ссылку на действующую политику конфиденциальности на странице «Список покупок» вашего приложения и в вашем приложении. Дополнительную информацию вы можете найти в нашем справочном центре. В качестве альтернативы вы можете отказаться от этого требования, удалив любые запросы на конфиденциальные разрешения или пользовательские данные. Если у вас есть дополнительные приложения в вашем каталоге, убедитесь, что они соответствуют нашим замечательным требованиям к раскрытию. Удалите эту проблему до 15 марта 2017 года, или административные действия будут предприняты для ограничения видимости вашего приложения, вплоть до удаления из Play Маркета. Спасибо, что помогли нам обеспечить прозрачный и прозрачный опыт для пользователей Google Play. С уважением, команда Google Play

Вам нужно указать min и target sdk версию target sdk в файле манифеста.
Если не android.permission.READ_PHONE_STATE будет автоматически добавляться при экспорте вашего файла apk.

1. Возможно, вы используете PlayServices версии 9.6.0. Затем вы должны его обновить, это ошибка библиотеки. Больше информации здесь .

К файлу манифеста.

1. Вам нужно создать страницу политики конфиденциальности на своем веб-сайте и обновить политику конфиденциальности для разрешений, которые вы запрашиваете.

2. Обновите новый SDK, удалите ненужные разрешения и повторно подайте приложение.

Источник