Incompatible with AGP 4.2.0

[ZacSweers]

Describe the bug

When used with AGP 4.2.0-alpha13, this error occurs during configuration

Caused by: java.lang.ClassCastException: com.android.build.api.component.analytics.AnalyticsEnabledApplicationVariantBuilder_Decorated cannot be cast to com.android.build.api.variant.Variant
    at com.bugsnag.android.gradle.BugsnagPlugin$apply$1$1.invoke(BugsnagPlugin.kt:37)
    at com.android.build.gradle.internal.dsl.CommonExtensionImpl$onVariants$1.execute(CommonExtensionImpl.kt:230)
    at com.android.build.gradle.internal.dsl.CommonExtensionImpl$onVariants$1.execute(CommonExtensionImpl.kt:40)
    at com.android.build.api.variant.impl.VariantOperations.executeActions(VariantOperations.kt:61)
    at com.android.build.gradle.internal.dsl.CommonExtensionImpl.executeVariantBuilderOperations(CommonExtensionImpl.kt:242)
    at com.android.build.gradle.internal.dsl.BaseAppModuleExtension.executeVariantBuilderOperations(BaseAppModuleExtension.kt)
    at com.android.build.gradle.internal.dsl.BaseAppModuleExtension.executeVariantBuilderOperations(BaseAppModuleExtension.kt:37)
    at com.android.build.gradle.internal.VariantManager.createVariant(VariantManager.kt:236)
    at com.android.build.gradle.internal.VariantManager.createVariantsFromCombination(VariantManager.kt:621)
    at com.android.build.gradle.internal.VariantManager.computeVariants(VariantManager.kt:156)
    at com.android.build.gradle.internal.VariantManager.createVariants(VariantManager.kt:118)
    at com.android.build.gradle.internal.plugins.BasePlugin.createAndroidTasks(BasePlugin.java:674)
    at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:69)
    ... 143 more

This is unfortunate, as basically what's happened is that while a new API was introduced in 4.1 to replace the previous API that was used in 4.0 and older, the new API is not stable yet and was changed.

Environment

• Android Studio version: 4.2.0-alpha13
• Android Gradle version: 4.2.0-alpha13
• Bugsnag manifest section (if modified):

Example Repo

https://github.com/zacsweers/catchup and just update the AGP version in buildSrc/build.gradle.kts

[ZacSweers]

One proposal for supporting these going forward could be to make AGP handling separate artifacts and implemented via service loader. Then these artifacts could be versioned separately (i.e. with matching -alpha13 or similar qualifiers to match the AGP version they target). That would help with semver, and is likely the only reasonable way I can think of for supporting unreleased versions. Then when it's stable, move the implementation into the main artifact as the default. If that sounds reasonable, I can take a crack at a PR

[tomlongridge]

@ZacSweers - that sounds interesting. But if we change the default when a version of AGP is released/stable, doesn't that effectively mean a breaking change for users of the Bugsnag plugin?

[ZacSweers]

the default would be whatever your minimum supported AGP version is, and users would have to add the extension artifact for the version they need

[fractalwrench]

Hey Zac, thanks for reporting this. We plan on looking at this after the API change has stabilised and AGP 4.2-beta is released, as this shouldn't be too far away. If it's possible to workaround the API change using reflection we'll probably go with that approach to maintain backwards compatibility across all versions - otherwise we'll consider using the service loader approach or perhaps re-evaluating the versions of AGP we support depending on the difficulty of a fix.

[ZacSweers]

Just to note - beta releases of AGP don't inherently imply API stability. They use gradle's @Incubating annotation instead for communicating API (in)stability. Waiting for 4.2 beta will not likely have any bearing on API stability

[fractalwrench]

In this case the upcoming canary14 is known to have some further API changes, so it's likely that any time spent looking at this now could be wasted effort. We recognize that the API is marked as @Incubating and is therefore unstable, but are hoping that there's less risk of further changes in a beta version than there would in the canary channel.

[rwmorey71]

I see this is closed but I'm still experiencing this issue with Bugsnag 5.4.0

[xljones]

Hey @rwmorey71, this issue is still open, and is on our radar. https://github.com/bugsnag/bugsnag-js/issues/1100 was closed as it was a duplicate.

[fractalwrench]

This has been fixed in #350 by using a Groovy shim to access the old API on 4.1, which avoided the need for a service loader pattern. A release should be coming soon

[ZacSweers]

Closing as it appears to be resolved