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

> Perform deep analysis on Android application manifest files. Learn to extract launcher activity, components, permissions, and custom classes for reverse engineering.

- Repository: [Simone Avogadro/android-reverse-engineering-skill](https://github.com/SimoneAvogadro/android-reverse-engineering-skill)
- Tags: how-to-guide
- Published: 2026-04-17

---

**The android-reverse-engineering skill extracts the launcher activity, application components, permissions, and custom Application class from [`AndroidManifest.xml`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/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`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/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`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/SKILL.md) (lines 91-96) and the reference guide [`call-flow-analysis.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/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`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/plugins/android-reverse-engineering/skills/android-reverse-engineering/references/call-flow-analysis.md), isolate specific component declarations:

```bash

# 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:

```bash
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`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/SKILL.md) | Describes **Phase 3 – Analyze Structure** (lines 91-96), outlining the workflow to read [`AndroidManifest.xml`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/AndroidManifest.xml) and identify entry points. | [`plugins/android-reverse-engineering/skills/android-reverse-engineering/SKILL.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/plugins/android-reverse-engineering/skills/android-reverse-engineering/SKILL.md) |
| [`call-flow-analysis.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/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`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/plugins/android-reverse-engineering/skills/android-reverse-engineering/references/call-flow-analysis.md) |
| [`decompile.sh`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/decompile.sh) | Handles XAPK/APK extraction; ensures the manifest is available at [`resources/AndroidManifest.xml`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/resources/AndroidManifest.xml) for subsequent analysis. | [`plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/decompile.sh`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/decompile.sh) |
| [`README.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/README.md) | Overview mentioning manifest analysis as part of "Analyzes app structure: manifest, packages, architecture patterns". | [`README.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/README.md) |

## Practical Example: Analyzing a Decompiled APK

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

```bash

# 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:

```text
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:

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

```

## Summary

- The **android-reverse-engineering skill** analyzes [`AndroidManifest.xml`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/AndroidManifest.xml) as the first structural step after APK decompilation, as defined in **Phase 3** of [`SKILL.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/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`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/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`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/call-flow-analysis.md) and executed during **Phase 3** of the analysis workflow defined in [`SKILL.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/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`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/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.