The AndroidManifest — your app's ID card

The one file Android reads first

Your app is thousands of lines of Kotlin. Android has read none of them.

Before your app runs, and in fact at the moment it is installed, Android reads exactly one file to find out what this app is: AndroidManifest.xml. Everything the system knows about you — your name, your icon, which screen opens first, what you are allowed to ask for — comes from that file and nowhere else.

Get it wrong and your app will not appear on the home screen, or will refuse to start, or will be denied something it needs, and none of those failures will point at your Kotlin. So it is worth nine minutes.

The whole file

This is the complete manifest from Dice Duel, the first app you build in Part 5. Not a simplified version — this is the real file, all twenty-six lines.

That is the entire file. There is no hidden extra part — this manifest is enough to describe a complete, installable, publishable Android app.

What is not in the manifest any more

If you look at an Android tutorial written before about 2018, you will see a <uses-sdk> block in the manifest holding minSdkVersion and targetSdkVersion, plus versionCode and versionName up on the <manifest> tag.

Those have all moved into app/build.gradle.kts:

1defaultConfig {
2  applicationId = "com.nativeworks.diceduel"
3  minSdk = 26
4  targetSdk = 35
5  versionCode = 1
6  versionName = "1.0"
7}

They still end up in the manifest — the Android Gradle Plugin injects them during the build — but you write them in one place, in Kotlin, where they can differ between a debug and a release build. Lesson 2.7 is entirely about those SDK numbers, and versionCode comes back in Part 6.

Permissions

Anything genuinely sensitive has to be declared, in public, in this file. If it is not in the manifest, your app simply cannot do it — there is no way to ask at runtime for something you never declared.

Focus Flow, the third app in this course, asks for exactly one:

1<uses-permission
2  android:name="android.permission.POST_NOTIFICATIONS" />

Declaring a permission is only half the job. For sensitive ones, you must also ask the user at runtime, and they may say no — your app has to still work when they do. Lesson 5.17 does this properly.

The habit worth forming now: declare the fewest permissions you can. Every one of them is shown to the user before they install, and a list of five for a dice game is a list of five reasons not to bother.

Your manifest is not the manifest that ships

Here is a genuinely surprising fact. The file above is not what ends up inside your APK.

Every library you depend on ships its own tiny manifest. Compose needs a couple of declarations. The lifecycle library installs a startup component. A build step called the manifest merger combines yours with every one of theirs into a single merged manifest, and that is what gets packaged.

You can read the whole merge decision, in order, in a real file the build writes:

app/build/outputs/logs/manifest-merger-debug-report.txt

Open it and you will find lines like this — this is genuine output from building Dice Duel:

1MERGED from [androidx.activity:activity-compose:1.9.3]
2MERGED from [androidx.compose.ui:ui-android:1.7.6]
3MERGED from [androidx.lifecycle:lifecycle-process:2.8.7]

Thirty-odd libraries, each contributing a line or two. It is the best possible answer to "where did that thing in my manifest come from?" — and the first place to look when the merger refuses to merge, which is the most common failure in this whole lesson.