We just released a new version of LeakCanary, and it’s got several new features!
Heads up, we’ve moved! If you’d like to continue keeping up with the latest technical content from Square please visit us at our new home https://developer.squareup.com/blog
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.
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.
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.
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:
To set it up, see Uploading to a server.
Here is the complete changelog, please give it a try and give us feedback!