unstrippedNativeLibsDir property can't accomodate build type and flavor variations together

[READ] Step 1: Are you in the right place?

Issues filed here should be about bugs in the code in this repository. If you have a general question, need help debugging, or fall into some other category use one of these other channels:

• For general technical questions, post a question on StackOverflow with the firebase tag.
• For general Firebase discussion, use the firebase-talk google group.
• For help troubleshooting your application that does not fall under one of the above categories, reach out to the personalized Firebase support channel.

[REQUIRED] Step 2: Describe your environment

• Android Studio version: 3.6.3
• Firebase Component: Crashlytics (Database, Firestore, Storage, Functions, etc)
• Component version: firebase-crashlytics-ndk: 17.0.1 firebase-crashlytics-plugin: 2.1.1

[REQUIRED] Step 3: Describe the problem

We have a fairly complex project layout, so the default Crashlytics heuristics for locating the unstripped binaries do not work for us. So we have to arrange the proper file tree ourselves and then point to it using the strippedNativeLibsDir and unstrippedNativeLibsDir properties. Of course, the binaries are different depending on the build flavor and the build type, so having a common value for those properties in the defaultConfig is a no-go. We can set those properties per build type, but then the per-flavor variation is lost. If we set them per-flavor, then the per-build type variation is lost.

Steps to reproduce:

android {

    // This setup assumes the same binaries are used for all flavors
    builtTypes {
        debug {
            firebaseCrashlytics {
                strippedNativeLibsDir 'myLibs/stripped/debug'
                unstrippedNativeLibsDir 'myLibs/unstripped/debug'
            }
        }
        release {
            firebaseCrashlytics {
                strippedNativeLibsDir 'myLibs/stripped/release'
                unstrippedNativeLibsDir 'myLibs/unstripped/release'
            }
        }
    }

    // This setup assumes the same binaries are used for all build types
    flavors {
        flavorA {
            firebaseCrashlytics {
                strippedNativeLibsDir 'myLibs/stripped/flavorA'
                unstrippedNativeLibsDir 'myLibs/unstripped/flavorA'
            }
        }
        flavorB {
            firebaseCrashlytics {
                strippedNativeLibsDir 'myLibs/stripped/flavorB'
                unstrippedNativeLibsDir 'myLibs/unstripped/flavorB'
            }
        }
    }
}

So one couldn’t organize myLibs/stripped and myLibs/unstripped to hold AGP-like hierarchies with variant dirs inside. Either the build type or the flavor configuration “wins”.

Relevant Code:

Ideally, the one would be able to set a “root” directory that contains variant-dir hierarchies

android {
    defaultConfig {
        firebaseCrashlytics {
            strippedNativeLibsRootDir 'myLibs/stripped'
            unstrippedNativeLibsRootDir 'myLibs/unstripped'
        }
    }
}

Or, alternatively, at least one should be able to set those properties for each variant:

android.applicationVariants.all { variant ->
    variant.firebaseCrashlytics.strippedNativeLibsDir "myLibs/stripped/${variant.dirName}"
    variant.firebaseCrashlytics.unstrippedNativeLibsDir "myLibs/unstripped/${variant.dirName}"
}

Unfortunately, the Firebase Crashlytics extension properties are not available in the variant, so the snippet above doesn’t work.

[doganov]

I am sorry, but I do not see how multi-dimensional flavor priorities address the original issue I reported. The example code in the original report doesn’t involve multi-dimensional flavors at all.

I would like to re-open the issue as @mrichards suggests, but I don’t seem to have permissions to do it as the issue was closed by a project contributor.

[mrichards]

Hi folks, we just shipped version 2.8.1 of the Crashlytics Gradle plugin, which should (finally!) prioritize multi-dimensional flavor properties correctly.

Thank you for your patience, and please re-open the issue if you continue to experience problems with firebaseCrashlytics properties when using multiple flavor & build type combinations.