Develop Reference

Firebase crashlytics mapping file upload doesn't work

I have added firebase crashlytics lib and crashlytics gradle plugin to my project
classpath("com.google.firebase:firebase-crashlytics-gradle:2.3.0")
...
plugins {
...
id("com.google.firebase.crashlytics")
...
}
...
implementation("com.google.firebase:firebase-crashlytics:17.2.1")
implementation("com.google.firebase:firebase-analytics:17.5.0")
I explicitly set mappingFileUploadEnabled for my release build types with
getByName("release").apply {
firebaseCrashlytics.mappingFileUploadEnabled = true
}
But mapping file is unfortunately not uploaded. I verify it in firebase crashlytics console - for my test crashes stacktrace points to Unknown Source:55.
Here is what I found in gradle logs:
[DEBUG] [com.google.firebase.crashlytics] Mapping File Upload Enabled: false; id: 00000000000000000000000000000000
So it seems my mappingFileUploadEnabled flag has no effect.
Do I need to do something else to make mapping file upload work?
I also don't see firebaseUpload*ReleaseProguardMapping tasks in my project. Not sure if it is supposed to be created though.
UPDATE
I have tried to create an empty android project from scratch and added firebase-crashlytics there. There it seems to work and I can see uploadCrashlyticsMappingFile tasks created for all build types. So for now it looks like firebase-crashlytics gradle plugin doesn't work correctly for my project and doesn't create tasks it is supposed to create. Does anyone have an idea why?

Today I learned that if you apply firebase-crashlytics gradle plugin declaratively, using the plugins {} block the mapping file upload tasks are not created. In order to make it work I had to apply the plugin imperatively using the legacy apply(..) function. This is what I have in the project now:
apply(plugin = "com.google.firebase.crashlytics")
plugins {
//other plugins
}
After making this change the mapping file upload works fine.
UPDATE
I figured out that if I move crashlytics plugin to the bottom on my plugins section I have the same effect.
Now it looks like:
plugins {
//all other plugins
id("com.google.firebase.crashlytics")
}

Crashlytics Android NDK: missing all symbols in crash reports

Our native Crashlytics crash reports are missing all symbol information as of late. I had hoped that the latest Crashlytics NDK would resolve the issue, but it does not.
I see that there is a similar query out there, but in this case I am not using Firebase, just Crashlytics, and had been doing so successfully for quite some time.
Our build.gradle (using CMake and the Gradle 3.0.0 or 3.1.0 Android plugin -- same issue either way) contains:
buildscript {
...
dependencies {
...
classpath 'io.fabric.tools:gradle:1.+'
}
}
...
dependencies {
...
implementation('com.crashlytics.sdk.android:crashlytics:2.9.1#aar') {
transitive = true
}
implementation 'com.crashlytics.sdk.android:crashlytics-ndk:2.0.2'
}
Which would seem to be correct and using all the latest Fabric components unless I am missing something.
I then added:
crashlytics {
enableNdk true
manifestPath 'AndroidManifest.xml'
}
tasks.whenTaskAdded { task ->
if (task.name.startsWith('assemble')) {
task.finalizedBy "crashlyticsUploadSymbols" + task.name.substring('assemble'.length())
}
}
none of which I had needed some time ago when this was working. (And, no, just adding the crashlytics block was insufficient.)
This gives me symbols for the .cpp files I actually build in this project. It still has no symbols for the .a file I link in, nor even for libc++_shared.so!

