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
Related
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
}
}
}
I'm trying to implement Crashlytics for my project which uses NDK/JNI. However the JNI part is in a project loaded externally like this in settings.gradle:
include ':app', ':core'
project (':core').projectDir = new File(rootDir, '../core')
I read that for some time Crashlytics should find the symbols automatically without the need to specify androidNdkOut and androidNdkLibsOut. It didn't work for my scenario, when I called ./gradlew crashlyticsUploadSymbols{flavor}Debug it complained about wrong androidNdkOut.
So I added those paths explicitly in the app's build.gradle:
crashlytics {
enableNdk true
androidNdkOut '../../core/build/intermediates/cmake/debug/obj'
androidNdkLibsOut '../../core/build/intermediates/cmake/release/obj'
manifestPath 'src/main/AndroidManifest.xml'
}
Crashlytics does find them right now and the crashlyticsUploadSymbols{flavor}Debug returns success. But it doesn't work properly. Some of the errors are not reported at all in the Crashlytics console, the rest is not deobfuscated. Also Crashlytics shows something like this in the logcat:
W/CrashlyticsCore: No minidump data found in directory /data/data/com.example.app/files/.Fabric/com.crashlytics.sdk.android.crashlytics-ndk/native/1513601249792
What should I do for my configuration to properly log the NDK exceptions in Crashlytics console?
Configuration that you specified in build.gradle is not correct.
androidNdkOut should point to object files, something like '../../core/build/intermediates/cmake/release/obj'
androidNdkLibsOut should point to actual libraries. in your case, most probably '../../core/build/intermediates/transforms/mergeJniLibs/release/folders/2000/3/main/lib'
How to add Diff Versions of JAR file depending on build variant using gradle in android ?
Use a build variant version of compile, like debugCompile or flavor1Compile.
For example, the following dependencies closure references an in-project library module for debug builds and an artifact for release builds:
dependencies {
debugCompile project(':security')
releaseCompile 'com.commonsware.cwac:security:0.6.+'
}
Since a given build will either be debug or release (not both), only one of those two dependencies will be used for the build.
If you literally mean JARs, you would need to use ...Compile files() statements that point to the specific JAR. I have not needed to use a bare JAR in Android builds in nearly two years, so I do not have the Gradle syntax for that handy.
I need a clear example of how to extend an Android Gradle project with an arbitrary project.
By arbitrary I mean that it can't just use the 'java' plugin since it doesn't support buildTypes to my knowledge. I am currently using an 'ant' task for this, which has two targets for debug and release, however I don't see how to tie it into an Android project.
Assume that your dependent project must build pure Java source in two ways:
debug build that produces a debug version in 'purejava.jar'
release build that produces a release version in 'purejava.jar'
The jar 'purejava.jar' is to be placed such that the Android project (could be a multi-project) is able to reference it at compile time, and it must therefore be the correct build to support both the debug and release configurations of the Android project.
How should this be tackled?
Since I am new to Android Studio and Gradle, I don't have a clear idea of how to manipulate extensions generated by the Android plugin, which are not available until after project evaluation.
How should the Android project be made dependent on this pure java project?
If it weren't for the fact that you need debug and release versions of your library, then your Android app could depend on a plain Java module just fine -- you could set up the library with the java plugin and put a compile project statement in the app's dependencies and it would work fine.
However, the Java plugin is never going to understand Android's notion of build types (unless GradleWare adds it at some point), so you can't propagate that to your Java modules. You could set up your plain Java project as an Android library and use the android-library plugin (you'll have to dummy out the manifest and other Android-specific stuff it expects to see in Android libraries), but you'll run into a different problem: https://code.google.com/p/android/issues/detail?id=52962 is a bug that reports that the build type is not propagated to library modules.
Until that bug is fixed, or if you're unwilling to make your plain Java library an android library, I think your only approach is to make two different versions of your library, compile them to different jar files, and selectively pull in dependencies.
This is my answer, with following project structure:
MyProject
-- MyAndroidLib
-- JarProject
This represents the gradle top project 'MyProject' which has a sub-project 'MyAndroidLib' which is dependent on a pure java project 'JarProject' which is built with different code for debug than for release builds.
I'll take advantage of Android's 'debugCompile' and
'releaseCompile' configurations. In the Android sub-project ('MyAndroidLib') that is dependent on the jars, add following lines to the dependencies:
//MyAndroidLib build.gradle
def jarProject = project(':MyProject:MyAndroidLib:JarProject')
def jarPath = pcfProject.projectDir.toString()
dependencies {
....
compile jarProject
debugCompile files(jarPath + '/' + jarProject.debugJarName)
releaseCompile files(jarPath + '/' + jarProject.releaseJarName)
}
The 'jarProject' def is defined to simplify accessing it from the MyAndroidLib project. (If you know a better way ...)
The main point of this is to define a separate debug and release jar path for the 'debugCompile' and 'releaseCompile' configurations. The 'debugJarName' and 'releaseJarName' are defined in a gradle.properties file for the JarProject as follows:
//JarProject gradle.properties
debugJarName=jarproject_d.jar
releaseJarName=jarproject_r.jar
In the gradle file for JarProject define a task that builds BOTH jar files named by this properties file. In my case, they are built right in the project folder by the 'compile' target of an ant build file located in that project.
//JarProject build.gradle
apply plugin: 'java'
project.ext.set("debugJar", file(projectDir.toString() + "/" + debugJarName))
project.ext.set("releaseJar",file(projectDir.toString() + "/" + releaseJarName))
task buildJars(type: Exec) {
description 'Build the debug and release jars for the JarProject'
outputs.files debugJar,releaseJar
commandLine 'ant', 'compile'
}
task compileJava.dependsOn('buildJars')
artifacts {
buildJars
}
clean.dependsOn('cleanBuildJars')
clean << {
exec {
commandLine 'ant', 'clean'
}
}
I took advantage of the 'java' plugin since it defines a 'compile' interface, and I haven't figured out how to build this from scratch, or even from the 'base' plugin. This project takes advantage of the automatic 'cleanBuildJars' task created because I defined the outputs in 'buildJars' task. This is necessary in order to have them built as needed. I probably need to define the 'inputs' too, since if they change ...
If anyone sees how my first stumblings in the gradle/Android world can be improved, pls. add comments as needed.
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.