It has been a hot minute since I posted about writing multi-module Lint rules so it’s time for a follow up. Today’s topic: suppressions! A quick recap of where we are:

I have been working with deeplinks lately and I noticed that quite a few things have changed since I last worked with them. The most important change is quoted in the list of Android 12 behaviour changes:

One of the more famous crash reporting tools used in Android development is probably Crashlytics. It offers up a lot of insight into an app’s performance – from device characteristics to insights on issue commonalities. If, like my current project, obfuscation is enabled in an app, Crashlytics has a Gradle plugin that uploads the mapping file so that we end up with readable crash reports.

About a year ago, I wrote about including quickfixes for Lint rules. Quick fixes appear on the context menu when Lint flags an error and allows developers to quickly address the issue. They can be applied by clicking on the link at the bottom of the dialog or pressing ALT+ENTER (⌥ + ↩) and then choosing the fix.

Back in August, I wrote about making an alias for finding the five most recent branches I have checked out by filtering out git reflog entries.

In my previous post, I talked about how to write a Lint rule that gathers information from different modules before performing a final analysis to determine if there are errors.

I have been learning a LOT about Lint the past year. Our team has grown 5x since I joined more than three years ago, and it became really obvious really quickly that we should be letting robots do a lot of the mundane and repetitive enforcement of our team’s code conventions.

One of the things we should be doing as Android developers is to ensure that our apps are as accessible as possible. There are a bunch of talks and articles that discuss the motivations behind current MDC a11y support, the basic steps to support a11y, testing overviews, even creating your own a11y service!

A few weeks ago, I tweeted about a discovery that blew my mind:

A few months ago, my team came upon an agreement that when leaving a TODO anywhere in our code, we need to always provide several things:

• the person who is expected to address the TODO
• date when the TODO was left
• a comment or explanation on what needs to be done