Unable to use the Native SDK to set up Sentry Tracing custom instrumentation for Android

[sillycelli]

Description
Hello!

TLDR: We are unable to use sentry-native to set up custom Sentry Tracing for Android. Would really appreciate some information and context as to whether or not this is expected.

I recently did some work to set up custom instrumentation for the Sentry Tracing feature. Our project supports multiple platforms, one of which is Android.

I initially tried to use sentry-native to set up Android custom instrumentation. I verified that the sample rate was set to 100% in my Android project. I also confirmed via breakpoints that all the necessary methods for Sentry Tracing are being called when expected. However, no Sentry transactions are sent from Android when using sentry-native.

Upon further investigation, we discovered a log line that seems related:
sentry-native com.mypackage I throwing away transaction due to sample rate or user-provided sampling value in transaction context

It appears that there may be a bug with sentry-native that does not respect the sample rate set for Android. Using the native SDK for our desktop platforms works great, so this seems to be an Android-specific issue. We are also able to use features such as Crash Reporting with Android using sentry-native, so it's perplexing that Tracing does not also work.

It would be great to be able to use sentry-native for this purpose to avoid unnecessary bridging. Any context or info you might be able to provide on this issue would be greatly appreciated.

When does the problem happen

• During build
• During run-time
• When capturing a hard crash

Environment

• OS: Android
• IDE: Android Studio

Steps To Reproduce

The setup is more involved than just a code snippet, but we followed the instructions pretty much exactly for setting up custom instrumentation for the native SDK. We are also setting the sample rate in our Android project in the AndroidManifest.xml:

<meta-data android:name="io.sentry.traces.sample-rate" android:value="1.0" />

We also tried setting it through our C++ code, but this did not work either.

Log output
I can provide other logs if needed, but this appears to be the most relevant log line when trying to run Android Sentry Tracing with sentry-native:

sentry-native com.mypackage I throwing away transaction due to sample rate or user-provided sampling value in transaction context

[supervacuus]

Thanks for the report @sillycelli!

@markushi and @JoshuaMoelans, can you have a look? The log only means that the dice roll probably discarded the transaction due to the default 0 sample rate (for which I don't see a way to set it up when using native from the Android SDK, i.e. this currently unsupported). I am also not sure whether the sentry-android outbox processing would accept transaction payloads from the Native SDK.

The setup is more involved than just a code snippet, but we followed the instructions pretty much exactly for setting up custom instrumentation for the native SDK.

It would still help to see how you set up the Native SDK and your transactions (whether a transaction is dropped, which is what the log signals, is decided during transaction construction).

We are also setting the sample rate in our Android project in the AndroidManifest.xml:

<meta-data android:name="io.sentry.traces.sample-rate" android:value="1.0" />

We also tried setting it through our C++ code, but this did not work either.

The Android sample-rate will not be synchronized with the Native SDK, and the Native SDK initialization is done entirely from sentry-android, so it is unclear how you tried setting a sample-rate from the native code.

[sillycelli]

Hi @supervacuus , thanks for getting back to me so quickly!

As for trying to set the sample rate from native code, I am pretty certain I was trying something that shouldn't work. In general, we are setting the sample rate through the AndroidManifest.xml meta-data tag as shown in the issue description.

I didn't do the initial setup for the Native SDK as we had already set it up for crash reporting. However I believe we are just adding it as a dependency in our build.gradle file:

dependencies {
        // Sentry Crash Reporting
	classpath 'io.sentry:sentry-android-gradle-plugin:4.10.0'
        classpath 'io.github.howardpang:androidNativeBundle:1.1.4'
    }

The general flow for a transaction being constructed is as follows:

We have #include <sentry.h>

When starting a transaction:

auto* context = sentry_transaction_context_new(name, operation);
sentry_transaction_t* transaction = sentry_transaction_start(context, sentry_value_new_null());
sentry_set_transaction_object(transaction);

When finishing a transaction:
sentry_transaction_finish(transaction);

We also have some code for starting/finishing spans, which I can share as well if that would be helpful.

Please let me know if you need any other clarification or info.

[supervacuus]

Thanks for the details @sillycelli.

Please let me know if you need any other clarification or info.

No, from that response, what is happening is clear. Since sentry-android does not sync the trace sampling configuration and no explicit sampling configuration occurs in the JNI layer initialization of the Native SDK, you will hit a dice roll with a configured sample-rate of 0 (i.e., guaranteed to drop the transaction).

So, the short answer is: this is currently not supported for that use-case.

What is unclear to me is whether this was intentional, for instance, because isolated tracing between the Java and the native layer could lead to inconsistent/incomprehensible traces or whether this is just something that hasn't been attempted yet.

In any case, this is not a bug but a feature request because it would require defining what tracing should look like at the interface between the two SDKs.

The tracing docs you refer to were not written from an Android integration perspective since the downstream SDKs typically own the tracing on the respective platforms. Of course, we know that people often start from the Native SDK and then extend to other platforms, where tracing might already be in-place, like in your case.

CC: @kahest, @JoshuaMoelans, @markushi