AndroidManifest.xml: passport of your application

In the world of development for the Android operating system, there is one file that is the foundation for any software product being launched. This is the application manifest, or, in technical terms, a file AndroidManifest.xml. Without it, the system simply will not understand how to interact with your code, what resources to load and what permissions to request from the user during installation.

Imagine that you built a complex house with rooms, communications and security, but forgot to give the architect a building plan. Builders will not know where the front door is and where the sockets are. Likewise, Android OS ignores any APK file that does not contain this declarative document. It acts as a strict contract between the developer and the operating system, dictating the rules of the game.

Understanding the structure of this file is critical not only for programmers creating new products, but also for security specialists analyzing malware. This is where all the “wants” of the application are written down: access to the camera, the Internet, contacts or geolocation. Let's look in detail at what this file consists of and how it controls the life of the application on a smartphone.

The architectural role of the manifest in the Android system

The manifest file is located in the root directory of the project and is compiled along with the source code. Its main task is to provide metadata about the application to the system PackageManager. When you press the “Install” button on the smartphone screen, it is this service that first reads the manifest to understand what exactly it is going to install.

Unlike the executable code that tells the system what to do, the manifest explains to the system who you are. It defines a unique package name, which serves as an identifier for the application in the Google Play store and in the device memory. Two applications with the same package name cannot exist on the same device at the same time unless they are signed by the same certificate.

In addition to identification, the file describes the components of the application: activities, services, broadcast receivers, and content providers. The Android system is unaware of the existence of these components until they are explicitly declared in the manifest. This is a security mechanism: if an attacker tries to introduce a hidden service into someone else's application, the system will simply ignore it, since this service is not in the application passport.

⚠️ Attention: Never change the package name in an already published application. This will be a completely new product for the system, and users will not be able to update the old version; they will have to delete it and install it again, losing all data.

File structure and main configuration elements

The file is written in language XML and has a strictly hierarchical structure. The root element is always the tag <manifest>, within which all other settings are located. The attribute xmlns:android indicates the namespace required for the correct operation of the system parser.

There is a section inside the root element <application>, which describes the global properties of the entire application. Here you set the icon, name, theme and flag that allows or prohibits data backup. All components, such as activities, must be nested inside the application tag or declared as part of its context.

Particular attention should be paid to version attributes. The manifest specifies two types of versions: android:versionCode and android:versionName. The first is an integer that the system uses for comparison: if the new number is greater than the old one, an update is offered. The second is the string (for example, "1.0.5") that the user sees in the application store.

The secret of the tools attribute

ignore: Sometimes during compilation, warnings appear that the developer deliberately ignores. For this, the tools namespace is used, which allows you to suppress the linter without affecting the operation of the application in production.

Below is a table of the main attributes of the root element and the application tag, which are found in 99% of projects:

Attribute	Location	Purpose	Example value
package	manifest	Unique application ID	com.example.myapp
android:label	application	Display name	@string/app_name
android:icon	application	Icon in the launcher	@mipmap/ic_launcher
android:theme	application	Default interface style	@style/AppTheme
android:allowBackup	application	Backup permission	true / false

Managing permissions and access to resources

One of the most important functions of the manifest is the declaration of access rights. The modern Android ecosystem follows the principle of least privilege: an application is not allowed to do anything more than basic operations unless it explicitly requests permission. These requests are written with tags <uses-permission> at the top of the file, immediately after the package declaration.

There are two levels of permissions: normal and dangerous. Regular permissions such as Internet access (INTERNET) or vibration, the system provides automatically during installation. Dangerous ones, for example, reading contacts or accessing the camera, require explicit confirmation from the user while the application is running through runtime requests.

In addition to requesting rights, the manifest allows you to declare your own permissions through the tag <permission>. This is used when one application wants to protect its components from access by other apps. Only those applications that have been granted this custom permission will be able to interact with the protected component.

• 🔒 INTERNET — basic right to access the global network, required to download data.
• 📍 ACCESS_FINE_LOCATION — access to precise coordinates via GPS, requires user confirmation.
• 📸 CAMERA — ability to use the device’s hardware camera for shooting.
• 📞 READ_CALL_LOG —reading call history, is particularly sensitive data.

⚠️ Attention: Google Play policies are constantly becoming stricter. If your app requests permissions that are not used in its core functionality (for example, a flashlight asking for access to contacts), moderation will reject the publication or remove the app from the store.

Registration of components: Activities, Services and Receivers

