Open troy-skydio opened 1 week ago
Hello @troy-skydio!
Can you please give more details about your setup? Like the following:
Ideally we would appreciate if you can attach simple project illustrating your setup.
@0xnm I appreciate the quick response!
Are these symbol files unique per build variant or they are the same for any variant?
They are the same for all variants.
Are you still using AGP for compiling Java/Kotlin code?
As of right now, yes. We use bazel elsewhere and want to move to that, but for this discussion we can ignore that and just assume AGP for the Java and Kotlin code.
What triggers compilation of native symbol files: is it a Gradle task or something else?
It is not Gradle. Essentially, the build system used for other parts of our ecosystem (bazel) is used to build the native code, then after that the Gradle build starts and it pointed to the output directory of the native build. This is done via a build script that builds the native code first, before calling into Gradle.
As for a simple project illustrating this, I'm not really sure how doable that is. I'd have to either share our real code (which I cannot do) or copy parts of our system to a new project and put it all together (which I don't have time to do). I'm hoping just knowing that the native build process is totally separate from Gradle is enough to move forward with ideas.
FWIW, this is how we tell Firebase (which we want to replace with Datadog) where the native symbols are:
firebaseCrashlytics {
unstrippedNativeLibsDir "../common/jniDebugLibs/local"
strippedNativeLibsDir "build/intermediates/stripped_native_libs/" + flavor + buildType + "/out/lib"
nativeSymbolUploadEnabled true
}
Hi @troy-skydio ,
thanks for those precisions, for now our gradle plugin is expecting standard project set up. We're adding a task in our backlog to add an option to allow non standard native builds, quite similar to what we did in #199.
@xgouchet great thank you!
Do you have any suggestions for us to do in the meantime? Maybe a cli..?
Also, is it expected that native crashes won't show up in datadog if the symbols are not uploaded? I've triggered test crashes in our app's C++ and they do not show up in the dashboard.
For native crashes to appear in your dashboard, you need to include Datadog's NDK specific library :
In your build.gradle[.kts]
file, add the following dependency :
dependencies {
// …
implementation ("com.datadoghq:dd-sdk-android-ndk:x.x.x")
}
Then in your Android Application class, after the Datadog SDK has been initialized, you need to call the following line (usually in the onCreate
):
class SampleApplication : Application() {
override fun onCreate() {
super.onCreate()
// RUM and/or Logs were initialized before
NdkCrashReports.enable()
}
}
Do you have any suggestions for us to do in the meantime? Maybe a cli..?
For now we don't have a cli tool that can upload the NDK symbols. One thing you can do is create a fork of our plugin and override this check by forcing the value to true
, that way you'll be able to upload your NDK symbols.
The Issue
My team does not use the standard Gradle NDK tooling, and thus this plugin is not generating the
uploadNdkSymbolFilesRelease
task.I see
[INFO] [DdAndroidGradlePlugin] No native build tasks found for variant x, no NDK symbol file upload task created.
when running./gradlew tasks
. I took a look through this repo, and it seems like this task is only generated whenvariant.externalNativeBuild != null
.We don't use Gradle to build our native code, so we have no need to have a
externalNativeBuild{}
in our Gradle files, and yet we do have native code that we'd like symbolicated for native crash reports.Potential Solution
Maybe there is an existing way around this, and I'd be happy to hear it. But, if there isn't I think the following could work.
Allowing a configuration block where we could explicitly enable the NDK feature for Datadog would be great. Maybe something like:
Alternatives I've Tried
I tried adding a dummy
externalNativeBuild{}
block, but to no avail. The task is still not generated, and even if it was, I doubt the current implementation would be able to find the.so
files our build system generates which is why an option to specify that directory would be nice.