A Missing Maven Dependency in Firebase Auth Just Broke Kotlin Builds Worldwide
theme: smartblue
I was speechless when I saw this a few days ago. On the 24th, firebase_auth 6.6.0 was released with a change: REFACTOR(auth,android): migrate native implementation to Kotlin. That is, FlutterFire's firebase_auth Android plugin was just rewritten from Java to Kotlin. At the same time, firebase_core 4.14.0 also migrated to Kotlin. The migrated code contains Java SAM conversions like this:
FirebaseAuth.IdTokenListener { auth ->
// auth type inferred by Kotlin
}
IdTokenListener is a Java single abstract method interface provided by the Firebase Android SDK. For Kotlin to infer the type of auth, it needs to read the full type information from the Firebase SDK class file.
And here's where the problem arises: the class file of firebase-auth:24.2.0 references Checker Framework's:
org.checkerframework.checker.initialization.qual.UnknownInitialization
But its POM published to Maven never actually declared checker-qual. This means the Kotlin compiler can see "there is an annotation here", but cannot load the annotation class, resulting in the error:
Type annotation class
'org.checkerframework.checker.initialization.qual.UnknownInitialization'
of the inferred type is inaccessible.
So the whole problem can be broken down into three layers:
| Layer | Problem |
|---|---|
| Upstream defect | firebase-auth's class file references @UnknownInitialization, but its POM does not declare checker-qual |
| FlutterFire trigger | firebase_auth 6.6.0 migrated from Java to Kotlin, introducing SAM lambdas that need parameter type inference |
| Kotlin amplifier | Kotlin 2.3 mainly gives a warning for this issue; Kotlin 2.4 treats it as a compilation error |
So where's the problem? The interesting part is that Firebase Android SDK's release metadata has always had this gap, but the gap was never discovered before.
Only when the other two conditions stacked up did this bug erupt. So in the Flutter scenario, FlutterFire's fix was also simple. It didn't add a checker-qual dependency; instead, it chose to write explicit types for the two lambda parameters:
- FirebaseAuth.IdTokenListener { auth ->
+ FirebaseAuth.IdTokenListener { auth: FirebaseAuth ->
- FirebaseAuth.AuthStateListener { auth ->
+ FirebaseAuth.AuthStateListener { auth: FirebaseAuth ->
This way, Kotlin no longer needs to infer parameter types from Java signatures with missing annotations, bypassing the compiler error path. The PR also upgraded the test project to:
- Kotlin 2.4.10
- AGP 8.11.1
- Gradle 8.14
Ensuring CI truly covers the "warning becomes error under Kotlin 2.4" scenario.
And actually, it's the same on Android. Java might be fine, but any Kotlin project that:
- Uses Kotlin 2.4
- Has no other dependency on the classpath that incidentally brings in
checker-qual - Uses parameter type inference in Kotlin code for
FirebaseAuth.IdTokenListenerorAuthStateListener
will also fail on Kotlin Android. This is essentially a long-standing bug. The Firebase Auth AAR missed the Checker Framework compile dependency at release time. It was only discovered when FlutterFire 6.6.0's Kotlin rewrite and Kotlin 2.4's type inference combined. You can only say this kind of bug is too classic. It wasn't a problem before simply because there was no trigger. Many low-level mistakes just quietly accumulate over time.
Even former Flutter founder Eric publicly complained about Firebase's architecture issues. Ultimately, Google Play keeps telling everyone to use R8 and optimize, but your own SDK itself isn't optimized well. That's ironic: