The Android manifest is a core file that describes an app to the system. It names the package and the main activity and the app label. It lists permissions that the app requests from the user. It lists activities and services and receivers and providers. It also lists intent filters that let other apps start a component. Reading the manifest gives a fast map of an app. That map shows what the app can do before it runs. It also shows what data the app can reach. Analysts start with the manifest for a good reason. It is small and structured and rich in clues. A careful manifest review can reveal a hidden capability in minutes. It can also reveal a permission that does not match the visible features. That mismatch deserves a closer look. For a wider study see APK reverse engineering basics.
A manifest file in a decoded APK appears as readable XML. APKTool decodes the binary form into that XML form. The root element holds the package name and version details. A child element holds application settings like theme and icon. Other child elements hold each component with its own settings. Each component can carry an exported flag. That flag states whether other apps can start the component. An exported component can be a security risk when it lacks protection. A non exported component stays private to the app. Checking exported flags is a key step in manifest review. It reveals entry points that an outside app could use. Those entry points need permission checks or other guards.
Permissions And What They Mean
Permissions in the manifest state what the app may access. A camera permission allows photo and video capture. A location permission allows position data in the background or foreground. A contacts permission allows reading address book entries. A storage permission allows reading files in shared storage. Each permission should match a visible feature. A torch app that asks for contacts deserves a question. A photo app that asks for location may have a map feature. Context decides whether a permission is reasonable. Analysts note each permission and the feature that needs it. A permission with no matching feature is a red flag. It may be leftover code or it may be hidden use. Further study of code can resolve that question.
Permission levels also matter in manifest review. Normal permissions pose low risk and grant at install. Dangerous permissions pose higher risk and need user approval at run time. Signature permissions stay within apps signed by the same key. Custom permissions can protect a component from other apps. A manifest can declare a custom permission for its own use. That declaration shows how the developer guards a sensitive component. Analysts should note custom permissions and their protection levels. A weak level on a sensitive component is a problem. A strong level on a public component may break a planned feature. Balance between protection and function is the goal.
Components Hidden In Plain Sight
Activities are the screens of an app. Services run work in the background without a screen. Receivers listen for system events like boot or a message. Providers share data with other apps in a controlled way. The manifest lists all of these components. Some components have no launcher icon. Some components run only on a system event. Some components serve other apps through a defined interface. Hidden does not always mean harmful. A sync service has no screen by design. A boot receiver has no screen by design. A data provider has no screen by design. Analysts judge a component by its purpose and its guards. A component with a clear purpose and a guard is normal. A component with no purpose and no guard needs study.
Intent filters deserve special attention in component review. An intent filter states which actions a component can handle. A filter for viewing web links can make an app a browser choice. A filter for sharing text can make an app a share target. A filter for a custom action can link two apps from the same developer. A broad filter can attract intents from many apps. Broad filters need input validation in code. Without validation a broad filter can accept harmful data. Analysts list each filter and the data it accepts. They then check code for validation of that data. That pair of checks reveals many real flaws.
Deep Links And App Links
Deep links let a web link open a specific screen in an app. The manifest declares the link pattern in an intent filter. A pattern includes a scheme and a host and a path. A web scheme with a verified host becomes an app link. A custom scheme works without web verification. Deep links are useful for sharing content. They are also a risk when they lack validation. A link that opens a payment screen needs a strong check. A link that opens a settings screen needs a check too. Analysts test deep links with a test device. They send a crafted link and watch the result. A safe app validates the link before acting. An unsafe app trusts the link at once. That trust can be abused by a malicious page.
App link verification adds a web check to deep links. The app domain must host a verification file. The system checks that file before granting link handling. Without that file the link opens a chooser or a browser. With that file the app opens directly. Analysts check the manifest for auto verify flags. They also check whether the domain file exists. A missing file can mean a broken feature. A present file can mean a working app link. Either result informs the review. Deep link testing belongs in a safe test environment. Use a test account and a spare device for all link tests.
Practical Manifest Review Steps
A practical review follows a fixed order. Open the decoded manifest in a text editor. Read the package name and version first. List all permissions next in your notes. List all components next with exported flags. List all intent filters next with schemes and hosts. Note any component that looks out of place. Note any permission that lacks a visible feature. Note any exported component without a permission guard. That short list becomes the focus for code study. Code study then confirms or clears each note. That workflow keeps manifest review fast and useful. It also stops a reviewer from drowning in details. For code study that follows this step see DEX code and Smali layouts.
A review checklist helps keep the work consistent. Check for a backup flag that allows app data backup. Check for a cleartext traffic flag that allows plain network use. Check for a debuggable flag that should be off in release. Check for a large heap flag that changes memory limits. Check for a network security config reference. Each flag tells a story about the build. A debuggable release build is a serious flaw. A cleartext flag may be needed for a legacy server. Context and code study decide the final judgement. Record each flag with a short note on its meaning. That record helps a developer fix a real issue fast.
apktool d sample.apk -o sample-out
cat sample-out/AndroidManifest.xml
grep -n "uses-permission" sample-out/AndroidManifest.xml
grep -n "exported" sample-out/AndroidManifest.xmlCommon Manifest Pitfalls
Common pitfalls appear in many apps. An exported activity without a guard tops the list. An exported receiver without a guard follows close behind. A broad intent filter without validation is another common flaw. A leftover test component in a release build is also common. A test component may open a debug screen. A debug screen may expose internal data. A permission request for a removed feature is a softer flaw. It confuses users and weakens trust. It may also trigger a store policy review. Analysts should report each pitfall with evidence. Evidence includes the manifest lines and the test result. A clear report helps a developer fix the issue.
Manifest review also has limits that analysts must respect. The manifest shows declared capabilities only. It does not show code that runs through reflection. It does not show native code behaviour. It does not show server side logic. A clean manifest does not prove a safe app. A messy manifest does not prove a harmful app. Code study and dynamic testing complete the picture. Treat the manifest as a map rather than a verdict. A map guides the journey but does not replace it. That humble view keeps analysis honest and useful.
Testing Manifest Findings Live
Manifest findings need live confirmation before they become claims. An exported component may look risky in the manifest. Code may still guard it with a permission check. A permission may look unused in the manifest. Code may still use it through a dynamic path. Test each finding on a spare device. Try to start the exported component from another test app. Watch the result and the log for a guard. That test turns a manifest hint into evidence. It also stops a false alarm from reaching a developer. For dynamic testing methods see Frida dynamic code injection.
Live testing also reveals components that the manifest hides. Code can register a receiver at run time. Code can start a service without a manifest entry in some cases. Logs show those dynamic components during a run. Network logs show hosts that the manifest never mentions. Combine manifest review with live logs for a full picture. That combination catches tricks that either method alone would miss. It also gives a developer a complete report. A complete report earns trust and a faster fix.
- Test exported components from another test app.
- Watch logs for permission guards.
- Combine manifest review with live logs.
- Report only findings confirmed by a test.
Manifest Review For Different App Types
A manifest review changes with the type of app. A messaging app may request contacts and notifications. A camera app may request camera and storage. A banking app may request biometric hardware. Each request should match the app purpose. A mismatch in any type deserves a question. A game that requests contacts deserves a question. A calculator that requests location deserves a question. Type context helps a reviewer judge a permission. It also helps a reviewer spot a hidden capability fast.
A system app manifest differs from a store app manifest. A system app may hold signature permissions. A system app may declare protected components. A store app cannot hold those permissions in most cases. Analysts should note the app source when reviewing a manifest. A system app with broad access may be normal. A store app with the same access may be suspicious. That source context prevents false alarms. It also prevents missed alarms for store apps.
Manifest review for a work app also differs. A work app may use device admin features. A work app may enforce password rules. A work app may restrict other apps. Those features appear in the manifest and in code. A reviewer should check the admin receiver and its policies. A reviewer should check whether policies match the stated purpose. A work app that overreaches its purpose needs a report. A work app that matches its purpose is normal. Context again decides the judgement.
Updates can change a manifest in important ways. A new version may add a permission. A new version may add a component. A new version may add a deep link pattern. Compare the manifest across versions when possible. Note each addition with a short reason. An addition without a visible feature needs study. An addition with a visible feature is likely normal. Version comparison turns a static file into a change story. That story helps users understand an update.
Conclusion
Inspecting a manifest is a fast and powerful first step. It reveals permissions and components and intent filters. It reveals exported entry points and deep link patterns. It reveals build flags that affect security. A fixed review order keeps the work consistent. Code study and live testing then confirm each finding. Beginners should practise on their own test apps first. They should build a checklist and keep clear notes. That habit turns a small XML file into a rich source of insight.
The steps above follow the approach described in the official developer documentation for Android applications and in widely used testing guidance for mobile software.
