seekingStillness
seekingStillness

Reputation: 5103

Should I remove leak canary code/classes for release build?

I searched for an answer to this and couldn't find anything, which probably means it's a basic question. At the risk of showing my ignorance, I'm going to ask anyway. I am preparing my app for release and want to insure Leak Canary doesn't popup for my users. My leak canary related dependencies are as such.

dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
}

I think that since the releaseCompile contains no-op it means I can proceed with my release build as is without removing the Leak Canary code. Am I right?

Upvotes: 9

Views: 5184

Answers (3)

Mahmoud
Mahmoud

Reputation: 2893

I was using the latest version of the library 2.0-alpha-1 in debug mode, and I didn't find the release dependency of the library. I did the following:

  1. I created separate folders for each build mode (release and debug)
  2. The path of the debug folder: app/src/debug
  3. The path of the release folder: app/src/release

Then I created a class for initializing leak canary called LeakCanaryInitializer.kt (I created it inside the two build folders)

  • debug: app/src/debug/java/LeakCanaryInitializer.kt
  • release: app/src/release/java/LeakCanaryInitializer.kt

The class in the release mode contains:

import android.content.Context
object LeakCanaryManager {

  fun init(context: Context) {
    // We should do nothing in the release mode
  }
}

The class in the debug mode contains:

import android.content.Context
import leakcanary.LeakCanary
import leakcanary.LeakSentry

object LeakCanaryManager {

  fun init(context: Context) {
    // Here you should write your custom initializing
  }
}

Then in your Application class call the init method:

LeakCanaryManager.init(this)

My gradle file only contains the debug dependency:

debugImplementation "com.squareup.leakcanary:leakcanary-android:2.0-alpha-1"

Upvotes: 3

sudocoder
sudocoder

Reputation: 1173

The answers are correct but there's an updated and easier solution as of 4/13/19:

    dependencies {
      debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.0-beta-3'
    }

no need for no-ops nor proguard.

but why?

ok but how?

Upvotes: 5

seekingStillness
seekingStillness

Reputation: 5103

I found this online.

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'
}

Upvotes: 14

Related Questions