Android Studio: Causes of “Program type already present” and How to Fix It

What Is Program type already present?

Program type already present
is an error that occurs when the same class is loaded from multiple locations
while building an Android app.

In Android apps,
multiple libraries can be combined using Gradle.

However,
if the same class is included in two or more libraries,
or if the same library has been added twice in different ways,
the same class is detected multiple times during the build.

As a result,
Program type already present
may be displayed and the build may stop.

Typical Error Message

Program type already present: com.example.SomeClass

In an actual error,
the fully qualified class name of the duplicated class is displayed after
Program type already present:.

For example,
it may appear in the following form.

Program type already present: android.support.v4.app.INotificationSideChannel

In this case,
check which library contains the displayed class,
and investigate whether multiple dependencies containing the same class have been added.

First, Check the Duplicate Class Name in Build Output

When
Program type already present
occurs,
first check the full error message in Android Studio’s Build Output.

In particular,
check the class name displayed after
Program type already present:.

Program type already present: com.example.library.SampleClass

From this class name,
check which library it may belong to.

Even if many errors are displayed,
they do not necessarily all have separate causes.

If an entire library is duplicated,
Program type already present
may be displayed for many classes contained in that library.

Cause 1: The Same Library Has Been Added Twice

The easiest cause to understand is a case in which
the same library has been added multiple times.

For example,
the same library may be written twice in the Gradle dependencies.

dependencies {
    implementation("com.example:sample-library:1.0.0")
    implementation("com.example:sample-library:1.0.0")
}

In this case,
remove the unnecessary one.

dependencies {
    implementation("com.example:sample-library:1.0.0")
}

Check
build.gradle
or
build.gradle.kts
and make sure the same library has not been added multiple times.

Cause 2: JAR or AAR Files and Gradle Dependencies Are Duplicated

If JAR or AAR files have been added manually to the
libs
folder,
and the same library is also being obtained through Gradle,
the same class may be included twice.

For example,
suppose the following file exists.

app/libs/sample-library.jar

And the same library is also added through Gradle.

implementation("com.example:sample-library:1.0.0")

In this state,
the same class may be loaded from both the JAR file and the Gradle dependency.

Check whether the JAR or AAR should be used directly
or obtained through Gradle,
and remove the unnecessary one.

Check the libs Folder

If you do not know the cause,
check the
libs
folder in the app module.

app/libs/

If old JAR or AAR files remain,
they may be duplicated with libraries currently being obtained through Gradle.

If you previously added a JAR file directly
and later changed to obtaining it through Gradle from a Maven Repository or another source,
check whether the old file remains.

Cause 3: Old Support Library and AndroidX Are Mixed

In older Android projects,
mixing the Android Support Library and AndroidX
may cause
Program type already present.

For example,
the app itself may use AndroidX,
while an older library depends on the
com.android.support
Support Library.

Check whether old Support Library dependencies remain in
build.gradle
or other files.

implementation("com.android.support:appcompat-v7:28.0.0")

In a project that has already migrated to AndroidX,
check whether the AndroidX library is being used.

implementation("androidx.appcompat:appcompat:VERSION")

Specify the version of AndroidX AppCompat to use in
VERSION.

Check the AndroidX Settings

In an older project that has been migrated to AndroidX,
also check
gradle.properties.

android.useAndroidX=true
android.enableJetifier=true

android.useAndroidX=true
is a setting for using AndroidX libraries.

android.enableJetifier=true
has been used to convert some dependencies that refer to the old Support Library
for use with AndroidX.

If the Android Gradle Plugin and all libraries being used already support AndroidX,
Jetifier may not be necessary.
Rather than simply adding settings from an old project,
check the support status of the libraries you are using.

Cause 4: Different Versions of the Same Library Are Included

Problems may also occur when different versions of the same library
are being loaded through multiple dependencies.

For example,
the app may directly add one library,
while another library also adds the same library internally as a dependency.

implementation("com.example:library-a:2.0.0")
implementation("com.example:library-b:1.0.0")

If
library-b
internally uses another version of
library-a,
check the dependencies.

Check the Gradle Dependency Tree

If you do not know which library is adding the duplicate dependency,
check the Gradle dependency tree.

From the Terminal in Android Studio,
run a command such as the following according to your project.

./gradlew app:dependencies

On Windows,
depending on the environment,
run it as follows.

gradlew app:dependencies

When executed,
the dependencies added to the app module are displayed in a tree format.

Look for a library related to the class shown in the error
and check whether the same dependency is being added through multiple paths.

Check the Dependency Source with dependencyInsight

If you want to check where a specific library is being added from,
you can use Gradle’s
dependencyInsight.

./gradlew app:dependencyInsight \
--dependency library-name \
--configuration debugRuntimeClasspath

This allows you to check which library is adding the specified dependency.

Depending on the build type you are using,
specify
releaseRuntimeClasspath
or another configuration instead of
debugRuntimeClasspath.

Solution 1: Remove Unnecessary Dependencies

Once you have identified the duplicate dependencies,
remove the unnecessary one.

If a library is directly specified
even though the same dependency is already being added through another library,
the direct specification may be unnecessary.

dependencies {
    implementation("com.example:library-a:1.0.0")
    implementation("com.example:library-b:1.0.0")
}

If
library-a
is being added through
library-b
and there is no need to specify it directly from the app,
the unnecessary direct dependency may be removable.

Solution 2: Exclude Duplicate Dependencies with exclude

