Your data. Anywhere you go.

New Relic for iOS or Android


Download on the App Store    Android App on Google play


New Relic Insights App for iOS


Download on the App Store


Learn more

Close icon

Disable New Relic for Android debug builds

android
releases
mobile
gradle
instrumentation

#21

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.


#22

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


#23

@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!


#24

Sounds great.
Let me check it.


#25

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!


#26

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.


#27

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


#28

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.