какой xml тег используется приложением для указания разрешения permission

Манифест приложения

Каждый проект в Android имеет файл манифеста, называемый AndroidManifest.xml, который хранится в корневом каталоге. Файл манифеста является важной частью нашего приложения, поскольку он определяет структуру и метаданные приложения. В частности, манифест приложения выполняет следующие задачи:

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

Манифест приложения содержит корневой элемент с именем пакета, заданным в атрибуте package. Он также должен включать атрибут xmls:android, который будет предоставлять несколько системных атрибутов, используемых в файле.

В можно добавить атрибут android:versionCode, который используется для определения текущей версии приложения в виде целого числа, которое увеличивается с каждым обновлением. Также атрибут android:versionName используется для указания публичной версии, которая показывается пользователям.

Также можно указать, куда должно устанавливаться приложение: на SD-карту или внутреннюю память, используя атрибут android:installLocation.

Oбщая структура файла манифеста выглядит следующим образом:

Кратко рассмотрим каждый из этих элементов.

Элемент

Этот элемент позволяет запрашивать у системы разрешения, которые нужны приложению для доступа к различным функциям. Это делается с помощью единственного атрибута android:name, в параметры которого нужно передать имя разрешения. Например, для получения доступа к Интернету нужно добавить следующее разрешение:

Элемент

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

Элемент

Этот элемент объявляет базовое имя дерева разрешений. Приложение получает права собственности на все разрешения в дереве. Оно может динамически добавлять новые разрешения для дерева, вызывая PackageManager.addPermission(). Имена внутри дерева разделяются точками. Например, если имя дерева задано как ru.androidtools.project, то для него можно добавить следующие разрешения:

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

Элемент

Объявляет имя группы для набора разрешений. Отдельные разрешения присоединяются к группе через атрибут android:permissionGroup элемента

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

Источник

Android permissions

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

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

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

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

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

До Android 6

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

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

Нажав кнопку 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, оно всегда одно и то же.

Корневой элемент манифеста. Является обязательным.

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

Атрибуты:

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

Атрибуты:

Элемент позволяет приложению объявлять пространство имён разрешений, в которое оно может динамически во время выполнения добавлять новые разрешения.

Атрибуты:

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

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

Атрибуты:

Объявляет класс Instrumentation, который дает возможность отслеживать все взаимодействия, которые система выполняет с приложением. Обычно используется при отладке и тестировании приложения и удаляется из release-версии приложения.

Атрибуты:

Совместимость приложения с указанной версией Android. Когда приложение будет устанавливаться, система сравнит указанный уровень API с API устройства. Также Google Play использует этот элемент, чтобы отфильтровывать устройства, которые не соответствуют указанному уровню API.

Атрибуты:

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

Атрибуты:

Объявляет одну или несколько аппаратных или программных функций, требуемых для работы приложения.

Атрибуты:

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

Атрибуты:

Данные атрибуты были добавлены в API 13 (Android 3.2):

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

Этот элемент носит исключительно информационный характер. С помощью него Google Play фильтрует устройства с неподдерживаемыми экранами.

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

Определяет формат сжатия текстур GL. Элемент является информационным, т.е. необходим Google Play для фильтрации устройств, которые не поддерживают заданные параметры.

Дочерние элементы:

Атрибуты:

Дочерние элементы:

Атрибуты:

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

На эту тему есть интересная статья.

Дочерние элементы:

Атрибуты:

Данный элемент позволяет записать какие-либо данные по типу “ключ-значение”. Доступ к этим данным можно получить из всего приложения (если объявлены в внутри тега ), либо можно передать необходимые для работы данные конкретной activity (объявляется внутри тега ).

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

Источник

Разрешения в Xamarin.Android

Обзор

Приложения Android выполняются в собственной песочнице, и по соображениям безопасности не имеют доступа к определенным системным ресурсам или оборудованию на устройстве. Пользователь должен явно предоставить разрешение на доступ к приложению, прежде чем он сможет использовать эти ресурсы. Например, приложение не может получить доступ к GPS на устройстве без явного разрешения у пользователя. Android выдаст исключение, Java.Lang.SecurityException Если приложение пытается получить доступ к защищенному ресурсу без разрешения.

Разрешения объявляются в AndroidManifest.xml разработчиком приложения при разработке приложения. У Android есть два разных рабочих процесса для получения согласия пользователя для этих разрешений:

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

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

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

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

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

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

Требования

настоятельно рекомендуется, чтобы проекты xamarin. android включали пакет xamarin. android. Support NuGet. Этот пакет будет выполнять неограниченный доступ к более старым версиям Android для интерфейсов API, предоставляя один общий интерфейс без необходимости постоянно проверять версию Android, на которой выполняется приложение.

Запрос разрешений системы

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

Приложения, предназначенные для Android 6,0 или более поздней версии, не могут предположить, что, поскольку пользователь предоставил разрешение в некоторый момент времени в прошлом, это разрешение будет действительным в следующий раз. Приложение, предназначенное для Android 6,0, должно всегда выполнять проверку разрешений среды выполнения. Приложениям, предназначенным для Android 5,1 или более низкого уровня, не требуется выполнять проверку разрешений во время выполнения.

Приложения должны запрашивать только те разрешения, которые им необходимы.

Объявление разрешений в манифесте

Разрешения добавляются в AndroidManifest.xml с uses-permission элементом. Например, если приложение должно определять положение устройства, для него требуются точные разрешения и расположение курса. В манифест добавляются следующие два элемента:

Разрешения можно объявить с помощью встроенной поддержки средств в Visual Studio:

Дважды щелкните Свойства в Обозреватель решений и выберите вкладку Манифест Android в окно свойств:

Выберите разрешения, необходимые приложению, в списке требуемые разрешения и сохраните:

разрешения можно объявить с помощью встроенной поддержки средств в Visual Studio для Mac:

Дважды щелкните проект в панель решения и выберите параметры > сборка > приложение Android:

Выберите необходимые для приложения разрешения в списке требуемые разрешения и нажмите кнопку ОК.

Для приложений, предназначенных для Android 5.1 (уровень API 22) или ниже, больше ничего делать не нужно. Приложения, которые будут работать на Android 6,0 (API 23 уровня 23) или выше, должны перейти к следующему разделу о выполнении проверок разрешений времени выполнения.

Проверки разрешений среды выполнения в Android 6,0

ContextCompat.CheckSelfPermission Метод (доступный в библиотеке поддержки Android) используется для проверки предоставления определенного разрешения. Этот метод возвращает Android.Content.PM.Permission перечисление, которое имеет одно из двух значений:

В этом фрагменте кода приведен пример того, как проверить наличие разрешения камеры в действии:

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

Если пользователь предоставляет разрешение, ActivityCompat.RequestPermissions(Activity activity, string[] permissions, int requestCode) метод должен быть вызван. Этот метод требует наличия следующих параметров:

Этот фрагмент кода является примером двух обсуждаемых методов. Во-первых, выполняется проверка, чтобы определить, должно ли быть показано логическое разрешение. Если необходимо отобразить обоснование, то Снаккбар отображается с обоснованием. Если пользователь нажмет кнопку ОК в снаккбар, приложение запросит разрешения. Если пользователь не принимает обоснование, приложение не должно продолжать отвечать на запросы разрешений. Если обоснование не отображается, действие запрашивает разрешение:

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

Сводка

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

Источник