If an unnecessary duplicate dependency is being added transitively from a required library,
Gradle’s
exclude
can be used.

In Kotlin DSL,
it can be specified in the following form.

implementation("com.example:library-a:1.0.0") {
    exclude(group = "com.example", module = "duplicate-library")
}

In Groovy DSL,
it takes the following form.

implementation("com.example:library-a:1.0.0") {
    exclude group: "com.example", module: "duplicate-library"
}

This excludes
duplicate-library
that is added from the specified library.

Solution 3: Align Library Versions

If the versions of related libraries are inconsistent,
consider aligning them to compatible versions.

In particular,
if you are using multiple libraries belonging to the same product or service,
check whether only some of them remain on older versions.

implementation("com.example:library-core:2.0.0")
implementation("com.example:library-ui:2.0.0")

Check the library’s official documentation and other information,
and use a supported combination.

Cause 5: Google Play services or Firebase Dependencies Are Duplicated

With services such as Google Play services and Firebase
that use many related libraries,
dependency problems may occur when old and new libraries are mixed.

In older Android projects in particular,
individually updating Google Play services-related libraries may result in
only some dependencies having different versions.

Check the versions and dependencies of the related libraries being used
and change them to a compatible configuration.

If you are using Firebase,
you can also manage the versions of related libraries using the Firebase BoM.

implementation(platform("com.google.firebase:firebase-bom:VERSION"))
implementation("com.google.firebase:firebase-analytics")
implementation("com.google.firebase:firebase-auth")

Specify the version of the Firebase BoM to use in
VERSION.

Cause 6: A Local Module and a Published Library Are Duplicated

If the same library is added as a local module
while the published version of the same library is also added through Gradle,
the same class may be included twice.

For example,
suppose a local module is added as follows.

implementation(project(":samplelibrary"))

And the same library is also added as an external dependency.

implementation("com.example:samplelibrary:1.0.0")

If the same classes are included in both,
use only one of them.

Cause 7: An Old Library Contains Dependency Library Classes Internally

Some older JAR or AAR files may directly include
classes from another required library internally.

In that state,
if the same library is separately added through Gradle,
the same class may be included twice.

In this case,
check whether a newer version of the library you are using is available.

If possible,
update to a newer version in which dependencies are properly separated.

Cause 8: Multiple Copies of the Same Class Exist in the Project

In addition to libraries,
also check whether multiple classes with the same fully qualified class name
exist in the app’s source code.

For example,
the following class may exist in multiple source sets.

com.example.app.SampleClass

Also check cases where an old class remains after copying a file,
or where both Java and Kotlin versions of the same class remain.

Also Check Source Sets Such as debug and release

In an Android project,
source sets such as
debug,
release,
and Product Flavors can be used in addition to
main.

If the same class is placed in multiple source sets,
duplication may occur depending on the build variant configuration.

src/main/java/
src/debug/java/
src/release/java/

If the error occurs only with a specific build variant,
also check the source set configuration.

Run Gradle Sync After Fixing Dependencies

If you modify
build.gradle
or
build.gradle.kts,
run Gradle Sync.

Synchronize Gradle in Android Studio
to apply the modified dependencies to the project.

After that,
build the app again and check whether
Program type already present
has been resolved.

Run Clean or Rebuild

If the error remains even after fixing the dependencies,
old build results or intermediate files may still remain.

From the
Build
menu in Android Studio,
perform the equivalent of Clean or Rebuild available in the version of Android Studio you are using.

After that,
build the app again and check whether the error has been resolved.

If Program type already present Still Cannot Be Resolved

If the error is not resolved,
check the sources of duplication one by one based on
the fully qualified class name shown in the error.

When Many Program type already present Errors Are Displayed

Many
Program type already present
errors may be displayed in Build Output.

Even in this case,
it does not necessarily mean that every class must be fixed individually.

If an entire JAR or library is duplicated,
the same error will be displayed for many classes contained in that library.

Check whether the first several classes displayed
belong to the same library,
and investigate duplication at the library level.

Even if many
Program type already present
errors are displayed,
it does not necessarily mean that a large amount of Java or Kotlin code must be modified.
Removing a single duplicated library or JAR may resolve many errors at once.

Difference from Duplicate class found in modules

Program type already present
and
Duplicate class ... found in modules ...
have different display formats,
but both may occur when the same class is being loaded from multiple locations.

In projects using older versions of Android Studio or the Android Gradle Plugin,
Program type already present
may be displayed,
while in newer build environments,
Duplicate class found in modules
may be displayed.

Therefore,
the basic checking method is the same for both errors,
and it is important to identify the dependency source of the duplicated class.

Summary

Android Studio’s
Program type already present
is an error that occurs when the same class is being loaded
from multiple libraries or modules.

First, check the class name shown in Build Output,
then check Gradle dependencies,
JAR or AAR files in the
libs
folder,
whether the Support Library and AndroidX are mixed,
local modules,
and other possible causes.

If you do not know the source of the dependency,
using
./gradlew app:dependencies
or
dependencyInsight
allows you to check which library is adding the dependency.

Once you have identified the duplicate dependency,
resolve it by removing unnecessary libraries,
organizing JAR and AAR files,
aligning library versions,
organizing the project around AndroidX,
or using
exclude
as necessary.

When resolving
Program type already present,
it is important not to directly delete the class shown in the error,
but to check
“why the same class is being loaded from multiple locations.”
Identify the dependency that is causing the duplication,
determine which one should remain,
and then make the correction.