Gradle task injectCrashlyticsBuildIds fails when processing unparseable ELFs

[EmielMatthys]

Describe your environment

• Android Studio version: NA
• Firebase Component: Gradle Plugin and Build tools
• Component version: Tested with 3.0.6 but other versions are affected.
• Setup: An Android app Gradle project with at least one SDK dependency using native libraries.

Describe the problem

As part of the injectCrashlyticsBuildIds task, ELF files pulled into an Android app project from SDK dependencies are parsed by the Crashlytics build tools during info collection.

When an SDK includes .so files that are not parseable by Crashlytics' ElfDataParser for any reason, the plugin crashes while executing the mentioned task.

We've seen at least two concrete occurrences on our end but the problem can in theory happen in any part of the parsing code.
At the moment there is no self-actionable way to work around this, other than downgrading the Crashlytics version.

Trace 1

The file could not be identified as a valid ELF.

Caused by: java.lang.IllegalArgumentException: Input is not a valid ELF file.
        at com.google.firebase.crashlytics.buildtools.ndk.internal.elf.ElfDataParser.initializeReader(ElfDataParser.java:119)
        at com.google.firebase.crashlytics.buildtools.ndk.internal.elf.ElfDataParser.parse(ElfDataParser.java:107)
        at com.google.firebase.crashlytics.buildtools.ndk.internal.elf.ElfDataParser.parse(ElfDataParser.java:58)
        at com.google.firebase.crashlytics.buildtools.buildids.BuildIdInfoCollector.getBuildIdInfo(BuildIdInfoCollector.java:50)
        at com.google.firebase.crashlytics.buildtools.buildids.BuildIdInfoCollector.collect(BuildIdInfoCollector.java:41)
        at com.google.firebase.crashlytics.buildtools.Buildtools.injectBuildIdsIntoResource(Buildtools.java:216)
        at com.google.firebase.crashlytics.buildtools.gradle.CrashlyticsBuildtools.injectBuildIdsIntoResource(CrashlyticsBuildtools.kt:91)
        at com.google.firebase.crashlytics.buildtools.gradle.tasks.InjectBuildIdsTask.injectBuildIds(InjectBuildIdsTask.kt:54)
        [omitted]

Trace 2

This one appears to be caused specifically by an assumption in the ElfDataParser::readElfSectionHeaders that eShstrndx always points to an existing section entry.

Caused by: java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
        at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
        at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
        at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266)
        at com.google.firebase.crashlytics.buildtools.ndk.internal.elf.ElfDataParser.readElfSectionHeaders(ElfDataParser.java:531)
        at com.google.firebase.crashlytics.buildtools.ndk.internal.elf.ElfDataParser.parseElf(ElfDataParser.java:137)
        at com.google.firebase.crashlytics.buildtools.ndk.internal.elf.ElfDataParser.parse(ElfDataParser.java:113)
        at com.google.firebase.crashlytics.buildtools.ndk.internal.elf.ElfDataParser.parse(ElfDataParser.java:58)
        at com.google.firebase.crashlytics.buildtools.buildids.BuildIdInfoCollector.getBuildIdInfo(BuildIdInfoCollector.java:50)
        at com.google.firebase.crashlytics.buildtools.buildids.BuildIdInfoCollector.collect(BuildIdInfoCollector.java:41)
        at com.google.firebase.crashlytics.buildtools.Buildtools.injectBuildIdsIntoResource(Buildtools.java:216)
        at com.google.firebase.crashlytics.buildtools.gradle.CrashlyticsBuildtools.injectBuildIdsIntoResource(CrashlyticsBuildtools.kt:91)
        at com.google.firebase.crashlytics.buildtools.gradle.tasks.InjectBuildIdsTask.injectBuildIds(InjectBuildIdsTask.kt:54)
        [omitted]

Steps to reproduce

I've attached a reproducing sample. You can run it by first publishing the library to Maven local and then building the APK or running the inject task directly:

./gradlew :mynativelibrary:publishToMavenLocal
./gradlew :app:injectCrashlyticsBuildIdsRelease --stacktrace

ReproducingCrashlytics.zip

Proposed solution

As the libraries included in SDKs can be unpredictable and are not guaranteed to be parseable: Extend the catch-clause in BuildIdInfoCollector::getBuildIdInfo to cover any RuntimeException. A debug log can be printed to indicate this happened but the processed library is otherwise ignored.

This will immediately unblock users with SDK dependencies that distribute any non-standard or otherwise unparseable ELF files, which would be uninformative for info collection in any case.

Thank you for your consideration!

[lehcar09]

Hi @EmielMatthys, thank you for raising this issue and sharing and MCVE. I was able to reproduce the issue. I'll raise this to our engineers with your proposed solution. Thanks!

[mrober]

I have come up with a mitigation you can do in your own app for now. I will fix this permanently in the next release of the Crashlytics Gradle plugin

In your app's build.gradle.kts file, you can exclude specific binaries from the Crashlytics tasks like this:

import com.android.build.api.artifact.SingleArtifact
import com.google.firebase.crashlytics.buildtools.gradle.CrashlyticsExtension
import com.google.firebase.crashlytics.buildtools.gradle.tasks.GenerateSymbolFileTask
import com.google.firebase.crashlytics.buildtools.gradle.tasks.InjectBuildIdsTask

...

androidComponents {
  onVariants { variant ->
    project.tasks.withType(InjectBuildIdsTask::class.java).configureEach {
      mergedNativeLibsDirs.set(null as File?)
    }

    project.tasks.withType(GenerateSymbolFileTask::class.java).configureEach {
      unstrippedNativeLibsDirs.setFrom(
        variant.artifacts.get(SingleArtifact.MERGED_NATIVE_LIBS).map { directory ->
          project.fileTree(directory.asFile).matching {
            exclude("**/libdoesntparse.so")
          }
        }
      )
    }
  }
}

You can include or exclude whatever you want this way. Let me know if you run into any problems with this approach

[EmielMatthys]

Hi @mrober , thank you for the confirmation and the mitigation snippet! I could indeed use it as a temporary workaround.
Looking forward to the release!