For Java
https://docs.fabric.io/android/crashlytics/dex-and-proguard.html
Configure ProGuard and DexGuard
We’ve made it simple to set up ProGuard or DexGuard in your app and receive deobfuscated crash reports. First of all, Fabric uses annotations internally, so add the following line to your configuration file:
-keepattributes *Annotation*
Next, in order to provide the most meaningful crash reports, add the following line to your configuration file:
-keepattributes SourceFile,LineNumberTable
Crashlytics will still function without this rule, but your crash reports will not include proper file names or line numbers.
For C++
https://docs.fabric.io/android/crashlytics/ndk.html
Specifying the path to debug and release binaries
To properly symbolicate and process native crashes, we need the symbols from your native binaries. Typically, Android’s native binary build processes produce two sets of binaries: one set with debugging symbols, and one set to be packaged in your final APK. The Fabric plugin uses both sets of binaries to generate a symbol file on your machine. The symbol generation and upload process assumes your project will have two directories - one for the debug binaries (called obj below), and one for the release binaries (called libs below) - that are broken down by architecture-specific folders.
When building your project with the Android plugin for Gradle version 2.2.0+ with the externalNativeBuild DSL, the Fabric plugin is able to automatically detect the necessary directories for each native build variant in order to generate the appropriate symbol files.
obj/
— armeabi
+ lib1.so
+ lib2.so
— x86
+ lib1.so
+ lib2.so
libs/
— armeabi
+ lib1.so
+ lib2.so
— x86
+ lib1.so
+ lib2.so
The paths to the debug and release binaries can be manually controlled via the androidNdkOut (default: src/main/obj) and androidNdkLibsOut (default: src/main/libs) properties. Ant users can modify these in the fabric.properties file. Gradle users can control these via the crashlytics {} block in their build.gradle.
Ant: ant crashlytics-upload-symbols
Gradle: ./gradlew crashlyticsUploadSymbols{Variant}
For example: ./gradlew crashlyticsUploadSymbolsRelease
You should also read "Uploading symbols for external dependencies" it it applies to your code.

add the following to your gradle.properties file:
android.bundle.enableUncompressedNativeLibs = false

After upgrade of Gradle to the version 3.0.1 something generates redundant jacoco.exec file

I have the following modules:
app (com.android.application)
testlibrary (com.android.library)
After upgrade of Gradle to the version 3.0.1, Jacoco plugin generates redundant and not valid jacoco.exec file in the app (com.android.application) module’s root folder after execution of tests. This file is generated when in testlibrary (com.android.library) module I set testCoverageEnabled true. If I set in testlibrary testCoverageEnabled false, then jacoco.exec file is not generated.
Expected Behavior
jacoco.exec file shouldn’t be generated in the root folder of app module after execution of tests, regardless testCoverageEnabled flag set to true or false in the testlibrary module.
Current Behavior
After execution of tests, jacoco.exec file is created in the root folder of the app module if in the testlibrary module the testCoverageEnabled flag set to true.
Context
I’m trying to upgrade to the Gradle 3.0.1 version from the Gradle 2.2.2 version. But after upgrade and execution of all tests, I noticed that a new redundant jacoco.exec file was generated inside of app’s root directory.
Steps to Reproduce
GitHub repo to showcase the issue: https://github.com/DenysShovhenia/Test
Steps to reproduce:
Open project in Android Studio
Run testDebugUnitTest task of Test(root) module
Note the newly created jacoco.exec file in the root folder of app module
I hope somebody can help me to resolve this issue.

This is actually a bug which for now is not closed: https://issuetracker.google.com/issues/67872367
After a lot of research, I have found some workarounds.
1) Add this to the modules where this file is generated.
android {
testOptions {
unitTests {
all {
// workaround for generation of unexpected jacoco.exec file in project directory
systemProperty 'jacoco-agent.destfile', buildDir.path + '/jacoco.exec'
}
}
}
}
2) Create in the library module under library/src/debug/resources folder the file jacoco-agent.properties.
And add to this file next line:
destfile=build/jacoco/coverage.exec
So, in this way you can just replace this files to the build folder.
Additional variants:
3) Set testCoverageEnabled to false for library module.
4) Don't use code from the library in tests for the app module.
Useful link:
http://www.qalearningguide.com/2017/10/code-coverage-for-android-using-jacoco.html

Android Crashlytics ndk; values of NdkOut and NdkLibsOut in build.gradle

