What are android manifest files

Android Manifest

The Android Manifest is an XML file which contains important metadata about the Android app. This includes the package name, activity names, main activity (the entry point to the app), Android version support, hardware features support, permissions, and other configurations.

For more information about the Android Manifest file, see the Android Developer documentation on Android Manifests.

How Unity produces the Android Manifest

In Unity 2019.3 and newer versions, the Android Gradle An Android build system that automates several build processes. This automation means that many common build errors are less likely to occur. More info
See in Glossary project that Unity generates has two template manifest files:

1. LauncherManifest.xml — Located in the exported project, at root/launcher/src/main/AndroidManifest.xml. This file contains the app’s:
   • icons
   • name
   • starting activity and its Intents
   • install location
   • supported screen sizes
   • isGame setting
2. LibraryManifest.xml — Located in the exported project at root/unityLibrary/src/main/AndroidManifest.xml. You can override this manifest with a custom_ AndroidManifest.xml_ that you add in the Plugins/Android folder. This file declares the:
   • Unity activity
   • permissions
   • theme used by the Unity activity
   • VR modes
   • VR performance
   • making the activity non-resizable (for VR)
   • setting max aspect ratio
   • reacting to configuration changes
   • orientations
   • launch modes
   • Android UI (User Interface) Allows a user to interact with your application. More info
     See in Glossary hardware acceleration
   • used features (like gamepad or graphics API)
   • notch support
   • initial window size
   • ability to resize the window

When Unity builds your app, it automatically generates the Android manifest files, following the steps below:

1. Unity uses LibraryManifest.xml or AndroidManifest.xml as the main manifest.
2. It then finds all of the Android manifests of your plug-ins A set of code created outside of Unity that creates functionality in Unity. There are two kinds of plug-ins you can use in Unity: Managed plug-ins (managed .NET assemblies created with tools like Visual Studio) and Native plug-ins (platform-specific native code libraries). More info
   See in Glossary (.aar files and Android Libraries).
3. It uses Google’s manifmerger class to merge plug-in manifests into the main manifest.
4. Unity modifies the manifest files in the launcher and library modules. It automatically adds permissions, configuration options, features used, and other information.

Overriding the Android manifest

Although Unity generates a correct manifest for your app, you might want direct control over its contents.

To use an Android manifest you created outside of Unity, import your Android Manifest file to the following location: Assets/Plugins/Android/AndroidManifest.xml. This overrides the default LibraryManifest.xml.

In this situation, Unity merges the manifests of your Android libraries into your main manifest, and ensures that the resulting manifest’s configuration is correct. For full control of the manifest, including permissions, you must export the Project and modify the final manifest in Android Studio.

Note: Unity only supports the [launchMode — singleTask](https://developer.android.com/guide/topics/manifest/activity-element.html#lmode) launch mode.

Permissions

Unity automatically adds the necessary permissions to the manifest based on the Android Player Settings and Unity APIs that your app calls from the script. For example:

• Network classes add the INTERNET permission
• Using vibration (such as Handheld.Vibrate ) adds VIBRATE
• The InternetReachability ] property adds ACCESS_NETWORK_STATE
• Location APIs (such as LocationService ) adds ACCESS_FINE_LOCATION
• WebCamTexture APIs add CAMERA A component which creates an image of a particular viewpoint in your scene. The output is either drawn to the screen or captured as a texture. More info
  See in Glossary permission
• The Microphone class adds RECORD_AUDIO
• NetworkDiscovery and NetworkTransport.SetMulticastLock add CHANGE_WIFI_MULTICAST_STATE

For more information about permissions, see Android developer documentation on Android Manifest Permissions.

If your plug-ins require a permission by declaring it in their manifests, Unity automatically adds the permission to the resulting Android manifest during the merge stage. All Unity APIs that plug-ins call also contribute to the permissions list.

Runtime permissions in Android 6.0 (Marshmallow)

If your app is running on a device with Android 6.0 (Marshmallow) or later and also targets Android API level 23 or higher, your app uses the Android Runtime Permission System.

The Android Runtime Permission System asks the user to grant permissions while the app is running, instead of when they first install the app. App users can usually grant or deny each permission when the app needs it while the app is running (for example, requesting camera permission before taking a picture). This allows an app to run with limited functionality without permissions. You can use the Android.Permission class in Unity to check whether the user granted or denied specific permissions. If a permission your app needs has been denied, you can inform the user why the app needs it and ask them to approve the permission. For more information, see documentation on Requesting Permissions.

Your app normally prompts the user to allow what Android calls “dangerous” permissions on its startup. For more information, see Android developer documentation on dangerous permissions. If you don’t want your app to ask for permissions on startup, you can add the following code to your manifest, in either the Application or Activity sections:

Note: This code suppresses the permission dialog the app shows on startup, but you must handle runtime permissions carefully to avoid crashes. This is an advanced method of dealing with runtime permissions.

For more information about the Runtime Permission System and handling permissions, see Android developer documentation on Requesting Permissions.

Examining the resulting Android manifest

To examine the final Android manifest that Unity generates for your app, open the Temp/StagingArea/AndroidManifest.xml file after you build your Project but before you close the Unity Editor.

The Manifest is stored in binary format in the output package (.apk). To check the contents of a Manifest inside an . apk The Android Package format output by Unity. An APK is automatically deployed to your device when you select File > Build & Run. More info
See in Glossary , you can use the Android Studio APK Analyzer, or another third-party tool such as Apktool.

