What the APK Manifest Viewer does
This viewer opens an Android APK in your browser and decodes its compiled AndroidManifest.xml back into readable XML, then lists the package name, version, minimum and target SDK, every permission requested with its protection level, and every activity, service, broadcast receiver and content provider with whether other apps can reach it.
An APK is a ZIP archive whose manifest is stored in Android's binary XML format, so opening it in a text editor shows only noise. The decoding happens on your device; the APK is never uploaded, installed or run.
How to use it
- Drop an .apk file onto the page or choose one. A compiled AndroidManifest.xml extracted from an APK also works.
- Read the headline for the package name and version, and the tiles for SDK levels, permission count and exported components.
- Check the findings: problems are settings that are unsafe in a release build or that break installation; warnings and notes are worth a second look.
- Use the permission and component tables, open the decoded XML, and download the XML, a JSON summary or a components CSV.
Reading the results
Exported means another app can start the activity, bind to the service, send to the receiver or query the provider. A component is exported if it says android:exported="true"; without the attribute, one with an intent filter is exported, and a content provider is exported only for apps targeting API 16 or lower.
Protection levels come from Android's Manifest.permission reference as stored in a dated data file. Dangerous permissions need a runtime prompt; signature permissions are granted only to apps signed with the same key; custom permissions from other apps are shown as custom, not guessed.
Values such as @0x7f120001 are references into the app's compiled resources (resources.arsc). The viewer shows the reference rather than inventing the text it points to.
Worked example: the synthetic shop app
The example is a small APK built by A2Z with a hand-written binary manifest for com.example.shop, version 2.3.1 (code 42), minimum SDK 24 and target SDK 34. It requests INTERNET (normal), CAMERA (dangerous) and one custom permission.
.DeepLinkActivity has an intent filter for https://shop.example.com/p/ but no android:exported. Because the app targets API 34, which is 31 or higher, Android refuses to install it - reported as a problem. .OrdersProvider is exported with no read or write permission, so any app could query it, and the application sets android:debuggable="true": two more problems.
The app also defines com.example.shop.PUBLIC with no protection level, which defaults to normal, so any app may hold it - a warning. The launcher activity .MainActivity is exported on purpose and is not flagged.
What the checks are based on
The export rules, the Android 12 requirement to declare android:exported on components with intent filters, debuggable, allowBackup and usesCleartextTraffic all come from the Android developer documentation for the manifest and its elements. Which findings count as problems rather than warnings is an A2Z judgement, stated in each finding's text.
Binary XML is read chunk by chunk following the layout in Android's ResourceTypes.h: a string pool (UTF-8 or UTF-16), a resource-ID map, then namespace and element chunks with typed attribute values. When an obfuscated APK strips attribute names, the viewer falls back to the attribute's resource ID for the common android attributes.
Limitations: what the result does not prove
- It reads the manifest only. It does not scan code, native libraries, trackers or network behaviour, and a clean result is not a security review.
- App bundles (.aab) store the manifest as protobuf and split sets (.apks, .xapk) contain several APKs; the viewer explains these rather than guessing. Build a universal APK or extract the base APK first.
- Signatures are not verified. The viewer only notes whether v1 signature files are present; v2 and v3 signature blocks are outside the ZIP entries.
- Resource references (labels, icons, themes) are shown as IDs, and manifest placeholders are shown as the build left them.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- Android Developers - App manifest overview - checked 19 Sep 2026
- Android Developers - Manifest.permission
- Android Developers - activity element (android:exported)
- Android Developers - provider element
- Android source - ResourceTypes.h (binary XML layout)
Frequently asked questions
Why does AndroidManifest.xml look like binary garbage when I unzip an APK?
The build tools compile it into Android's binary XML format, which stores strings in a pool and attributes as typed values. It has to be decoded - as this viewer or aapt2 dump xmltree does - before it reads as XML again.
How can I see which permissions an APK asks for before installing it?
Open it here: every uses-permission element is listed with its protection level, and dangerous permissions are counted separately. This shows what the app can request, not whether it will actually use each permission.
What does android:exported do?
It says whether components of other apps can launch or bind to this one. Since Android 12, any activity, service or receiver with an intent filter must declare it explicitly, and a missing value makes installation fail for apps targeting API 31 or higher.
Is an exported component always a security problem?
No. The launcher activity, deep-link handlers and share targets must be exported to work. The risk is a component exported by accident or without a permission when it performs sensitive actions, so each flagged item is a prompt to check intent, not a verdict.
Can I open an .aab file from Google Play Console?
Not directly. An Android App Bundle stores its manifest in protobuf rather than binary XML. Use bundletool build-apks with universal mode to produce an APK, then open that APK here.
Is it safe to open an APK here?
The file is read as bytes in your browser and nothing inside it is executed or uploaded. The reader checks every offset against the file size and caps entries and decompressed size, so a malformed APK produces an error rather than a hang.
Last reviewed by the A2Z.Tools team against the sources listed above.
