What is AndroidManifest.xml? | <application> element (Part 1 — attributes)

Photo by Denny Müller on Unsplash

If you have read my article about the <manifest> element of the AndroidManifest file, it is time to learn about the second crucial element within this file — the <application> sub-element.

Think of the <application> element as the heart of your app. It’s where all the important pieces come together, including activities, services, content providers, broadcast receivers, its icon, theme, label, etc.

- You have activities with a layout?; define them within this element.
- You have some background services?; define them within this element.
- Content ready to be shared with other apps?; fine, define them within this element.

Key attributes:

• android:name
  It is used to specify the full application package name of the Application class that represents the global context of the application.
• android:icon
  The application’s icon that is being displayed in the launcher and elsewhere.
• android:label
  The name of the application that is being displayed in the launcher and elsewhere.
• android:theme
  It is used to define the theme by which the visual image of the application is defined and which will apply to the entire application.
• android:allowBackup
  It is used to manage how the Android system stores the app’s local data, such as databases and preferences. This ensures data preservation even if the app is deleted or moved to a new device.
  - "true" : Setting this value means that the Android system will periodically back up the app’s local data to both the device’s local memory and, if connected to the internet, the user’s Google Drive for long-term storage. If the app is deleted or installed on a new device, the system will restore this data to reinstalled app.
  - "false" : Setting this value means that automatic backups are disabled, meaning data won’t be preserved in case of app removal or device changes.
  
  Note: If the target API is Android 12 or higher and this attribute has been set to false, then user data will not be backed up to the user’s Google Drive, but the user will be able to transfer data D2D (Device-to-device) via cable.
• android:dataExtractionRules
  While “android:allowBackup” offers a general approach to data backup, for detailed control over data in Android 12 and above (we use the “fullBackupContent” attribute for Android 11 and below devices), we use this attribute (because backing up sensitive user data poses a security risk).
  We set an XML file to this attribute. This XML file dictates precisely which data should be preserved and which should remain excluded, ensuring sensitive information stays secure.
• android:fullBackupContent
  While “android:allowBackup” offers a general approach to data backup, for detailed control over data in Android 11 and below (we use the “dataExtractionRules” attribute for Android 12 and above devices), we use this attribute (because backing up sensitive user data poses a security risk).
  We set an XML file to this attribute. This XML file dictates precisely which data should be preserved and which should remain excluded, ensuring sensitive information stays secure.
• android:hasFragileUserData
  It allows developers to let users themselves choose whether the data should be backed up or not during app deletion process.
  - "true” : Setting this value means that the Android system will present a prompt during app uninstallation and ask users whether they wish to retain app data or not.
  - "false" (default value) : Setting this value means that the Android system will handle the data according to configured backup rules without users’ input.
• android:debuggable
  It acts as a key to activate debugging features within the app. While IDEs like Android Studio often provide debugging without its explicit declaration, setting this attribute is recommended. Because debugging mode can expose sensitive information, it is recommended to disable it for release builds.
  - "true” : Setting this value unlocks debugging capabilities, enabling essential tools for troubleshooting.
  - "false” : Setting this value disables debugging capabilities.
• android:hardwareAccellerated
  This attribute lets developers control whether to harness the device’s hardware components for smoother, more visually nice graphics.
  - "true” : Setting this value will ensure that the rendering tasks will be done by a hardware-based GPU instead of a software-based CPU. This type of hardware-accelerated rendering results in smoother animations and transitions, and faster rendering.
  - "false” : Setting this value will only let the software-based CPU handle the rendering tasks.
• android:supportsRtl
  It lets developers adapt their app’s layout for right-to-left (RTL) languages like Arabic and Farsi, ensuring a natural and intuitive experience for users worldwide.
  - "true” : Setting this value signals the Android system to automatically mirror UI elements and text direction (all texts align to the right) when an RTL language is selected.
  - "false” (default value) : Setting this value signals the Android system that this app is specifically designed for LTR (left-to-right) languages.
• android:appCategory
  It is used to specify the category that the application exactly fits into. It provides valuable information to both users and the Android system. Users browsing Play Store categories can easily find our app in the exact category if it has been accurately categorized.
  - "accessibility" : Setting this value indicates that this app is specifically designed for accessibility reasons. Apps like screen readers should set this value.
  - "audio" : Apps primarily focused on audio playback and manipulation, like music players and podcast apps.
  - "game" : Games of all genres and styles.
  - "image" : Apps designed for image editing, viewing, or creation, like camera apps and photo editors.
  - "maps" : Apps that offering maps, directions, and location-based services.
  - "news" : Apps that deliver news content from various sources.
  - "productivity" : Apps designed to enhance efficiency and workflow, like task managers, calendars, or document editors.
  - "social" : Apps that offer social interaction and communication, like social networks, messaging apps, or dating apps.
  - "video" : Apps dedicated to video playback and streaming, like video players or video editing tools.
• android:largeHeap
  In Android, each application is treated as a distinct user with its own ID, owing to the multi-user Linux kernel system. Consequently, every application is processed and launched with its own Virtual Machine (VM), ensuring the isolation of code and data for enhanced security.
  We know that each VM has a designated memory known as the heap, where processed objects and other runtime data are stored. To allocate space in the device’s memory for this heap, the VM must request a specific amount. The Android system assigns starting memory space to each application based on the device’s capabilities, current load, and general application requirements. When launching the app, the VM claims the allocated memory for its heap before initiating the processing.
  However, an application may require more memory than the standard allocation on the device. For example, a video editing application dealing with large videos may demand additional space. In such cases, we use the ‘largeHeap’ attribute within <application> element, setting it to “true.” This signals to the Android system that the application might need a larger memory allocation compared to other apps.
  - "true" : Indicates that the application may require more memory.
  - "false" : Indicates that no additional memory needs to be allocated beyond the standard.
