AndroidManifest.xml: The Blueprint for Your App

AndroidManifest.xml is the blueprint for your app, telling the OS its components, permissions, and requirements before running any code. A missing declaration here is a common source of runtime crashes, as the OS simply won't see your component.
WHY IT EXISTS: The Android OS needs a standardized way to understand an app's structure and requirements before executing its code. It can't just scan all the code files to figure out what screens or services exist. This manifest provides a single, machine-readable summary for the system, the Google Play Store, and development tools.
THE MENTAL MODEL: AndroidManifest.xml is your app's table of contents and configuration file, rolled into one. Before the Android system runs a single line of your Kotlin or Java code, it reads this file to learn about your app's identity, what components it contains (like screens and background services), and what permissions it needs to function. It's a contract between your app and the OS.
HOW IT WORKS: It's an XML file located at the root of your project's source set. The root element is <manifest>, which contains other elements. Key elements include: <application> for app-level properties like its icon, label, and theme; <activity>, <service>, <receiver>, and <provider> to declare each of your app's main components; <uses-permission> to request permissions from the user, such as android.permission.INTERNET; and <uses-feature> to declare hardware or software features the app requires, like a camera. The build tools merge this manifest with manifests from any libraries you use into a single file for the final app package.
WHEN TO USE IT: You will edit this file whenever you add a new screen (Activity), background task (Service), or other major component. It's also where you go to request a new permission, declare support for an intent filter so other apps can launch yours (e.g., opening a specific type of link), or set app-wide metadata and configuration flags.
WHEN NOT TO USE IT: Don't use the manifest for dynamic, runtime configuration. It's a static declaration file that is read when the app is installed and launched. For values that change while the app is running, use other mechanisms like SharedPreferences, databases, or remote config. The manifest is for declaring what your app is, not how it's currently behaving.
ONE CANONICAL EXAMPLE: A classic beginner mistake is creating a new screen but forgetting the manifest entry. If you create a SettingsActivity.kt file for a settings screen, you must also add an <activity> tag for it inside the <application> block of the manifest: <activity android:name=".SettingsActivity"></activity>. If you forget this step, your code will compile, but trying to launch the settings screen will crash your app with an ActivityNotFoundException. From the OS's perspective, that screen simply doesn't exist.
Read the original → developer.android.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.