FullLifecycleObserver dependency error

[gulcesenyuz]

Cannot access 'androidx.lifecycle.FullLifecycleObserver' which is a supertype of 'com.skydoves.balloon.Balloon'. Check your module classpath for missing or conflicting dependencies

Can you help me to solve this

[faraz152]

this happens when your project forces a newer lifecycle-common version that removed the internal FullLifecycleObserver class. the fix is to update Balloon to the latest version — newer releases use DefaultLifecycleObserver instead which is the public API in lifecycle 2.4+.

if upgrading Balloon is not an option, you can pin lifecycle-common to 2.3.1 in your gradle but that will hold back other lifecycle deps too.

[Alox1d]

Before pinning Lifecycle to an old version, check which Balloon binary and Lifecycle artifacts are actually on the failing module's compile classpath:

./gradlew :app:dependencyInsight --dependency com.github.skydoves:balloon --configuration debugCompileClasspath
./gradlew :app:dependencyInsight --dependency androidx.lifecycle:lifecycle-common --configuration debugCompileClasspath

Replace :app and debugCompileClasspath if the error comes from a library module or another build variant. Check for strict version constraints, exclusions, and a locally supplied AAR as well.

If you want to keep the View-based Balloon API, use a compatible 1.x release consistently. For example, Balloon 1.7.6 implements DefaultLifecycleObserver, so a compiler diagnostic still naming FullLifecycleObserver is a reason to inspect the resolved binary rather than assume your declared version was selected:

implementation("com.github.skydoves:balloon:1.7.6")
// If using the 1.x Compose wrapper:
implementation("com.github.skydoves:balloon-compose:1.7.6")

There is an important caveat to “upgrade to latest”: 2.x is a Compose Multiplatform rewrite, with no Balloon.Builder(context), View, or XML API. It is a migration, not a drop-in fix for an existing View integration. The migration guide explicitly identifies 1.7.6 as the final View release.

The one-line error is not enough to identify the exact conflicting dependency. Posting the two dependency-insight results and your current Balloon version would make that clear without forcing the entire app's Lifecycle stack down to 2.3.1. Gradle's dependency-insight documentation explains how to read the selection reasons.