The App Manifest

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Every Android app has an app manifest. It’s important because it tells an Android device everything it needs to know about your app.

Think of it as an instruction manual about your app for the Android system. It contains essential information like the app’s components (activities, services, etc.) and their configurations.

Android is strict about its requirements for a manifest. The file name must be AndroidManifest.xml, and it has to be located in the correct spot in the project file hierarchy. Without this file, Android refuses to run your app.

On the left side of Android Studio, in the Project navigator, navigate to app ▸ manifests ▸ AndroidManifest.xml.

Note: The manifests folder in the sidebar is a virtual folder generated by Android Studio’s Android project view and isn’t directly related to anything in the file system. The actual file is kept at the root of your app’s main folder inside app/src.

Also, for now, don’t worry about any warnings that appear in the manifest.

This is an XML-based file containing various tags. The main tags in this file are manifest, application, and activity, but you’ll use plenty more.

The manifest tag is the root element of the app manifest. You must declare all the other tags within this tag.

The application tag contains app-specific information for the Android system, such as the icon to use for the app, the name of the app, and what theme style it uses. This information tells Android how to present the app on the home screen and how to represent it in other areas, such as the Settings.

Activities

Perhaps the most interesting tags are the activity tags. Every activity within an app should have a corresponding tag within the manifest. This is to ensure that your app only runs activities from within your app, not any that may have come from elsewhere.

The Foundation of Screens

  • An activity is like a container that holds the UI elements (buttons, text views, images, etc.) that the user sees on a particular screen. You define these elements with “composables” — declarative UI elements using the Jetpack Compose library.
  • Each activity is typically associated with a separate Kotlin class that handles the logic behind the UI, like responding to user clicks, updating data, or interacting with other parts of your app.

User Interaction and Navigation

  • Activities are the focal point for user interaction. They handle user inputs like clicks, swipes, and text input. You write code within the activity class to define how the UI elements behave when the user interacts with them.
  • Activities also play a crucial role in app navigation. They can launch other activities within your app to navigate to different screens or functionalities. For instance, clicking a button on the main screen might launch a new activity for viewing detailed information. If you use fragments in your app, all fragments must also be associated with an activity. However, if you are building a modern Android app using Jetpack Compose, you likely won’t have any fragments, and you may even have an app with just a single activity.

Lifecycle and System Interactions

  • Activities have a well-defined lifecycle that the Android system manages. This lifecycle includes methods like onCreate(), onStart(), onResume(), and onPause(), which are called at specific points in an activity’s lifetime (creation, becoming visible, going to the background, etc.).
  • You can override these lifecycle methods in your activity class to perform actions at specific points, such as fetching data when the activity starts or saving data when it goes into the background.
  • The system can also pause, resume, or destroy activities based on user actions or system events (like low memory). Your activity class should handle these lifecycle changes gracefully.

Intents

To indicate work or an action your app will perform in the future, you use the Intent object. Currently, your app has only one activity. But if you were to add another, you’d use an Intent to navigate between the two of them. Intents are incredibly flexible and can perform various tasks, such as communicating with other apps, providing data to processes, or starting up another screen.

Explicit Intents

  • Specificity: They’re like explicitly naming your destination. You directly specify the component (activity, service, etc.) within your app that you want to launch.
  • Use case: They’re ideal for internal app navigation, where you know exactly which activity to open within your app in response to a user action.
  • Example: Launching a settings activity within your app from the main activity.

Implicit Intents

  • Flexibility: They’re more like describing an action you want to be performed. Instead of a specific component, you define an action (like view, edit, dial) and optionally some data (like a website URL or phone number).
  • Use case: Useful for functionalities that can be handled by multiple apps. For instance, opening a link in a web browser or dialing a phone number. The system finds an app registered to handle that action and launches it.
  • Example: Clicking a link in your app that opens the user’s preferred web browser to view the linked webpage.

Content Providers

Content providers act as middlemen for managing data access between applications. They essentially create a standardized interface for sharing data securely.

Broadcast Receivers

Broadcast receivers in Android development act as messengers that listen for system-wide events or announcements from other apps. They allow your app to stay informed and react to these events even when the app itself isn’t actively running in the foreground.

The Role of the App Manifest

The app manifest file plays a crucial role in registering broadcast receivers and enabling them to function:

In Essence

  • The app manifest acts as a central point for declaring broadcast receivers and their intent filters.
  • Static registration in the manifest allows receivers to be active even when the app is in the background (with limitations on Android 8.0+).
  • The manifest provides information about the receiver to the system, enabling it to deliver relevant broadcasts.

Additional Points to Consider

  • Permissions: You might need to declare permissions in the manifest if the broadcasts you intend to receive require accessing certain resources or data.
  • Performance: While statically registered receivers offer convenience, they can impact battery life if they listen for frequent events. Consider dynamic registration or using alternative mechanisms like WorkManager for long-running tasks when appropriate.

Permissions

For security, you have to declare or request permission before using certain features on Android devices. Permissions protect access to restricted data and restricted actions.

Services

Another important component declared in the manifest is services, which are defined within the <service> tag. You use services to implement things like processes that run in the background or communications APIs. For example, Kodeco Chat might want to fetch messages in the background even when it’s not the app currently running and then notify the user that it’s received new messages.

Themes

Notice the <application> tag in the manifest has the following attribute:

Summary

Well, it’s been quite the whirlwind tour of the app manifest! By now, you should have an idea of its importance and role. In the next section, you’ll get an interactive demo of how to change various parts and functionality of your app through editing the manifest.
See forum comments
Download course materials from Github
Previous: Introduction Next: Demo