> For the complete documentation index, see [llms.txt](https://android-course.cornellappdev.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://android-course.cornellappdev.com/chapters/3.-intent-and-manifest/3.1-manifest.md).

# 3.4 Manifest

Every Android app, large or small, has a very important little file in the root folder called `AndroidManifest.xml` . This file describes crucial information about the app, including the application's name, the activities it holds, the permissions it requests, and the hardware and software requirements needed to run the app in the first place. Android Studio will handle the boilerplate code of the manifest when you first create the app, but often you will need to modify the file to suit your own needs.

The root element requires an attribute for your app's package name, which the build tools will use to resolve any relative classes in the package and generate the resources file.

{% code title="AndroidManifest.xml" %}

```markup
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.cornellappdev.android.pollo">
    ...
</manifest>
```

{% endcode %}

In the child `<application ...>` tag, these attributes specify project-specific information including where you set the app icon for your project.

Under the application tag is where most of the configuring will be done. For each activity that you create in your app, you **must** declare a corresponding XML activity element as a child of `<application ...>` in `AndroidManifest.xml`. Otherwise, that activity will never be seen by the system and can never be launched with an intent.&#x20;

An example manifest looks something like:&#x20;

{% code title="AndroidManifest.xml" %}

```xml
<manifest package="com.example.exampleproject" ... >
    <application ... >
        <activity android:name=".MainActivity">
            ...
        </activity>
    </application>
</manifest>
```

{% endcode %}

We can add a child element of type `intent-filter` to each `Activity` element. This is where an activity specifies what implicit intents the application can receive. In the manifest file for Google’s Gmail app, one of the activities would have the action `android.intent.action.SEND` under their intent filter, which allows the application to receive the implicit intent with action `Intent.ACTION_SEND`.

```markup
<activity ...>
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
    </intent-filter>
</activity>
```

The example below is of an activity that is recognized by the system as the entry point to this application (labeled with `action.MAIN`), and as something that shows up and can be launched from the app drawer - the area in your phone where all installed apps are stored (labeled with `category.LAUNCHER`).&#x20;

{% code title="AndroidManifest.xml" %}

```markup
<activity android:name=".MainActivity" ... >
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>
```

{% endcode %}

The manifest file is a small but mighty beast that controls activities, permissions, and implicit intents. If this file becomes messed up, then some issues will likely *manifest* their way into your application. *Heh* 🤭


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://android-course.cornellappdev.com/chapters/3.-intent-and-manifest/3.1-manifest.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.