Манифест андроид студио что это

Описание

Элемент является корневым элементом манифеста. По умолчанию Eclipse создает элемент с четырьмя атрибутами:

Атрибуты

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

android:name название разрешения android:label имя разрешения, отображаемое пользователю android:description описание разрешения android:icon значок разрешения android:permissionGroup определяет принадлежность к группе разрешений android:protectionLevel уровень защиты

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

android:name имеет единственный атрибут с именем разрешения android:name. Это может быть разрешение, определенное в элементе

данного приложения, разрешение, определенное в другом приложении или одно из стандартных системных разрешений, например: android:name=»android.permission.CAMERA» или android:name=»»android.permission.READ_CONTACTS»

Наиболее распространенные разрешения

• INTERNET — доступ к интернету
• READ_CONTACTS — чтение (но не запись) данных из адресной книги пользователя
• WRITE_CONTACTS — запись (но не чтение) данных из адресной книги пользователя
• RECEIVE_SMS — обработка входящих SMS
• ACCESS_COARSE_LOCATION — использование приблизительного определения местонахождения при помощи вышек сотовой связи или точек доступа Wi-Fi
• ACCESS_FINE_LOCATION — точное определение местонахождения при помощи GPS

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

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

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

Источник

Структура AndroidManifest.xml

AndroidManifest.xml – это так называемый «паспорт» любого приложения для ОС Android. Данный файл полностью описывает структуру, составляющие приложения и его требования. «Манифест» нужен любому приложению и для создания любой программы под Android его нужно составить правильно.

Существует официальная документация с описанием структуры файла AndroidManifest.xml, однако она достаточно объемная и сложная для восприятия, кроме того – на английском языке, так что мы постараемся изложить всю необходимую информацию в удобоваримой форме.

Итак, AndroidManifest.xml находится в корневой директории приложения и всегда имеет именно такое имя. Всё содержимое данного файла в теге — это корневой тег «манифеста». Например:

Package – название данного программного пакета.

VersionCode – версия приложения (значение может быть использовано для внутренних нужд).

VersionName – значение версии, которое показывается пользователю.

Все остальные теги находятся внутри тега , и основные из них мы сейчас и рассмотрим.

Тег Uses-sdk содержим параметры, которые указывают на необходимую для работоспособности приложения версию SDK. Возможны такие параметры:

minSDKVersion — минимально допустимая версия SDK, чтобы запустить программу.

targetSDKVersion – «целевая» версия SDK, проще говоря – на данной версии проводилось тестирование приложения.

maxSDKVersion – верхняя допустимая версия SDK для работы приложение. Если нет стопроцентной уверенности в том, что на более новых версиях SDK приложение не будет работать, то данный параметр лучше не использовать вовсе.

Как видно, минимальная версия SDK – четвертая, а тестирование проводилось на пятой.

Тег Uses-Configeration определяет компбинацию допустимых методов ввода для приложения. Возможны следующие параметры:

reqFiveWayNav – приложение будет требовать от устройства возможность навигации в четырех направлениях плюс нажатие (это, к примеру, оптический или пятипозиционный джойстик). Возможные значения: true, false.

reqHardKeyboard – приложение будет требовать обязательное наличие аппаратной клавиатуры. Возможные значения: true, false.

reqKeyboardType — требование приложения к типу клавиатуры, которое распространяется как на программную (сенсорную), так и на аппаратную клавиатуру. Значения:

undefined – значение по умолчанию, означает, что приложение не требует клавиатуру.

nokeys – аналогично предыдущему, приложение не требует клавиатуру.

twelvekey – приложение требует 12-символьную стандартную «телефонную» клавиатуру.

qwerty – приложение требует полную клавиатуру с раскладкой qwerty.

reqNavigation – требования приложения к возможным способам навигации на девайсе (трекбол, джойстик, колесико). Допустимые значения:

undefined – значение по умолчанию. У приложения к способу навигации требований нет.

nonav – у приложения к способу навигации требований нет.

dpad – приложению требуется D-pad для работы.

trackball – приложению нужен трекбол.

wheel – приложению требуется колесо навигации.

reqTouchScreen – обязательно наличие сенсорного экрана. Допустимые значения:

undefined – значение по умолчанию, наличие сенсорного экрана не требуется.

notouch – наличие сенсорного экрана не требуется.

stylus – необходим сенсорный экран резистивного типа (управляемый стилусом).

finger – необходим сенсорный экран емкостного типа (управляемый пальцем).

Тег User-Feature определяет необходимые аппаратные и программные возможности устройства. Полный список всех допустимых требований приведен в официальной документации для AndroidManifest.xml — http://developer.android.com/guide/topics/manifest/uses-feature-element.html#features-reference.

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

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

smallScreens – приложение поддерживает нестандартные и малые разрешения дисплея (такие как HVGA, QVGA).

normalScreens – приложение поддерживает стандартные разрешения (такие как HVGA, WVGA, WQVGA).

largeScreens – приложение поддерживает устройства с высокой разрешающей способностью дисплея.

