Android manifest editor: change the text, then check it here

What people want an editor to do

An Android manifest XML editor, in the way the phrase is usually meant, is a place to change the file that will ship: package or namespace, SDK levels, permissions, the launcher activity, android:exported, and backup or debuggable flags. Android Studio’s manifest editor and the Merged Manifest tab are that place. They see library manifests, flavors, and the build type. A webpage that only holds the string you pasted cannot.

The Manifest Validator is the check after the edit. It parses with DOMParser. It requires a manifest root, a package attribute, and an application element. It warns on a missing Android namespace, a missing uses-sdk or minSdkVersion, a permission with no android:name, and no activity whose filter has both MAIN and LAUNCHER. Pretty-print only indents that same text. It does not insert attributes, it does not merge libraries, and it does not save a file back into an APK.

It never reads android:exported, android:debuggable, android:allowBackup, queries, or tools:node. You can add android:exported="true" in your editor, paste again, and the summary will look almost the same. The install on API 31 can still change. That limit is written up in exported components after Android 12.

Edit the text that will actually ship

Start from the variant you mean to install. src/main/AndroidManifest.xml is often incomplete. Debug overlays, product flavors, and AAR manifests are applied by the merger. A clean paste of main can hide a library activity that has an intent-filter and no exported value.

1. Open the module manifest in Android Studio and use the Merged Manifest tab for the variant you will ship. Copy that document, or open the merged file under app/build/intermediates after a successful assemble. The folder name has changed across Android Gradle Plugin versions. The tab is the stable view.
2. Make the edit in source, not only in the copied merged text. A hand edit of the merged file is discarded on the next build. Change src/main, the build-type manifest, or a tools:node / tools:replace marker so the merger keeps the change.
3. Rebuild. Paste the new merged text into the validator. Use the report for well-formed XML, the package attribute, uses-sdk, permission names, and a launcher activity.
4. Read android:exported yourself on every activity, activity-alias, service, and receiver that has an intent-filter when target SDK is 31 or higher.
5. Confirm with aapt dump badging and aapt dump xmltree on the APK. Badging prints the application id the package manager will use, which can differ from the package attribute when applicationId or a suffix is set in Gradle. The validator only prints the attribute in the text you pasted.

Since Android Gradle Plugin 7, a source manifest may omit package and still build, because namespace lives in Gradle. This validator then reports a missing package. That is a true statement about the text in the box. It is not a true statement about the build. Paste the merged document before you put the attribute back just to silence the page. The full version of that mistake is the merged manifest is not the XML you pasted.

A small edit, and what the checker will say

This is the sample already used on the validator page. It is a fixture, not a merged release manifest and not an app published here.

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.notes">
  <uses-sdk android:minSdkVersion="24" android:targetSdkVersion="34" />
  <uses-permission android:name="android.permission.INTERNET" />
  <application android:label="Notes">
    <activity android:name=".MainActivity">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>
  </application>
</manifest>

Pasted as-is, the report is package com.example.notes, one permission, one activity, launcher yes, no issues. The activity still has no android:exported. An editor’s useful change for an API 31 target is to set android:exported="true" on that launcher activity. Paste the edited text again. Issues stay at zero. You have to see the attribute in the XML yourself. The validator will not congratulate you for adding it.

Other edits the page will notice:

• Deleting package becomes an issue.
• Deleting application becomes an issue.
• A permission with no android:name becomes a warning. The name is not looked up. That is the permissions decoder.
• Removing the MAIN or LAUNCHER category becomes the launcher warning. Some libraries and TV apps should see that warning and ignore it.
• Changing minSdkVersion from 24 to another number does not change the verdict. The number is not compared with the version checker. API 24 is Android 7.0 and API 34 is Android 14 in that table. Look the number up there when you need the release name.

Binary AndroidManifest.xml from inside an APK is not editable on this page. Decode it first. How the viewer treats that binary file is in view an APK online.

When to stop using the browser

Use the validator after you have text and you want to know that it parses and contains the elements in the short list above. Use Android Studio when you need the merger, resource references, or a file that the next build will keep. Use aapt when you need the manifest the APK actually contains. Use Play Console when the question is policy, Data safety, or the target-API deadline. None of those answers come from pretty-print.

Related pages: the validator, the merged manifest, the publishing checklist, and the APK viewer guide.