• Unity as a Library for Android added in 2019.3. NewIn20193
• Added support for Android Runtime Permissions in 2018.3.
• Updated functionality in 5.5

Источник

Работа с манифестом 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 , чтобы указать, что приложение может быть отлажено, что его понятное имя — мое приложение, а в качестве темы по умолчанию для всех действий используется стиль.

Источник

Working with the Android Manifest

AndroidManifest.xml is a powerful file in the Android platform that allows you to describe the functionality and requirements of your application to Android. However, working with it is not easy. Xamarin.Android helps to minimize this difficulty by allowing you to add custom attributes to your classes, which will then be used to automatically generate the manifest for you. Our goal is that 99% of our users should never need to manually modify AndroidManifest.xml.

AndroidManifest.xml is generated as part of the build process, and the XML found within Properties/AndroidManifest.xml is merged with XML that is generated from custom attributes. The resulting merged AndroidManifest.xml resides in the obj subdirectory; for example, it resides at obj/Debug/android/AndroidManifest.xml for Debug builds. The merging process is trivial: it uses custom attributes within the code to generate XML elements, and inserts those elements into AndroidManifest.xml.

The Basics

At compile time, assemblies are scanned for non- abstract classes that derive from Activity and have the [Activity] attribute declared on them. It then uses these classes and attributes to build the manifest. For example, consider the following code:

This results in nothing being generated in AndroidManifest.xml. If you want an element to be generated, you need to use the [Activity] custom attribute:

This example causes the following xml fragment to be added to AndroidManifest.xml:

The [Activity] attribute has no effect on abstract types; abstract types are ignored.

Activity Name

Beginning with Xamarin.Android 5.1, the type name of an activity is based on the MD5SUM of the assembly-qualified name of the type being exported. This allows the same fully-qualified name to be provided from two different assemblies and not get a packaging error. (Before Xamarin.Android 5.1, the default type name of the activity was created from the lowercased namespace and the class name.)

If you wish to override this default and explicitly specify the name of your activity, use the Name property:

This example produces the following xml fragment:

You should use the Name property only for backward-compatibility reasons, as such renaming can slow down type lookup at runtime. If you have legacy code that expects the default type name of the activity to be based on the lowercased namespace and the class name, see Android Callable Wrapper Naming for tips on maintaining compatibility.

Activity Title Bar

By default, Android gives your application a title bar when it is run. The value used for this is /manifest/application/activity/@android:label . In most cases, this value will differ from your class name. To specify your app’s label on the title bar, use the Label property. For example:

This example produces the following xml fragment:

Launchable from Application Chooser

By default, your activity will not show up in Android’s application launcher screen. This is because there will likely be many activities in your application, and you don’t want an icon for every one. To specify which one should be launchable from the application launcher, use the MainLauncher property. For example:

This example produces the following xml fragment:

Activity Icon

By default, your activity will be given the default launcher icon provided by the system. To use a custom icon, first add your .png to Resources/drawable, set its Build Action to AndroidResource, then use the Icon property to specify the icon to use. For example:

This example produces the following xml fragment:

Permissions

When you add permissions to the Android Manifest (as described in Add Permissions to Android Manifest), these permissions are recorded in Properties/AndroidManifest.xml. For example, if you set the INTERNET permission, the following element is added to Properties/AndroidManifest.xml:

Debug builds automatically set some permissions to make debug easier (such as INTERNET and READ_EXTERNAL_STORAGE ) – these settings are set only in the generated obj/Debug/android/AndroidManifest.xml and are not shown as enabled in the Required permissions settings.

For example, if you examine the generated manifest file at obj/Debug/android/AndroidManifest.xml, you may see the following added permission elements:

In the Release build version of the manifest (at obj/Debug/android/AndroidManifest.xml), these permissions are not automatically configured. If you find that switching to a Release build causes your app to lose a permission that was available in the Debug build, verify that you have explicitly set this permission in the Required permissions settings for your app (see Build > Android Application in Visual Studio for Mac; see Properties > Android Manifest in Visual Studio).

Advanced Features

Intent Actions and Features

The Android manifest provides a way for you to describe the capabilities of your activity. This is done via Intents and the [IntentFilter] custom attribute. You can specify which actions are appropriate for your activity with the IntentFilter constructor, and which categories are appropriate with the Categories property. At least one activity must be provided (which is why activities are provided in the constructor). [IntentFilter] can be provided multiple times, and each use results in a separate element within the . For example:

This example produces the following xml fragment:

Application Element

The Android manifest also provides a way for you to declare properties for your entire application. This is done via the element and its counterpart, the Application custom attribute. Note that these are application-wide (assembly-wide) settings rather than per-Activity settings. Typically, you declare properties for your entire application and then override these settings (as needed) on a per-Activity basis.

For example, the following Application attribute is added to AssemblyInfo.cs to indicate that the application can be debugged, that its user-readable name is My App, and that it uses the Theme.Light style as the default theme for all activities:

This declaration causes the following XML fragment to be generated in obj/Debug/android/AndroidManifest.xml:

In this example, all activities in the app will default to the Theme.Light style. If you set an Activity’s theme to Theme.Dialog , only that Activity will use the Theme.Dialog style while all other activities in your app will default to the Theme.Light style as set in the element.

There are many application-wide attributes that you can configure in the element; for more information about these settings, see the Public Properties section of ApplicationAttribute.

Источник