firebase-android-sdk: [firebase-perf] Fails the build when using dependencies in Multi-release JAR format

looks like this one has been fixed with https://firebase.google.com/support/release-notes/android#performance_gradle_plugin_v1-4-1 ?

Still getting the same issue with perf-plugin:1.4.1.

Hi @ZacSweers, we have included a fix in the next Fireperf gradle plugin release where we will filter out classes in META-INF/ directory, so look out for that in a couple of weeks. Thanks!

@jfcong - we get a lot of questions from the community that feel hamstrung by firebase’s unwillingness to address this bug but also cannot upgrade to a pre-release version of AGP. Would there be a middle ground here to resolve this by either not reading classes in resources/META-INF (they’re not going to be run at runtime anyway), gracefully skipping over classes in a newer Java class version that firebase cannot parse, or offering an opt-out mechanism to skip certain classes (jetifier’s plugin does this)?

I think there are options available that would both benefit users today while also help avoid future issues like this with the firebase plugin.

This situation completely sucks. You can’t requires people to use canary release that will not be stable before months just because you are unable to backport a fix to stable release (by the way, this bug was reported 2 months before AGP 7.1 was stable).

Version 1.3.2 breaks gradle configuration cache and is not an option. Version 1.3.5 is broken when using AGP 7.1. Version 1.4 don’t work with anything but AGP 7.2 which does not exist yet.

I guess removing firebase perfs from my project is today the best options…

Hi all, we understand the frustration with the current situation, and we want to provide some updates/workarounds for this issue:

Here are some updates:

1. AGP v7.2.0-beta01 was made available last week and will work with the latest perf plugin v1.4.1.
2. AGP 7.2 RC1 is scheduled to release on 1st of March and 7.2 final is scheduled on the 9th of March.

In the mean time, here are some work arounds worth trying out:

1. Use perf plugin 1.3.5 with AGP v6.8.3. Perf plugin v1.3.5 and below is not compatible with AGP v7.0.0+; in order for the perf plugin to be compatible with AGP v7.0.0+, we have to use the new transform API, which introduces the build failure where even if the perf plugin filters out classes in the META-INF/ directory from instrumentation, AGP still tries to visit the classes to collect information about them. However, AGP is working on a more permanent fix for this where we will have an option to filter out failed classes completely.
2. Wait until March 9 to integrate the latest perf plugin version and AGP.
3. Try a beta version of AGP with the latest perf plugin version and move to the production version after March 9th.

We will continue to post updates on this issue as soon as we have them, but in the mean time, please try out the workarounds mentioned above.

This should still be fixed with AGP 7.2.0-beta01, but one other workaround to try is to downgrade to a version of Fireperf plugin before we migrated to use the new Transform API. The latest version before the migration was 1.3.5.

Downgrading firebase-perf to 1.3.5 with AGP 7.1.0 faced another issue.

> Task :app:transformClassesWithFirebasePerformancePluginForRelease FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:transformClassesWithFirebasePerformancePluginForRelease'.
> 'java.lang.String com.android.utils.FileUtils.relativePossiblyNonExistingPath(java.io.File, java.io.File)'

Downgrading firebase-perf to 1.3.2 and the build passed.

Hi everyone, we’ve discovered that there is another processing step done by AGP that tries to visit the class to collect information about it whether or not firebase registers interest in visiting the class, so there is no fix available for this issue on Firebase side even when we filtered out classes in the META-INF/ directory from instrumentation. We will update the release note to reflect this.

This should still be fixed with AGP 7.2.0-beta01, but one other workaround to try is to downgrade to a version of Fireperf plugin before we migrated to use the new Transform API. The latest version before the migration was 1.3.5.

Hi @mateuszkwiecinski! This issue will be fixed by AGP 7.2.0-beta01, and it is planned for release in three weeks. In addition, it won’t take 2 years for it to be stable, 7.2.0 stable is planned to release in mid February of next year. As such, we will treat this as a feature request, since it seems to require a lot of investigation to change the Fireperf plugin implementation to be compatible with the current AGP versions, and it’s unlikely that we can release a workaround on the Fireperf plugin side before AGP 7.2.0-beta01 is released.

Let me know if you have more questions!

Here’s minial sample repository https://github.com/mateuszkwiecinski/firebase-perf-doesnt-work in case it’s still needd.

git clone git@github.com:mateuszkwiecinski/firebase-perf-doesnt-work.git
cd firebase-perf-doesnt-work
git checkout f76929e361a257e9c28d8b1fde0bc43010b3d48a
./gradlew :app:assembleDebug

@argzdev I’m not sure I understood what does “supported” mean. According to https://issuetracker.google.com/issues/206655905 you do “support” them, in a way fireabse-perf plugins shouldn’t have access to unrelated bytecode. Are you 100% sure firebase-perf plugin should touch parts of the jar that don’t meant to be used? that doesn’t sound right 🤔

I personally don’t like calling this a “feature request” because it’s not like some data present in multi release jar file isn’t parsed by firebase-perf but it rather completely breaks the project. It is a blocker, without a workaround other than removing firebase-perf depenedncy at all, it makes the plugin unusable, but idk 🤷

Hi there folks, I’m raising this with our engineering team so that we can take a look. Thanks for all the info so far! We’ll let you know if we have additional questions.

You do raise a good point, @mateuszkwiecinski. I think in this case, it’s more valid to tag this as a bug. Thank you both for your findings and explanations, I’m sure our engineers can investigate this further with the given information.

I can reproduce the issue with help of @mateuszkwiecinski project by following the steps of the failing Github Action:

git clone git@github.com:mateuszkwiecinski/github_browser.git
cd github_browser
git checkout 006baf9215eb508190447db50039518da3c50543
./gradlew :app:minifyMockedReleaseWithR8

I get the error:

* What went wrong:
Execution failed for task ':app:minifyMockedReleaseWithR8'.
> Could not resolve all files for configuration ':app:mockedReleaseRuntimeClasspath'.
   > Failed to transform moshi-1.13.0-SNAPSHOT.jar (com.squareup.moshi:moshi:1.13.0-SNAPSHOT:20211123.150350-27) to match attributes {artifactType=android-asm-instrumented-jars, asm-transformed-variant=mockedRelease, org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.jvm.environment=standard-jvm, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.status=integration, org.gradle.usage=java-runtime, org.jetbrains.kotlin.platform.type=jvm}.
      > Execution failed for AsmClassesTransform: /Users/wasyl/.gradle/caches/modules-2/files-2.1/com.squareup.moshi/moshi/1.13.0-SNAPSHOT/59c588d010076e7f764c96eebfc6de82bcacb68/moshi-1.13.0-SNAPSHOT.jar.
         > Record requires ASM8

I think AGP 7.1.2 should resolve this issue, as it includes the following fix - https://issuetracker.google.com/issues/216160972

@mateuszkwiecinski Well it’s still the same company, so if anybody has an ability to make things faster is another google team. So I guess firebase people should care enough to try and force Android Gradle Plugin team to backport fix for currently stable release. It’s in their interest I guess? And no worries, we are complaining there too.

Understood, thank you very much for the clarification.

I think it depends what libraries you include in your product. I you have one with multi JDK support (like Moshi which is commonly use), you can’t use 1.4.1.

Hi @ZacSweers, thanks for all the suggestions! We are currently low on staffing due to the holiday season, but we will revisit this after the holidays.

All clear, thanks!