Introduction

In Android, a custom Application class gives you one place to initialize app-wide state before any activity starts. It only runs if Android knows about it, which is why you must register it in the manifest.

What the Application Class Is For

Application is the process-level entry point for your app. Android creates it before launching your first activity, service, or receiver in that process. That makes it a reasonable place for work that truly belongs to the whole app, such as:

• setting up logging
• initializing dependency injection
• configuring analytics
• creating singletons that live for the process

It is not the right place for screen-specific state, network calls that can wait, or anything that makes startup noticeably slower.

Here is a minimal custom implementation in Kotlin:

1package com.example.app
2
3import android.app.Application
4import android.util.Log
5
6class MyApp : Application() {
7    override fun onCreate() {
8        super.onCreate()
9        Log.d("MyApp", "Application started")
10    }
11}

This class exists, but Android will not instantiate it until you declare it in AndroidManifest.xml.

How to Register It in the Manifest

The registration happens on the application element through the android:name attribute.

1<manifest xmlns:android="http://schemas.android.com/apk/res/android"
2    package="com.example.app">
3
4    <application
5        android:name=".MyApp"
6        android:allowBackup="true"
7        android:label="@string/app_name"
8        android:supportsRtl="true"
9        android:theme="@style/Theme.App">
10
11        <activity
12            android:name=".MainActivity"
13            android:exported="true">
14            <intent-filter>
15                <action android:name="android.intent.action.MAIN" />
16                <category android:name="android.intent.category.LAUNCHER" />
17            </intent-filter>
18        </activity>
19    </application>
20
21</manifest>

If the class is in the same package as the app, .MyApp is enough. If it lives elsewhere, use the full package name.

<application
    android:name="com.example.core.MyApp"
    android:theme="@style/Theme.App" />

Once that attribute is present, Android creates MyApp during process startup and calls onCreate.

When You Actually Need a Custom Application

Many apps do not need one at all. If you only wanted a shared helper object, a dependency injection container or a lazily created singleton may be cleaner. Use a custom Application class when the work is truly app-wide and should happen once per process.

Common examples include setting up Hilt, WorkManager configuration, or a crash reporter.

1package com.example.app
2
3import android.app.Application
4import dagger.hilt.android.HiltAndroidApp
5
6@HiltAndroidApp
7class MyApp : Application()

In that case, the manifest still needs the class name, unless your build setup injects it through a generated manifest merge. In normal app code, checking the merged manifest is the safest way to confirm what will ship.

How to Verify It Is Working

The simplest test is to log from onCreate and launch the app. You can also inspect the merged manifest in Android Studio to confirm that the android:name value is present after manifest merging from libraries and build variants.

If you are debugging startup issues, keep onCreate short. A lightweight sanity check is fine:

1class MyApp : Application() {
2    override fun onCreate() {
3        super.onCreate()
4        check(BuildConfig.APPLICATION_ID.isNotBlank())
5    }
6}

That kind of validation is acceptable. Heavy I/O or long synchronous setup is not.

Common Pitfalls

• Creating the class but forgetting to register it. The app still runs, but your custom startup code never executes.
• Using the wrong package name in android:name. This usually shows up as a startup crash because Android cannot instantiate the class.
• Putting too much work in onCreate. Slow initialization hurts cold start time.
• Treating Application as a global dump for mutable state. That makes testing and lifecycle management harder.
• Forgetting about manifest merging. A library or product flavor can change the final manifest, so inspect the merged result when behavior is unexpected.

Summary

• A custom Application class is optional and should be used only for real app-wide startup work.
• Register it in AndroidManifest.xml with the android:name attribute on the application element.
• Use a relative class name such as .MyApp only when it is in the app package.
• Keep onCreate small and avoid heavy blocking work during process startup.
• If registration seems correct but the class is not used, inspect the merged manifest for the final value.