- Файл манифеста AndroidManifest.xml
- Назначение файла
- Общая структура манифеста
- Описание
- Атрибуты
- Android uses feature location
- Google Play and Feature-Based Filtering
- Filtering based on explicitly declared features
- Filtering based on implicit features
- Special handling for Bluetooth feature
- Testing the features required by your application
- Features Reference
- Hardware features
- Software features
- Permissions that Imply Feature Requirements
Файл манифеста AndroidManifest.xml
Файл манифеста AndroidManifest.xml предоставляет основную информацию о программе системе. Каждое приложение должно иметь свой файл AndroidManifest.xml. Редактировать файл манифеста можно вручную, изменяя XML-код или через визуальный редактор Manifest Editor (Редактор файла манифеста), который позволяет осуществлять визуальное и текстовое редактирование файла манифеста приложения.
Назначение файла
- объявляет имя Java-пакета приложения, который служит уникальным идентификатором;
- описывает компоненты приложения — деятельности, службы, приемники широковещательных намерений и контент-провайдеры, что позволяет вызывать классы, которые реализуют каждый из компонентов, и объявляет их намерения;
- содержит список необходимых разрешений для обращения к защищенным частям API и взаимодействия с другими приложениями;
- объявляет разрешения, которые сторонние приложения обязаны иметь для взаимодействия с компонентами данного приложения;
- объявляет минимальный уровень API Android, необходимый для работы приложения;
- перечисляет связанные библиотеки;
Общая структура манифеста
Файл манифеста инкапсулирует всю архитектуру Android-приложения, его функциональные возможности и конфигурацию. В процессе разработки приложения вам придется постоянно редактировать данный файл, изменяя его структуру и дополняя новыми элементами и атрибутами.
Корневым элементом манифеста является . Помимо данного элемента обязательными элементами является теги и . Элемент является основным элементом манифеста и содержит множество дочерних элементов, определяющих структуру и работу приложения. Порядок расположения элементов, находящихся на одном уровне, произвольный. Все значения устанавливаются через атрибуты элементов. Кроме обязательных элементов, упомянутых выше, в манифесте по мере необходимости используются другие элементы.
Описание
Элемент является корневым элементом манифеста. По умолчанию 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 элемента
Источник
Android uses feature location
Google Play Filtering
Google Play uses the elements declared in your app manifest to filter your app from devices that do not meet it’s hardware and software feature requirements.
By specifying the features that your application requires, you enable Google Play to present your application only to users whose devices meet the application’s feature requirements, rather than presenting it to all users.
For important information about how Google Play uses features as the basis for filtering, please read Google Play and Feature-Based Filtering, below.
The purpose of a declaration is to inform any external entity of the set of hardware and software features on which your application depends. The element offers a required attribute that lets you specify whether your application requires and cannot function without the declared feature, or whether it prefers to have the feature but can function without it. Because feature support can vary across Android devices, the element serves an important role in letting an application describe the device-variable features that it uses.
The set of available features that your application declares corresponds to the set of feature constants made available by the Android PackageManager , which are listed for convenience in the Features Reference tables at the bottom of this document.
You must specify each feature in a separate element, so if your application requires multiple features, it would declare multiple elements. For example, an application that requires both Bluetooth and camera features in the device would declare these two elements:
In general, you should always make sure to declare elements for all of the features that your application requires.
Declared elements are informational only, meaning that the Android system itself does not check for matching feature support on the device before installing an application. However, other services (such as Google Play) or applications may check your application’s declarations as part of handling or interacting with your application. For this reason, it’s very important that you declare all of the features (from the list below) that your application uses.
For some features, there may exist a specific attribute that allows you to define a version of the feature, such as the version of Open GL used (declared with glEsVersion ). Other features that either do or do not exist for a device, such as a camera, are declared using the name attribute.
Although the element is only activated for devices running API Level 4 or higher, it is recommended to include these elements for all applications, even if the minSdkVersion is «3» or lower. Devices running older versions of the platform will simply ignore the element.
Note: When declaring a feature, remember that you must also request permissions as appropriate. For example, you must still request the CAMERA permission before your application can access the camera API. Requesting the permission grants your application access to the appropriate hardware and software, while declaring the features used by your application ensures proper device compatibility.
attributes: android:name Specifies a single hardware or software feature used by the application, as a descriptor string. Valid descriptor values are listed in the Hardware features and Software features tables, below. Descriptor string values are case-sensitive. android:required Boolean value that indicates whether the application requires the feature specified in android:name .
- When you declare android:required=»true» for a feature, you are specifying that the application cannot function, or is not designed to function, when the specified feature is not present on the device.
- When you declare android:required=»false» for a feature, it means that the application prefers to use the feature if present on the device, but that it is designed to function without the specified feature, if necessary.
The default value for android:required if not declared is «true» .
android:glEsVersion The OpenGL ES version required by the application. The higher 16 bits represent the major number and the lower 16 bits represent the minor number. For example, to specify OpenGL ES version 2.0, you would set the value as «0x00020000», or to specify OpenGL ES 3.0, you would set the value as «0x00030000».
An application should specify at most one android:glEsVersion attribute in its manifest. If it specifies more than one, the android:glEsVersion with the numerically highest value is used and any other values are ignored.
If an application does not specify an android:glEsVersion attribute, then it is assumed that the application requires only OpenGL ES 1.0, which is supported by all Android-powered devices.
An application can assume that if a platform supports a given OpenGL ES version, it also supports all numerically lower OpenGL ES versions. Therefore, an application that requires both OpenGL ES 1.0 and OpenGL ES 2.0 must specify that it requires OpenGL ES 2.0.
An application that can work with any of several OpenGL ES versions should only specify the numerically lowest version of OpenGL ES that it requires. (It can check at run-time whether a higher level of OpenGL ES is available.)
For more information about using OpenGL ES, including how to check the supported OpenGL ES version at runtime, see the OpenGL ES API guide.
Google Play and Feature-Based Filtering
Google Play filters the applications that are visible to users, so that users can see and download only those applications that are compatible with their devices. One of the ways it filters applications is by feature compatibility.
To determine an application’s feature compatibility with a given user’s device, Google Play compares:
- Features required by the application — an application declares features in elements in its manifest
with. - Features available on the device, in hardware or software — a device reports the features it supports as read-only system properties.
To ensure an accurate comparison of features, the Android Package Manager provides a shared set of feature constants that both applications and devices use to declare feature requirements and support. The available feature constants are listed in the Features Reference tables at the bottom of this document, and in the class documentation for PackageManager .
When the user launches Google Play, the application queries the Package Manager for the list of features available on the device by calling getSystemAvailableFeatures() . The Store application then passes the features list up to Google Play when establishing the session for the user.
Each time you upload an application to the Google Play Developer Console, Google Play scans the application’s manifest file. It looks for elements and evaluates them in combination with other elements, in some cases, such as and elements. After establishing the application’s set of required features, it stores that list internally as metadata associated with the application .apk and the application version.
When a user searches or browses for applications using the Google Play application, the service compares the features needed by each application with the features available on the user’s device. If all of an application’s required features are present on the device, Google Play allows the user to see the application and potentially download it. If any required feature is not supported by the device, Google Play filters the application so that it is not visible to the user and not available for download.
Because the features you declare in elements directly affect how Google Play filters your application, it’s important to understand how Google Play evaluates the application’s manifest and establishes the set of required features. The sections below provide more information.
Filtering based on explicitly declared features
An explicitly declared feature is one that your application declares in a element. The feature declaration can include an android:required=[«true» | «false»] attribute (if you are compiling against API level 5 or higher), which lets you specify whether the application absolutely requires the feature and cannot function properly without it ( «true» ), or whether the application prefers to use the feature if available, but is designed to run without it ( «false» ).
Google Play handles explicitly declared features in this way:
- If a feature is explicitly declared as being required, Google Play adds the feature to the list of required features for the application. It then filters the application from users on devices that do not provide that feature. For example:
- If a feature is explicitly declared as not being required, Google Play does not add the feature to the list of required features. For that reason, an explicitly declared non-required feature is never considered when filtering the application. Even if the device does not provide the declared feature, Google Play will still consider the application compatible with the device and will show it to the user, unless other filtering rules apply. For example:
- If a feature is explicitly declared, but without an android:required attribute, Google Play assumes that the feature is required and sets up filtering on it.
In general, if your application is designed to run on Android 1.6 and earlier versions, the android:required attribute is not available in the API and Google Play assumes that any and all declarations are required.
Note: By declaring a feature explicitly and including an android:required=»false» attribute, you can effectively disable all filtering on Google Play for the specified feature.
Filtering based on implicit features
An implicit feature is one that an application requires in order to function properly, but which is not declared in a element in the manifest file. Strictly speaking, every application should always declare all features that it uses or requires, so the absence of a declaration for a feature used by an application should be considered an error. However, as a safeguard for users and developers, Google Play looks for implicit features in each application and sets up filters for those features, just as it would do for an explicitly declared feature.
An application might require a feature but not declare it because:
- The application was compiled against an older version of the Android library (Android 1.5 or earlier) and the element was not available.
- The developer incorrectly assumed that the feature would be present on all devices and a declaration was unnecessary.
- The developer omitted the feature declaration accidentally.
- The developer declared the feature explicitly, but the declaration was not valid. For example, a spelling error in the element name or an unrecognized string value for the android:name attribute would invalidate the feature declaration.
To account for the cases above, Google Play attempts to discover an application’s implied feature requirements by examining other elements declared in the manifest file, specifically, elements.
If an application requests hardware-related permissions, Google Play assumes that the application uses the underlying hardware features and therefore requires those features, even though there might be no corresponding to declarations. For such permissions, Google Play adds the underlying hardware features to the metadata that it stores for the application and sets up filters for them.
For example, if an application requests the CAMERA permission but does not declare a element for android.hardware.camera , Google Play considers that the application requires a camera and should not be shown to users whose devices do not offer a camera.
If you don’t want Google Play to filter based on a specific implied feature, you can disable that behavior. To do so, declare the feature explicitly in a element and include an android:required=»false» attribute. For example, to disable filtering derived from the CAMERA permission, you would declare the feature as shown below.
It’s important to understand that the permissions that you request in elements can directly affect how Google Play filters your application. The reference section Permissions that Imply Feature Requirements, below, lists the full set of permissions that imply feature requirements and therefore trigger filtering.
Special handling for Bluetooth feature
Google Play applies slightly different rules than described above, when determining filtering for Bluetooth.
If an application declares a Bluetooth permission in a element, but does not explicitly declare the Bluetooth feature in a element, Google Play checks the version(s) of the Android platform on which the application is designed to run, as specified in the element.
As shown in the table below, Google Play enables filtering for the Bluetooth feature only if the application declares its lowest or targeted platform as Android 2.0 (API level 5) or higher. However, note that Google Play applies the normal rules for filtering when the application explicitly declares the Bluetooth feature in a element.
Table 1. How Google Play determines the Bluetooth feature requirement for an application that requests a Bluetooth permission but does not declare the Bluetooth feature in a element.
Result | |
---|---|
android.hardware.bluetooth feature. | |
=5 | Google Play filters the application from any devices that do not support the android.hardware.bluetooth feature (including older releases). |
>=5 | >=5 |
The examples below illustrate the different filtering effects, based on how Google Play handles the Bluetooth feature.
In first example, an application that is designed to run on older API levels declares a Bluetooth permission, but does not declare the Bluetooth feature in a element. Result: Google Play does not filter the application from any device. In the second example, below, the same application also declares a target API level of «5». Result: Google Play now assumes that the feature is required and will filter the application from all devices that do not report Bluetooth support, including devices running older versions of the platform. Here the same application now specifically declares the Bluetooth feature. Result: Identical to the previous example (filtering is applied). Finally, in the case below, the same application adds an android:required=»false» attribute. Result: Google Play disables filtering based on Bluetooth feature support, for all devices.
Testing the features required by your application
You can use the aapt tool, included in the Android SDK, to determine how Google Play will filter your application, based on its declared features and permissions. To do so, run aapt with the dump badging command. This causes aapt to parse your application’s manifest and apply the same rules as used by Google Play to determine the features that your application requires.
To use the tool, follow these steps:
- First, build and export your application as an unsigned .apk . If you are developing in Eclipse with ADT, right-click the project and select Android Tools >Export Unsigned Application Package. Select a destination filename and path and click OK.
- Next, locate the aapt tool, if it is not already in your PATH. If you are using SDK Tools r8 or higher, you can find aapt in the /platform-tools/ directory.
Note: You must use the version of aapt that is provided for the latest Platform-Tools component available. If you do not have the latest Platform-Tools component, download it using the Android SDK Manager.
Here’s an example of the command output for the second Bluetooth example, above:
Features Reference
The tables below provide reference information about hardware and software features and the permissions that can imply them on Google Play.
Hardware features
The table below describes the hardware feature descriptors supported by the most current platform release. To signal that your application uses or requires a hardware feature, declare each value in a android:name attribute in a separate element.
Feature Type | Feature Descriptor | Description | Comments |
---|---|---|---|
Audio | android.hardware.audio.low_latency | The application uses a low-latency audio pipeline on the device and is sensitive to delays or lag in sound input or output. | |
Bluetooth | android.hardware.bluetooth | The application uses Bluetooth radio features in the device. | |
android.hardware.bluetooth_le | The application uses Bluetooth Low Energy radio features in the device. | ||
Camera | android.hardware.camera | The application uses the device’s camera. If the device supports multiple cameras, the application uses the camera that facing away from the screen. | |
android.hardware.camera.autofocus | Subfeature. The application uses the device camera’s autofocus capability. | These subfeatures implicitly declare the android.hardware.camera parent feature, unless declared with android:required=»false» . | |
android.hardware.camera.flash | Subfeature. The application uses the device camera’s flash. | ||
android.hardware.camera.front | Subfeature. The application uses a front-facing camera on the device. | ||
android.hardware.camera.any | The application uses at least one camera facing in any direction, or an external camera device if one is connected. Use this in preference to android.hardware.camera if a back-facing camera is not required. | ||
android.hardware.camera.external | The application uses an external camera device if one is connected. | ||
android.hardware.camera.level.full | The application uses a camera device with FULL -level support. | ||
android.hardware.camera.capability.manual_sensor | The application uses a a camera device with the MANUAL_SENSOR capability. | ||
android.hardware.camera.capability.manual_post_processing | The application uses a a camera device with the MANUAL_POST_PROCESSING capability. | ||
android.hardware.camera.capability.raw | The application uses a a camera device with the RAW capability. | ||
Infrared | android.hardware.consumerir | The application uses the consumer IR capabilities on the device. | |
Location | android.hardware.location | The application uses one or more features on the device for determining location, such as GPS location, network location, or cell location. | |
android.hardware.location.network | Subfeature. The application uses coarse location coordinates obtained from a network-based geolocation system supported on the device. | These subfeatures implicitly declare the android.hardware.location parent feature, unless declared with android:required=»false» . | |
android.hardware.location.gps | Subfeature. The application uses precise location coordinates obtained from a Global Positioning System receiver on the device. | ||
Microphone | android.hardware.microphone | The application uses a microphone on the device. | |
NFC | android.hardware.nfc | The application uses Near Field Communications radio features in the device. | |
android.hardware.nfc.hce | The application uses the NFC card emulation feature in the device. | ||
Sensors | android.hardware.sensor.accelerometer | The application uses motion readings from an accelerometer on the device. | |
android.hardware.sensor.barometer | The application uses the device’s barometer. | ||
android.hardware.sensor.compass | The application uses directional readings from a magnetometer (compass) on the device. | ||
android.hardware.sensor.gyroscope | The application uses the device’s gyroscope sensor. | ||
android.hardware.sensor.light | The application uses the device’s light sensor. | ||
android.hardware.sensor.proximity | The application uses the device’s proximity sensor. | ||
android.hardware.sensor.stepcounter | The application uses the device’s step counter. | ||
android.hardware.sensor.stepdetector | The application uses the device’s step detector. | ||
Screen | android.hardware.screen.landscape | The application requires landscape orientation. | |
android.hardware.screen.portrait | The application requires portrait orientation. | ||
Telephony | android.hardware.telephony | The application uses telephony features on the device, such as telephony radio with data communication services. | |
android.hardware.telephony.cdma | Subfeature. The application uses CDMA telephony radio features on the device. | These subfeatures implicitly declare the android.hardware.telephony parent feature, unless declared with android:required=»false» . | |
android.hardware.telephony.gsm | Subfeature. The application uses GSM telephony radio features on the device. | ||
Television | android.hardware.type.television | The application is designed for a television user experience. | This feature defines «television» to be a typical living room television experience: displayed on a big screen, where the user is sitting far away and the dominant form of input is something like a d-pad, and generally not through touch or a mouse/pointer-device. |
Touchscreen | android.hardware.faketouch | The application uses basic touch interaction events, such as «click down», «click up», and drag. | |
android.hardware.faketouch.multitouch.distinct | The application performs distinct tracking of two or more «fingers» on a fake touch interface. This is a superset of the faketouch feature. | ||
android.hardware.faketouch.multitouch.jazzhand | The application performs distinct tracking of five or more «fingers» on a fake touch interface. This is a superset of the faketouch feature. | ||
android.hardware.touchscreen | The application uses touchscreen capabilities for gestures that are more interactive than basic touch events, such as a fling. This is a superset of the basic faketouch feature. | ||
android.hardware.touchscreen.multitouch | The application uses basic two-point multitouch capabilities on the device screen, such as for pinch gestures, but does not need to track touches independently. This is a superset of touchscreen feature. | This implicitly declares the android.hardware.touchscreen parent feature, unless declared with android:required=»false» . | |
android.hardware.touchscreen.multitouch.distinct | Subfeature. The application uses advanced multipoint multitouch capabilities on the device screen, such as for tracking two or more points fully independently. This is a superset of multitouch feature. | This implicitly declares the android.hardware.touchscreen.multitouch parent feature, unless declared with android:required=»false» . | |
android.hardware.touchscreen.multitouch.jazzhand | The application uses advanced multipoint multitouch capabilities on the device screen, for tracking up to five points fully independently. This is a superset of distinct multitouch feature. | ||
USB | android.hardware.usb.host | The application uses USB host mode features (behaves as the host and connects to USB devices). | |
android.hardware.usb.accessory | The application uses USB accessory features (behaves as the USB device and connects to USB hosts). | ||
Wi-Fi | android.hardware.wifi | The application uses 802.11 networking (Wi-Fi) features on the device. | |
android.hardware.wifi.direct | The application uses the Wi-Fi Direct networking features on the device. |
Software features
The table below describes the software feature descriptors supported by the most current platform release. To signal that your application uses or requires a software feature, declare each value in a android:name attribute in a separate element.
Feature | Attribute Value | Description |
---|---|---|
App Widgets | android.software.app_widgets | The application uses or provides App Widgets and should be installed only on devices that include a Home screen or similar location where users can embed App Widgets. |
Device Management | android.software.device_admin | The application uses device policy enforcement via device administrators. |
Home Screen | android.software.home_screen | The application behaves as a Home screen replacement and should be installed only on devices that support third-party Home screen apps. |
Input Method | android.software.input_methods | The application provides a custom input method and should be installed only on devices that support third-party input methods. |
Live Wallpaper | android.software.live_wallpaper | The application uses or provides Live Wallpapers and should be installed only on devices that support Live Wallpapers. |
SIP/VOIP | android.software.sip | The application uses SIP service on the device and should be installed only on devices that support SIP. |
android.software.sip.voip |
Permissions that Imply Feature Requirements
Some feature constants listed in the tables above were made available to applications after the corresponding API; for example, the android.hardware.bluetooth feature was added in Android 2.2 (API level 8), but the bluetooth API that it refers to was added in Android 2.0 (API level 5). Because of this, some apps were able to use the API before they had the ability to declare that they require the API via the system.
To prevent those apps from being made available unintentionally, Google Play assumes that certain hardware-related permissions indicate that the underlying hardware features are required by default. For instance, applications that use Bluetooth must request the BLUETOOTH permission in a element — for legacy apps, Google Play assumes that the permission declaration means that the underlying android.hardware.bluetooth feature is required by the application and sets up filtering based on that feature.
The table below lists permissions that imply feature requirements equivalent to those declared in elements. Note that declarations, including any declared android:required attribute, always take precedence over features implied by the permissions below.
For any of the permissions below, you can disable filtering based on the implied feature by explicitly declaring the implied feature explicitly, in a element, with an android:required=»false» attribute. For example, to disable any filtering based on the CAMERA permission, you would add this declaration to the manifest file:
Источник