How to Analyze an Android Application's Manifest File for Reverse Engineering

The android-reverse-engineering skill extracts the launcher activity, application components, permissions, and custom Application class from AndroidManifest.xml using targeted grep commands to map the complete app structure.

When decompiling an APK or XAPK with the SimoneAvogadro/android-reverse-engineering-skill, analyzing the AndroidManifest.xml represents the critical first step in understanding application architecture. This systematic manifest file analysis reveals every entry point, declared permission, and component class name, providing the essential roadmap needed for deeper code investigation and call-flow tracing.

What Data Is Extracted from the AndroidManifest.xml

The skill performs systematic extraction of six key data categories from the manifest file located at <output-dir>/resources/AndroidManifest.xml. Each extraction targets specific XML attributes that reveal the application's architecture, capabilities, and entry points.

Entry Points and Launcher Activity

The launcher activity represents the primary user-facing entry point of the application. The skill identifies the <activity> element containing an <intent-filter> with both android.intent.action.MAIN and android.intent.category.LAUNCHER. This component serves as the natural starting point for call-flow tracing and dynamic analysis.

Application Components

The manifest analysis extracts the android:name attributes for all four major Android component types:

• Activities – UI screens and user interaction handlers
• Services – Background operations and long-running tasks
• BroadcastReceivers – System and application event listeners
• ContentProviders – Data sharing and storage interfaces

Permissions and Configuration

The skill captures declared permissions (such as INTERNET, ACCESS_NETWORK_STATE, and READ_EXTERNAL_STORAGE) to identify network capabilities, security requirements, and potential attack surfaces. It also extracts the custom Application class specified in the android:name attribute of the <application> tag, which typically bootstraps dependency injection frameworks, global HTTP client configuration, and initialization logic.

How the Manifest Analysis Is Performed

According to the source code in SKILL.md (lines 91-96) and the reference guide call-flow-analysis.md (lines 5-30), the skill does not rely on custom XML parsers. Instead, it executes targeted grep commands on the decompiled manifest file to extract structural information efficiently and reliably across different APK formats.

Grep Patterns for Component Extraction

The following commands, documented in plugins/android-reverse-engineering/skills/android-reverse-engineering/references/call-flow-analysis.md, isolate specific component declarations:

# List all Activities

grep -n 'android:name=.*Activity' resources/AndroidManifest.xml

# List all Services

grep -n 'android:name=.*Service' resources/AndroidManifest.xml

# List BroadcastReceivers

grep -n '<receiver' resources/AndroidManifest.xml

# List ContentProviders

grep -n '<provider' resources/AndroidManifest.xml

Locating the Launcher Activity

To identify the main entry point, the skill uses a chained grep pattern that searches for the MAIN action and captures the associated activity name:

grep -A5 'MAIN' resources/AndroidManifest.xml | grep 'android:name'

This command extracts the android:name value from the activity containing the MAIN/LAUNCHER intent filter, revealing the class that serves as the application's primary entry point.

Key Source Files in the Repository

The manifest analysis logic is distributed across several files in the SimoneAvogadro/android-reverse-engineering-skill repository:

File	Role in Manifest Analysis	Location
SKILL.md	Describes Phase 3 – Analyze Structure (lines 91-96), outlining the workflow to read AndroidManifest.xml and identify entry points.	plugins/android-reverse-engineering/skills/android-reverse-engineering/SKILL.md
call-flow-analysis.md	Provides the exact grep commands and patterns used to extract components and the launcher activity.	plugins/android-reverse-engineering/skills/android-reverse-engineering/references/call-flow-analysis.md
decompile.sh	Handles XAPK/APK extraction; ensures the manifest is available at resources/AndroidManifest.xml for subsequent analysis.	plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/decompile.sh
README.md	Overview mentioning manifest analysis as part of "Analyzes app structure: manifest, packages, architecture patterns".	README.md

Practical Example: Analyzing a Decompiled APK

After running the decompilation script, navigate to the output directory and execute the manifest analysis commands:

# Navigate to the decompiled resources

cd <output>/resources

# View the complete manifest structure

cat AndroidManifest.xml

# Extract all entry points

grep -n 'android:name=.*Activity' AndroidManifest.xml
grep -n 'android:name=.*Service'  AndroidManifest.xml
grep -n '<receiver'               AndroidManifest.xml
grep -n '<provider'               AndroidManifest.xml

# Identify the launcher activity

grep -A5 'MAIN' AndroidManifest.xml | grep 'android:name'

# Check network permissions

grep -n '<uses-permission' AndroidManifest.xml

Sample output showing extracted components:

81:    <activity android:name=".ui.MainActivity"
85:    <service android:name=".service.SyncService"
90:    <receiver android:name=".receiver.NetworkChangeReceiver"
95:    <provider android:name=".provider.AppProvider"
110:    <uses-permission android:name="android.permission.INTERNET"/>

Once you identify the launcher activity (e.g., MainActivity), search the decompiled sources to begin call-flow tracing:

grep -rn 'MainActivity' <output>/sources/

Summary

• The android-reverse-engineering skill analyzes AndroidManifest.xml as the first structural step after APK decompilation, as defined in Phase 3 of SKILL.md.
• It extracts the launcher activity, all application components (Activities, Services, BroadcastReceivers, ContentProviders), permissions, and the custom Application class using targeted grep commands.
• The analysis relies on patterns documented in call-flow-analysis.md (lines 5-30) and executes commands against <output-dir>/resources/AndroidManifest.xml without requiring custom XML parsers.
• Extracted manifest data drives subsequent reverse engineering phases, including lifecycle method tracing and API call location.

Frequently Asked Questions

What information can you extract from an AndroidManifest.xml during reverse engineering?

During reverse engineering, you can extract the launcher activity (main entry point), all component classes (Activities, Services, BroadcastReceivers, ContentProviders), declared permissions (such as INTERNET or ACCESS_NETWORK_STATE), the custom Application class, and the package name. This data reveals the application's architecture, security requirements, and potential attack surfaces.

How does the android-reverse-engineering skill find the main entry point of an app?

The skill locates the main entry point by searching for the MAIN/LAUNCHER intent filter using the command grep -A5 'MAIN' resources/AndroidManifest.xml | grep 'android:name'. This extracts the android:name attribute of the activity containing both android.intent.action.MAIN and android.intent.category.LAUNCHER, identifying the UI component that launches when the user taps the app icon.

What grep commands are used to analyze the Android manifest file?

The skill uses specific grep patterns to isolate components: grep -n 'android:name=.*Activity' for activities, grep -n 'android:name=.*Service' for services, grep -n '<receiver' for broadcast receivers, and grep -n '<provider' for content providers. These commands are documented in call-flow-analysis.md and executed during Phase 3 of the analysis workflow defined in SKILL.md.

Where does the skill look for the manifest file after decompiling an APK?

After decompilation, the skill expects the manifest file at <output-dir>/resources/AndroidManifest.xml. The decompile.sh script ensures the manifest is extracted to this specific location for both standard APK and XAPK formats, making it immediately available for the grep-based analysis commands in subsequent phases.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}