July 24th, 2018 | 1 minute read

LeakCanary 1.6 🐤

We just released a new version of LeakCanary, and it’s got several new features!

dependencies {
  debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.6.1'
  releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.6.1'
  // Optional, if you use support library fragments:
  debugImplementation 'com.squareup.leakcanary:leakcanary-support-fragment:1.6.1'
}

Update your build.gradle

Highlight of the leak cause

By determining the expected reachability of objects like Activity and View instances, LeakCanary now highlights the possible causes of the leak with a red underline wave.

We also simplified the leak trace UI and added in context help.

This leak was caused by either MainActivity.httpRequestHelper or HttpRequestHelper.button

The leak analysis runs in a foreground service

The analysis service now runs as a foreground service to support Android O+, with a progress notification that should help everybody understand what LeakCanary is doing at any given point.

We also turned off computation of the retained heap size by default, to reduce the analysis time.

Analysis in progress

Leak detection in UI tests

At Square, we run UI tests on every pull request (using Firebase Test Lab), and we wanted to make sure we could prevent new memory leaks from being merged to master.

LeakCanary runs at the end of every UI test and reports a test failure if a leak is detected.

UI Test failure in Square POS, the leak cause is in red.

To set it up, see Running LeakCanary in instrumentation tests.

Reporting traces to a crash backend

We wanted to track leaks without having to build a backend. It turns out that leak traces are fairly similar to stack traces. AnalysisResult.leakTraceAsFakeException() enables you to upload leaks as fake stack traces to your preferred crash reporter. Here’s an example with Bugsnag:

replay(1).autoConnect() caused a leak