anyDensity – допустимо любое разрешение экрана.

Значения для всех параметров false или true.

Тег Application – один из основных. Здесь описываются такие параметры приложения, как его название, иконка, ссылка на пользовательский интерфейс и много чего еще. Кроме того, данный тег – это контейнер для других тегов, которые описывают те или иные компоненты программы, в том числе Service, Activity, Content Provider и Broadcast Receiver. О компонентах APK мы уже говорили в другом материале.

Источник

Работа с манифестом Android

AndroidManifest.xml — это мощный файл на платформе Android, который позволяет описать функциональные возможности и требования приложения для Android. Однако работать с ним непросто. Xamarin. Android помогает снизить эту сложность, позволяя добавлять настраиваемые атрибуты в классы, которые затем будут использоваться для автоматического создания манифеста. Наша цель заключается в том, что 99% наших пользователей никогда не нужно вручную изменять AndroidManifest.xml.

AndroidManifest.xml создается как часть процесса сборки, и XML-код, найденный в свойствах/AndroidManifest.xml , объединяется с XML, созданным из настраиваемых атрибутов. Полученный Объединенный AndroidManifest.xml находится в подкаталоге obj ; Например, он находится в файле obj/Debug/Android/AndroidManifest.xml для отладочных сборок. Процесс слияния является тривиальным: он использует настраиваемые атрибуты в коде для создания XML-элементов и вставляет эти элементы в AndroidManifest.xml.

Основы

Во время компиляции сборки сканируются для классов, не являющихся abstract классами, которые являются производными от abstract и имеют [Activity] объявленный атрибут. Затем эти классы и атрибуты используются для создания манифеста. Рассмотрим следующий пример кода:

Это приведет к невозможности создания в AndroidManifest.xml. Если требуется создать элемент, необходимо использовать [Activity] настраиваемый атрибут:

В этом примере к AndroidManifest.xmlу добавляется следующий фрагмент XML:

[Activity] Атрибут не влияет на abstract типы; abstract типы игнорируются.

Activity Name

Начиная с Xamarin. Android 5,1, имя типа действия основано на MD5SUM имени экспортируемого типа с указанием сборки. Это позволяет предоставить одно и то же полное имя из двух разных сборок и не получить ошибку упаковки. (Перед Xamarin. Android 5,1 имя типа действия по умолчанию было создано из пространства имен в нижнем регистре и имени класса.)

Если вы хотите переопределить это значение по умолчанию и явно указать имя действия, используйте Name свойство:

В этом примере создается следующий фрагмент XML:

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

Строка заголовка действия

По умолчанию Android предоставляет приложению заголовок при его запуске. Для этого используется значение /manifest/application/activity/@android:label . В большинстве случаев это значение будет отличаться от имени класса. Чтобы указать метку приложения в заголовке окна, используйте Label свойство. Например:

В этом примере создается следующий фрагмент XML:

Запуск из средства выбора приложений

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

В этом примере создается следующий фрагмент XML:

Значок действия

По умолчанию для действия будет задан значок запуска по умолчанию, предоставляемый системой. Чтобы использовать пользовательский значок, сначала добавьте .png в Resources/Draw, задайте для его действия сборки значение AndroidResource, а затем используйте свойство, чтобы указать используемый значок. Например:

В этом примере создается следующий фрагмент XML:

Разрешения

При добавлении разрешений в манифест Android (как описано в разделе Добавление разрешений в манифест Android) эти разрешения записываются в свойствах и AndroidManifest.xml. Например, при задании INTERNET разрешения в INTERNET добавляется следующий элемент:

Отладочные сборки автоматически устанавливают некоторые разрешения для упрощения отладки (например INTERNET , и READ_EXTERNAL_STORAGE ) — эти параметры задаются только в созданном INTERNET и не отображаются как включенные в параметрах READ_EXTERNAL_STORAGE .

Например, если вы изучите созданный файл манифеста в файле obj/Debug/Android/AndroidManifest.xml, вы можете увидеть следующие добавленные элементы разрешений:

В версии сборки выпуска манифеста (в файле obj/Debug/Android/AndroidManifest.xml) эти разрешения не настраиваются автоматически. если вы обнаружите, что переключение на сборку выпуска приводит к тому, что ваше приложение потеряет разрешение, доступное в отладочной сборке, убедитесь, что это разрешение явно задано в параметрах, необходимых для приложения (см. раздел сборка приложения android в Visual Studio для Mac; см. свойства манифеста android в Visual Studio).

Дополнительные функции

Действия и функции намерения

Манифест Android предоставляет способ описания возможностей действия. Это делается с помощью целей и [IntentFilter] настраиваемый атрибут. Можно указать, какие действия соответствуют действию, с помощью IntentFilter и какие категории подходят дляСвойство Categories . Необходимо указать по крайней мере одно действие (это объясняется тем, что действия предоставляются в конструкторе). [IntentFilter] может предоставляться несколько раз, и каждое использование приводит к отдельному элементу в . Например:

В этом примере создается следующий фрагмент XML:

Элемент Application

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

Источник