» Программирование Android

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

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

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

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

<manifest xmlns:android=http://schemas.android.com/apk/res/android

package=»com.hello.world»

android:versionCode=»1″

android:versionName=»1.1 Beta»>

</manifest>

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

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

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

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

<uses-sdk>

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

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

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

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

Пример:

<uses-sdk android:minSdkVersion=»4″

android:targetSdkVersion=»5″>

</uses-sdk>

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

<uses-configeration>

Тег 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 – необходим сенсорный экран емкостного типа (управляемый пальцем).

Пример:

<uses-configuration android:reqTouchScreen=[«finger»]

android:reqNavigation=[«trackball»]

android:reqHardKeyboard=[«true»]

android:reqKeyboardType=[«qwerty»/>

<uses-configuration android:reqTouchScreen=[«finger»]

android:reqNavigation=[«trackball»]

android:reqHardKeyboard=[«true»]

android:reqKeyboardType=[«twelvekey»]/>

 

<user-feature>

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

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

<uses-feature android:glEsVersion=» 0x00010001″

android:name=»android.hardware.camera» />

 

<supports-screens>

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

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

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

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

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

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

Пример:

<supports-screens android:smallScreens=[«false»]

android:normalScreens=[«true»]

android:largeScreens=[«true»]

android:anyDensity=[«false»] />

 

<application>

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

Пример:

<application android:icon=»@drawable/icon»

android:theme=»@style/my_theme»

android:name=»MyApplication»

android:debuggable=»true»>

</application>

 

Тег <activity> создается для каждого имеющегося в приложении Activity. Кроме того, каждый Activity, в свою очередь, поддерживает тег <intent-filter>, чтобы определить запускающий Activity Intent.

Пример:

<activity android:name=».MyActivity» android:label=»@string/app_name»>

<intent-filter>

<action android:name=»android.intent.action.MAIN» />

<category android:name=»android.intent.category.LAUNCHER» />

</intent-filter>

</activity>

 

Тег <service> нужен для описанию каждого имеющегося в приложении класса Services. Как и <activity>, тег <service> поддерживает дочерний тег <intent-filter>.

Пример:

<service android:enabled=»true» android:name=».MyService»></service>

 

Тег <provider> используется для описания каждого Content Provider в программе.

Пример:

<provider android:permission=»com.paad.MY_PERMISSION»

android:name=».MyContentProvider»

android:enabled=»true»

android:authorities=»com.paad.myapp.MyContentProvider»>

</provider>

 

Тег <receiver> необходим для объявления Broadcast Receivers, не запуская само приложение. То есть в теге могут описываться события, на которые приложение должно реагировать.

Пример:

<receiver android:enabled=»true»

android:label=»My Intent Receiver»

android:name=».MyIntentReceiver»>

</receiver>

 

<uses-permission>

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

<uses-permission android:name=»android.permission.INTERNET»/>

Полный список всех допустимых разрешений можно получить из официальной документации – http://developer.android.com/reference/android/Manifest.permission.html.

<permission>

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

Пример:

<permission android:name=»com.paad.DETONATE_DEVICE»

android:protectionLevel=»dangerous»

android:label=»Self Destruct»

android:description=»@string/detonate_description»>

</permission>

 

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