Validate AndroidManifest.xml text before you merge

When to use this — and when not to

Use it when you are editing source or decompiled text XML: a hand-merged library manifest, a snippet from a stack overflow answer, or apktool output you want to sanity-check before you paste it back. It is also useful when Gradle’s merge failed and you want a second pair of eyes on well-formedness and the obvious missing blocks.

Do not drop a packaged APK here. The file inside the ZIP is binary AXML; DOMParser will report garbage or a parse error. Do not treat a green report as “Play will accept this.” We do not check android:exported on every component, intent-filter completeness for Android 12+, App Links verification, or Gradle namespace vs applicationId.

How the checks actually run

DOMParser.parseFromString(text, 'application/xml') is the first gate. If the document contains a parsererror node, we stop and print the browser’s parse message (unclosed tags, illegal characters, two roots). If the root is not <manifest>, that is a hard issue.

Next we read manifest@package and warn if it does not look like a dotted applicationId. We look for xmlns:android="http://schemas.android.com/apk/res/android", an <application> element, and <uses-sdk> with minSdkVersion. We collect uses-permission names (android namespace or prefix). We walk activities and their intent-filters for MAIN + LAUNCHER. Missing launcher is a warning — libraries, TV, and wear modules often have none.

Format is a naive pretty-printer: it inserts newlines between tags and indents. It is not an XML canonicalizer and can mangle unusual but valid constructs. Use it to read, not as a gold-file formatter for git.

Failure modes: Gradle often injects package / namespace from build.gradle, so a source file that looks “missing package” may still merge cleanly. Tools:namespace vs package on modern AGP is easy to misread. Binary AXML uploaded as .xml will fail parse.

Worked example

This fragment is valid XML but should warn:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.notes">
  <application android:label="Notes">
    <activity android:name=".MainActivity" />
  </application>
</manifest>

Expect: no critical parse issues; warning for missing uses-sdk; warning for no LAUNCHER activity; permissions count 0; activities 1. After Android 12, that activity is also the one you must set android:exported on once you add an intent-filter — this validator will not fail that yet. Add MAIN/LAUNCHER, then re-validate, then read exported rules in the APK guide.

Mistakes people make

• Validating the APK’s raw AndroidManifest.xml and concluding the project is corrupt. Decode first (apktool) or use aapt.
• Assuming a missing uses-sdk in source is fatal. AGP writes min/target from Gradle.
• Pretty-printing and committing the result, then fighting merge noise.
• Ignoring that package in the XML may no longer be the Play applicationId.

How this differs from aapt, lint, and Play Console

• aapt2 compiles and dumps the real merged manifest from the build.
• Android Lint knows exported, permissions, and SDK-specific rules.
• Play Console rejects upload-time identity and policy issues we never see.
• This page is a local well-formedness and “did I paste a real skeleton?” check.

Related

How to analyze APK files · Permissions Decoder · APK Analyzer

Frequently asked questions