• android:process
  In Android, each application is treated as a distinct user with its own ID, owing to the multi-user Linux kernel system. Consequently, every application is processed and launched with its own Virtual Machine (VM), ensuring the isolation of code and data for enhanced security.
  We know that each VM has a designated memory known as the heap, where processed objects and other runtime data are stored. To allocate space in the device’s memory for this heap, the VM must request a specific amount. The Android system assigns starting memory space to each application based on the device’s capabilities, current load, and general application requirements. When launching the app, the VM claims the allocated memory for its heap before initiating the processing.
  By default, all components of an application are processed under the same main VM process, sharing the same heap and potentially sensitive data. However, there are scenarios where we might want to separate specific components, such as those handling sensitive data or background services, from the main VM processing.
  For instance, consider a banking application with a payment transaction component. For security reason, we may opt to process this payment transaction in a separate process rather than the main VM process. This separation is facilitated by the ‘process’ attribute. Both processes operate under the same heap memory but have distinct “names”, providing protection against potential threats. In the event of threats in other parts of the application, hackers would find it more challenging to access sensitive data in this isolated component.
  - ":[process_name]" : Processing the component under the specified hidden process name. The “:” symbol denotes that this process is hidden, and direct communication from other processes is restricted.
  - "[process_name]" : Processing the component under the specified process name. The absence of “:” designates this as a “Global process,” allowing other processes to attempt communication.
  
  Note: It’s important to note that sub-elements of the <application> element, such as <activity> or <service>, typically override this attribute. When used on the <application> element itself, it specifies the main process for all components. If this attribute is not declared, the application defaults to a single VM process matching the package name.

• android:enabled
  It allows us to control whether the Android system can create instances of the app’s components.
  When we use this attribute within the <application> element itself, it acts as a master switch and control all components’ instantiation processes. To control the instantiation of specific components, developers usually override this attribute at the individual component level (e.g., for activities, services, receivers).
  - "true" (default value) : All components are eligible for instantiation. The system can create instances of them as needed.
  - "false" : All components are considered non-instantiable. The system cannot create instances of them (disabling them).
• android:permission
  It is used indicate whether any component within the application or application itself requires protection through a specific permission. Typically, this attribute is applied to sub-elements like activities or services of the <application> element, signifying protection for individual components. However, if the intention is to apply the permission universally across all components, it can be directly used in the <application> element itself.
  Understanding that custom permissions are established in the application using the <permission> element in the manifest file is crucial. For instance, let's consider an app named "MyContacts" where a custom permission called "ACCESS_PRIVATE_CONTACTS" is created to protect private contacts. Any other app wishing to access private contacts in the MyContacts app must hold this permission.

<manifest>
  ...
  <permission
    android:name="com.example.myapp.permission.ACESS_PRIVATE_CONTACTS"
    android:label="Access contacts info"
    android:description="@string/description_access_private_contacts"
    android:icon="@drawable/ic_access_private_contacts"
    android:protectionLevel="dangerous"/>

  <application
    ...
    android:label="MyContacts">
  </application>
</manifest>

However, merely declaring the permission through the <permission> element doesn't automatically apply it to any component. It's like having a key without a lock. To enforce this protection, we need to associate the permission with a specific component by overwriting the 'permission' attribute of the <application> element within that component.

Continuing with the example, let’s assume the private contacts are managed in the ‘PrivateContactsActivity’ activity. After declaring this activity in the <application> element, we attach the declared permission (ACCESS_PRIVATE_CONTACTS) using this attribute:

<manifest>
  ...
  <permission
    android:name="com.example.myapp.permission.ACESS_PRIVATE_CONTACTS"
    android:label="Access private contacts info"
    android:description="@string/description_access_private_contacts"
    android:icon="@drawable/ic_access_private_contacts"
    android:protectionLevel="dangerous"/>

  <application
    ...
    android:label="MyContacts">
  </application>

  <activity
    ...
    android:name=".PrivateContactsActivity"
    android:permission="com.example.ACESS_PRIVATE_CONTACTS">
</manifest>

By doing so, we ensure that other applications can access this component and its features only if they declare this permission in their manifest file using the <uses-permission> element. Access is granted based on the user's consent.

Syntax:

<application
  android:name=".application.MyApplication"
  android:icon="@mipmap/ic_app_icon"
  android:label="@string/app_name"
  android:theme="@style/Theme.Material3.DayNight"
  android:allowBackup="true"
  android:dataExtractionRules="@xml/my_data_extraction_rules"
  android:fullBackupContent="@xml/my_backup_rules"
  android:hasFragileUserData="true"
  android:debugabble="true"
  android:hardwareAccellerated="true"
  android:supportsRtl="false"
  android:appCategory="maps"
  android:largeHeap="false"
  android:process=":my_own_process"
  android:enabled="true"
  android:permission="com.example.MY_PERMISSION">


...


</application>

Thank you for reading until the end. Before you go:

- You can visit my github profile:

kananbashir - Overview

- Here is my LinkedIn profile: kananbashir