Disable New Relic for Android debug builds

Thanks for letting us know that Paul’s workaround doesn’t work for you, @vinay.nagaraj. Our engineering team is currently working on sorting this. Hang tight and we will update this thread as we learn more on the progress!

The problem is that with

it no longer filters it’s effect only to debug builds

For anyone following this thread… Changes were made in the Android Gradle plugin version 3 which required a change to our instrumentation process. Because of these changes, the workaround listed above will no longer work with the updated Gradle plugin.

We are looking to introduce a feature allowing instrumentation to be skipped for certain builds. We’ll update this post when we have more details.

4 Likes

@spotts Any updates on this topic?
Best,
–I

@imanol I found another possible workaround for selectively instrumenting the app based on build types.

Within the project level build.gradle file, I wrapped the agent’s Gradle plugin in validation (and printed a log to confirm):

    dependencies {
        classpath 'com.android.tools.build:gradle:3.0.1'
        if (getGradle().getStartParameter().getTaskRequests().toString().contains("Release")){
            println("Enabling New Relic")
            classpath 'com.newrelic.agent.android:agent-gradle-plugin:5.+'
        }
    }
...

This validation should also be wrapped around references which apply the agent’s plugin to module level build.gradle files (to resolve Plugin with id 'newrelic' not found errors).

apply plugin: 'com.android.application'
if (getGradle().getStartParameter().getTaskRequests().toString().contains("Release")){
    apply plugin: 'newrelic'
}

In my app, I was able to only instrument Release builds with this configuration - please let me know if it works for you!

2 Likes

Sounds great.
Let me check it.

1 Like

Let us know how that works out for you @imanol. If @nromike’s solution works, please be sure to select the checkbox icon under his post so others will know the answer too!

This solution works great when building the project from Android Studio, but doesn’t pick up the configuration correctly when building it from the command line :frowning: It’s a good start as it can speed up the day-to-day dev work, but can’t be really commit-ed to a source control, as it’ll break any CI systems in place.

Thanks for that additional insight @iliev.vesselin - appreciate you sharing what you learned.

This almost works for me. Unfortunately I tend to type gradle shorted commands ( for example assembleDe instead of assembleDebug). I noticed that getTaskRequests shows what I typed on command line, before resolving to the full task name, so this will be a deal braker for me.

I also noticed that I don’t need to skip the classpath declaration on my plugin version (specified as 5.+, resolved as 5.22.0 today).

I went instead with the solution from https://stackoverflow.com/questions/31379795/how-to-apply-plugin-to-only-one-flavor-in-gradle where a flag is introduced either at command line, or as I prefer, added to ~/.gradle/gradle.properties (in my case the presence of the flag skips new relic, so CI will enable it by default).

I’ll also rant a little bit since I’m here. I have used this product in the past, but for backend spring microservices. One more time I’m deeply disappointed with this company. It’s hard for me to believe there’s a legitimate reason to apply changes to builds where NO file was modified. It creates lots of problems, including totally breaking instant run in my case. The problem is compounded by the lack of straigthforward official support for turning this nasty behaviour off.

If it was for me no company would use New Relic at all. But devs rarely get a say, and it’s too easy to get away with post sales problems that decision makers don’t have to put up with.

Is there any progress on this? It would be great to have a well documented (in official NR documentation for the SDK integration) and non-brittle (aka not susceptible to break due to upgrading Gradle/Android Gradle Plugin) solution to this.

In my scenario, this is adding a lot of time to building what should be simple changes. In fact, it breaks Gradle caching completely, since the Build ID inside of a generated NewRelicConfig.java file changes with every build, irrespective of whether any changes to code are made or not. It would be great to prevent this build ID from regenerating with every build for debug (or other) build types.

1 Like

Firebase performance monitoring introduced a flag in the gradle.properties for this, I suggest that you do the same: It’s called firebasePerformanceInstrumentationEnabled. It can be disabled on debug builds then overridden to true for other builds.

2 Likes

Great tip, @sakis.kaliakoudas! Thank you for adding this solution! :blush:

It is not a solution, I am just pointing out what exists on Firebase Performance Monitoring :slight_smile: Your product should offer a similar flag, but that needs engineering work from your side.

1 Like

@sakis.kaliakoudas - Thanks for clarifying that I’ll make sure our mobile teams see this. :slight_smile:

@RyanVeitch
Has this feature been added? If not, what is the ETA for this feature request?

No news to share on this today, @skozyrev. This solution seems to work well for some—let us know if it gets you closer to a solution in the meantime!

It should be noted that if you disable instrumentation (by not applying the New Relic Gradle plugin as stated in the accepted answer), normal analytics and crash logs are also disabled.

Upon initialization of New Relic, you’ll get the following in your logcat:

E/com.newrelic.android: Failed to detect New Relic instrumentation. Something likely went wrong during your build process and you should visit http://support.newrelic.com.

Here’s the logcat messages you’ll get if you try to use logError with an IllegalStateException:

E/com.newrelic.android: Agent.getBuildId() was unable to find a valid build Id. Crashes and handled exceptions will not be accepted.
E/com.newrelic.android: Invalid (null or empty) build ID detected! Crash will be ignored by collector.
E/com.newrelic.android: ExceptionHelper: java.util.UUID:fromString(UUID.java:194) RandomUUID[java.lang.IllegalArgumentException] Invalid UUID string: 
E/com.newrelic.android: Harvest instance is not running! Session duration will be invalid
E/com.newrelic.android: AgentDataReporter not initialized
E/com.newrelic.android: HandledException: exception java.lang.IllegalStateException failed to record data.

I didn’t try recordBreadcumb, recordCustomEvent or recordMetric for general analytics but I imagine their fate is the same.

Based on these discoveries, I don’t really think disabling the plugin should be the accepted answer and the New Relic Android team should really build in a flag to disable instrumentation properly (but still generate things like BuildId)

1 Like

FWIW we just updated a bunch of stuff

  • Android Gradle Plugin 3.5.0 -> 3.6.0.beta02
  • Gradle 5.4.1 -> 5.6.3
  • NR Gradle plugin 5.23.0 -> 5.24.0
  • NR SDK 5.23.0 -> 5.24.0

Doing a clean build,

:app:transformClassesWithNewrelicTransformForDebug now only takes ~4 seconds (vs 1m 15 sec)

When we rebuild w/out changing any code, :app:transformClassesWithNewrelicTransformForDebug still runs but again takes only 4 sec,

So I’m still seeing the problem in NewRelic GradlePlugin should stop deleting temp files but it’s only costing us 4 seconds.