Home » Android » firebase – Error: AGPBI: Program type already present: com.google.android.gms.auth.api.signin.internal.zzg

firebase – Error: AGPBI: Program type already present: com.google.android.gms.auth.api.signin.internal.zzg

Posted by: admin June 15, 2020 Leave a comment

Questions:

In my Adrdoi app, where I use Google Login and Firebase Cloud Messaging, I get this error message:

AGPBI: {"kind":"error","text":"Program type already present: com.google.android.gms.auth.api.signin.internal.zzg","sources":[{}]}

Does that mean that the google auth lib was already used somewhere else? Whats that from?

How to&Answers:

I had the same problem.

Changed by changing

implementation 'com.google.firebase:firebase-auth:11.0.6'

to

implementation 'com.google.firebase:firebase-auth:11.2.2'

The issue happened after adding the firebase plugin at Android 3.

Android Plugin version automatically adds

implementation 'com.google.firebase:firebase-auth:11.0.6'

but we need to change the version to 11.2.2

Error Log

Answer:

FWIW I had a similar error with a different library I use in my app, and the workaround for me was setting android.enableD8=false in gradle.properties.

Or upgrading from AGP 3.0.0-beta3 to beta6.

Answer:

Go back to 11.2.2 version of firebase.

For example:

From:

'com.google.firebase:firebase-core:11.4.0'

to

'com.google.firebase:firebase-core:11.2.2'

UPDATE

Even 11.6.0 of firebase has been released, this problem still exist. I found out adding

compile 'com.google.firebase:firebase-core:11.6.0'    
compile 'com.google.android.gms:play-services-location:11.6.0'  

problem disappears.

Answer:

Make sure all firebase libraries have the same version

Answer:

I was using the downgrade method until last week.

About 2 weeks ago, Firebase series has release version 15.0.0+, anyone trying to avoid this bug should consider update to latest version rather than downgrade.


Note : Some 3rd party packages also include firebase or gcm, you should be aware of their version consistent, too. (such as AccountKit from Facebook)

Answer:

I’ll speak to the original post that asked:

question 1: Does that mean that the google auth lib was already used somewhere else?

Yes, it means that you have added two or more code modules (libraries) that both have the same fully qualified class name. Android doesn’t like that since there would be an ambiguity as to which one should be used.

question 2: Whats that from?

It comes from your included source code or a dependency that you’ve added.

The problem people have is trying to figure out is where the duplicate classes are coming from. The easiest first step is to issue the following command
:

gradlew app:dependencies

then do a search for the name that it says is duplicated. Make sure that if they come from a repository, that they have the same version. If they are not the same version, then you’ve found where your duplicates are coming from. Sometimes, this technique does not reveal where the duplicate are coming from. If you include a library from a repository, you actually are loading that library and any of its dependencies. The repository not only has the jar file but it also has a pom.xml file that defines its dependencies. The “gradlew app:dependencies” output does not show those additional dependencies. In addition, each dependency can have additional dependencies. Maybe gradle has a way to traverse repository dependencies, but I don’t know for such, and I think not. In my case, when I had the similar error cause, I looked into the pom.xml of some maven repository libraries that I had a dependency on. In my case, I had two library modules that had a dependency on “org.osgi:org.osgi.annotation:6.0.0” and I had one library module that had a dependency on “org.apache.felix:org.apache.felix.resolver:2.0.0”. When I looked at the pom.xml file for the resolver library I notices that it had a dependency on “org.osgi:osgi.annotation:6.0.1”. Fortunately it was fairly easy for me to guess that those contained different implementations for the same class. Sometimes the names aren’t close enough for you to recognize that they contain class conflicts. It you run into that situation, you need to look into those repository jars to see if the do contain the class that is being reported as already existing.

In some of the answers I’ve seen above, people where just adhocly changing implementation dependencies until they found one that worked. Hopefully my answer gives you a better insight into figuring out how to find the duplicates. Wouldn’t it be great in Android Studio just told you where the classes in conflict are coming from?