I have integrated Crashlytics, Fabric into my app, the sdk related crashes are reported successfully.
For the ndk part, i have followed instructions from the blog; The Wait is Over: Launching Crashlytics for Android NDK, but the ndk crashes aren't being reported. My doubt is, because other parts are sufficiently clear, i'm not providing the correct path for androidNdkOut and androidNdkLibsOut, as shown in:
The doubt and question is in my build.gradle, here it is...
crashlytics {
enableNdk true
androidNdkOut //what would be the obj here?
androidNdkLibsOut 'src/main/jniLibs' //path for my jni libraries
}
please let me know if i should post any other part of the code

EDIT/UPDATE July 7, 2017
Matt from the Fabric team here with an update to this answer - we just released the Fabric Gradle plugin version 1.23.0 which includes support for automatically detecting the appropriate native library paths when you're using the externalNativeBuild DSL with the Android plugin for Gradle version 2.2.0+, so you no longer need to set the androidNdkOut and androidNdkLibsOut properties. This will work with both CMake and ndk-build. Check out more info here: https://docs.fabric.io/android/crashlytics/ndk.html#specifying-the-path-to-debug-and-release-binaries
I could solve the problem after getting help from Crashlytics/Fabric Support, thanking them..this answer.
First, for
crashlytics {
enableNdk true
androidNdkOut //what would be the obj here?
androidNdkLibsOut 'src/main/jniLibs' //path for my jni libraries
}
for my app's build.gradle, it should have been:
crashlytics {
enableNdk true
androidNdkOut 'src/main/jniLibs'
androidNdkLibsOut 'src/main/jniLibs'
}
androidNdkOut is where your debug binaries are located. This defaults
to 'src/main/obj' but you can set in the crashlytics { } if it's
different in your project.
a link which contains useful information on the same: crashlytics knowledgebase; Missing line numbers in native crashes
A minor but very useful part was running commands like uploadReleaseSymbols with the --stacktrace option. Thought its worth the mention as that(uploading release symbols) was also an issue on my side for not receiving the crash reports.

Follow this guide -https://fabric.io/downloads/gradle/ndk. We kept empty both fields (androidNdkOut and NdkLibsOut)

Had a similar problem: I had to add CrashlyticsNdk kit at Fabric.with().
Fabric fabric = new Fabric.Builder(context)
.kits(new Twitter(authConfig), new Crashlytics(), new CrashlyticsNdk())
.debuggable(true)
.build();
Fabric.with(fabric);
you can check androidNdkOut, androidNdkLibsOut this way.
$ ./gradlew -d clean assemble{Flavor} | grep ndk-build
and you will find NDK_OUT and NDK_LIBS_OUT.

Gradle Configurations not Working as Expected in New Android Build System

Environment Configuration
com.android.tools.build:gradle:0.4
gradle version 1.6
jdk 1.6 (OSX)
android build tools version 17
compile sdk version 17
The issue that I seem to be having is that I can’t seem to exclude lombok from being added to the apk. I tried to do it by creating a provided configuration like this:
configurations {
provided
}
sourceSets {
main { compileClasspath += configurations.provided }
}
and then adding the dependency like this:
dependencies {
provided ‘org.projectlombok:lombok:0.11.8′
}
But I’m still getting this error:
Error: duplicate files during packaging of APK <myapp>.apk
Path in archive: LICENSE
Origin 1: /<home>/.gradle/caches/artifacts-24/filestore/org.projectlombok/lombok/0.11.8/jar/e43ce2be16d8990568a4182c0bf996ad3ff0ba42/lombok-0.11.8.jar
Origin 2: /<home>/.gradle/caches/artifacts-24/filestore/org.sonatype.sisu.inject/cglib/2.2.1-v20090111/jar/7ce5e983fd0e6c78346f4c9cbfa39d83049dda2/cglib-2.2.1-v20090111.jar
:packageRelease FAILED
I have tried using lombok-api.jar which then causes a different issue regarding some AccessLevel annotation while performing dex.
Which suggests that its including the lombok jar file into the apk. This shouldn't be happening, any suggestions?

You can't use sourceSets because we use custom ones. You'd have to do the following:
android.applicationVariants.each { variant ->
variant.javaCompile.classpath += configurations.provided.
}
However, it should be possible to instead remove the dependency from our "package" config (which replaces the "runtime" one.) I'll look into it.