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")
}

Error when executing crashlyticsGenerateSymbols task with android gradle plugin 3.6+

Where do i report this error? or could anyone help me?
“Directory X specified for property ‘$2’ does not exist” error when executing crashlyticsGenerateSymbols task
with
android gradle plugin 3.6.0
gradle version 5.6.4
fabric gradle plugin 1.31.2
[Error logs]
Some problems were found with the configuration of task ':~~~~~:crashlyticsGenerateSymbolsRelease' (type 'DefaultTask').
Directory '~~~' specified for property '$1' does not exist.
Directory '~~~~' specified for property '$2' does not exist.

Fabric/Firebaser here. This error comes up when the Fabric Gradle plugin is trying to parse your project structure in order to find your stripped and unstripped binaries, and is unable to do so. When it asks for properties $1 and $2 it means it could not find the default paths to the "obj" and "libs" folders that contain your supported ABIs folders with your supported native libraries there.
Using the legacy Fabric Gradle plugin, you can specify these paths under your crashlytics block in the build.gradle, like so:
crashlytics {
enableNdk true
androidNdkOut 'obj'
androidNdkLibsOut 'libs'
}
In the case for builds that are on Android Studio 3.5 or later, you can usually find the paths for these somewhere in the outputted build folders under "merged_native_libs" and "stripped_native_libs."
If you're using the new Firebase Crashlytics SDKs and Gradle plugin, those paths are controlled by "strippedNativeLibsDir" and "unstrippedNativeLibsDir" flags in the firebaseCrashlytics block in your build.gradle.
If you continue running into problems feel free to file a case with Firebase support with more details about your project and what you've tried to configure so far, and you can also still reach out to support#fabric.io.

I got the same issue on my side, and I fixed it by removing ext.enableCrashlytics = false from my app-level build.gradle in
android {
buildTypes {
debug {
// ext.enableCrashlytics = false
}
}
}

Jitpack builds successfuly, but jars are empty for every module

In recent release of our library we decided to add some kotlin-dsl features to our build, though for now we've added buildSrc build.gradle.kts and Dependencies.kts file containing libraries versions for easier use across all modules.
The problem is that this version builds successfuly on jitpack, but downloaded jars are empty. How do I fix this? Also all the resource files are present. The build log file also differs much from previous ones.
Problematic build log file
Working build log file
A link to library on jitpack: https://jitpack.io/#netigenkluzowicz/api_android
Github link
branch to reproduce these build problems is feature/kotlin, we're working to fix it on fix/jitpack-build branch
To Reproduce
Add this dependency to an Android project, sync and check classes.jars
implementation 'com.github.netigenkluzowicz:api_android:2.4.1'
What we did before this problem started to occur:
Added buildSrc directory with build.gradle.kts and Dependencies.kts.
We also extracted android { } block from our modules build.gradle files, it is now applied from android.gradle file.
I've already went through jitpack issues on github, all I found so far are build errors with kotlin-dsl from late 2018. Was following this guide to make a use of kotlin-dsl, though due to having issues with android { } block I didn't migrate all of our gradle files.

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

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.