Leakcanary: Production builds

[lawloretienne]

Will leak canary product notifications in the notification drawer in a production build or only in a debug build?

[artem-zinnatullin]

As you can see in the README, you can compile real LeakCanary for debug
builds only debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1' and use special version of
LeakCanary that does nothing (no-op) for release builds releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'.

[artem-zinnatullin]

Sorry for formatting (answered from email app).

dependencies {
    // Real LeakCanary for debug builds only: notifications, analysis, etc
    debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1'

    // No-Op version of LeakCanary for release builds: no notifications, no analysis, nothing
    releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
 }

[RicardoBelchior]

maybe lame question, but why do we need the releaseCompile dependency if "nothing" is done ?

[MGaetan89]

Because even if it does nothing, you still need to have the classes to compile your application.

[kusan-thana]

maybe lame question, but wouldn't if (BuildConfig.DEBUG) leakCanary.install(this) be cleaner?

[RicardoBelchior]

I believe that with that, even production code will go through that verification. Using releaseCompile:no-op, there's no need for an if statement. The install method is triggered but nothing happens.

[ozmium]

I still don't really understand the difference between using

if (BuildConfig.DEBUG) { leakCanary.install(this) }

and

releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'

It seems like the first option is better and more commonly used, because ProGuard (or the JVM hotspot compiler) can easily strip out the LeakCanary code in the release build. Most likely it can be stripped out at build time since BuildConfig.DEBUG is static final, whereas the 2nd option will always add in empty classes and empty methods.

Have I misunderstood something?

[JakeWharton]

LeakCanary adds components to the manifest for which aapt will generate
-keep designations and which transitively reference nearly the entire
library.

On Wed, Jan 10, 2018 at 9:53 AM ozmium [e-mail] wrote:

I still don't really understand the difference between using

if (BuildConfig.DEBUG) { leakCanary.install(this) }

and

releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'

It seems like the first option is better and more commonly used, because
ProGuard (or the JVM hotspot compiler) can easily strip out the LeakCanary
code in the release build. Most likely it can be stripped out at build time
with the static final BuildConfig.DEBUG, whereas the 2nd option will
always add in empty classes and empty methods.

Have I misunderstood something?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/square/leakcanary/issues/139#issuecomment-356625589,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEERVjZmDG-uaww--DUTHSinPFLeaYks5tJM7wgaJpZM4EiZJ9
.

[ozmium]

Ah ok. Thanks for clarifying. I was thinking of copying that info to the Readme file, so that people do not become confused when they see the 2 dependencies. I'm not sure if your team would want that though.