An application consists of four types of components, and each of them must be registered in the manifest. Activity (Activity) is a single interface screen. The tag <activity> tells the system that this class can be run and displayed to the user. Without this entry, clicking on the application icon will not produce anything.

Service (Service) is designed to perform background tasks without an interface. For example, playing music or downloading a file. Declaring a service through a tag <service> allows the system to know about its existence and manage its lifecycle, even if the user has minimized the application.

The third important type is BroadcastReceiver (Receiver). It allows the application to respond to system events, such as the OS finishing loading, changing the battery level, or receiving an SMS. In the manifest, this is declared by a tag <receiver>, inside which the intent-filters are specified that the component should respond to.

<receiver android:name=".BootReceiver" android:enabled="true">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>

The last type is ContentProvider. It is used to securely exchange data between different applications. Through the tag <provider> you specify a URI by which other apps can request your application data, while respecting the access rights you set.

Intent Filters and navigation between applications

The Intent Filters engine (intent filters) is a powerful tool that makes Android such a flexible system. They allow you to declare that your activity is capable of handling certain actions, even if the user launched them from another application. This is how share buttons or opening links in the browser work.

In the manifest, the intent filter is described inside the component tag (usually an activity) using a nested element <intent-filter>. Inside it, the action (<action>), category (<category>) and data type (<data>) are indicated. For example, in order for your activity to open when clicking on the https link, you need to specify the appropriate scheme and host.

Category plays a special role LAUNCHER. If you want the application to have a desktop icon, the main activity must contain an intent-filter with an action MAIN and category LAUNCHER. Without this combination, the application will install, but the user will not find a way to launch it manually.

Errors in setting up intent filters lead to the application becoming "invisible" to the system in certain scenarios. If you are developing a file manager, but forgot to specify a filter for the “image” data type, the system will not offer your application when you try to open a picture from the gallery.

Optimization and configuration security

The manifest affects not only functionality, but also performance and security. Incorrect configuration can lead to memory leaks or vulnerabilities. For example, if you export a component (activity or service) unnecessarily, other applications will be able to gain unauthorized access to it.

The attribute android:exported has become mandatory in recent versions of Android. It explicitly indicates whether the component can be started externally. For internal service activities, always set to false. This covers potential attack vectors when an attacker tries to call a hidden function of your application.

It is also worth paying attention to the android:debuggableattribute. In release builds it should be equal false or absent. Leaving debug mode enabled in the public version allows hackers to connect to the application process via ADB and inject their code or steal data.

⚠️ Warning: Always check the final compiled manifest (AndroidManifest.xml in the build folder) before releasing. Build tools (Gradle) can automatically add permissions or change attributes based on dependencies, which sometimes leads to unexpected consequences.

Common errors and debugging methods

Developers often encounter errors related to incorrect manifest syntax or logic. The most common problem is ActivityNotFoundException. It occurs when the code tries to launch an activity that is not declared in the configuration file or does not have a suitable intent-filter.

Another common error is an SDK version conflict. Attributes minSdkVersion and targetSdkVersion must be consistent with the libraries used. If you use an API that is only available from version 21 of Android, but specify a minimum version of 16, the application will crash on older devices.

To diagnose problems, use the utility aapt or the built-in analyzers in Android Studio. They show the final manifest tree, taking into account all the manifest mergers from the libraries. This helps to understand where the extra permission came from or why the component attribute has changed.

Why does the application crash immediately after installation with a manifest error?

Most often this happens due to a syntax error in the XML (unclosed tag) or specifying a non-existent class in the android:name attribute. The system cannot parse the file and interrupts the launch of the application process.

Is it possible to change the manifest of an already installed application?

No, the manifest file is compiled inside the APK file. To make changes, you need to change the original project, rebuild the APK and install the new version on top of the old one (with the same package name and signature).

Why is the android:allowBackup attribute needed?

It allows or denies the Android system to create backup copies of application data in the cloud or on a PC. For banking applications and instant messengers with encryption, this flag is often set to false so as not to copy sensitive data.

What is Manifest Merger?

This is a build process in which your project's manifest is merged with the manifests of all connected libraries. If conflicts arise (for example, different versions of the same permission), the collector uses precedence rules or requires manual resolution via tools:replace.

How to view the manifest of someone else's application?

You can extract the APK file from the device and open it using a decompiler (for example, jadx or apktool). There you will see the AndroidManifest.xml file, which will show all the permissions and components of the foreign application.