Making Android Lint Theme Aware — Part 2
Over the last year or so, we have seen a lot of apps provide support for Dark Theme in their apps. Android Q brought this toggle to the system setting. Eventually, users will expect all apps to have/provide support for Dark theme and apps not doing so will be the exception rather than the norm.
Through these series of posts, we’ll see how we can use Android Lint to help us build and eventually maintain an app that supports a day and night theme variant.
You can read Part 1 here:
In Part 1, we saw how we can write a lint check that will flag layouts and drawables files which have hardcoded hex color values (#FFFFFF) and help in migrating them to use color resources (@color/white) instead.
In this post (Part 2), we’ll see how we can detect color resources that don’t have a corresponding dark theme (night qualifier) variants.
First up, let’s define the lint issue describing the problem we are looking for in our source code:
The issue is self-explanatory, so let’s look at the detector class (MissingNightColorDetector) that we have already bonded this issue with.
In Android, colors resources are defined under the values folder in a colors.xml file. Since we are looking for issues inside XML files, we’ll use the ResourceXmlDetector which defines how an XML file is parsed. It might help to understand the XML markup before proceeding. You can read about it here.
In Part 1, when we were looking for hardcoded colors, we looked at XML attributes. For parsing the colors.xml file (located inside the values folder), we need to look at XML Elements. We simply can’t declare support for the name attribute as that will also match other resources like String Resources, Style Resources, etc. Hence we declare support for the “color” element (see: getApplicableElements) and then look at the name attribute inside the “color” element.
visitElement is then called for each XML element that the detector has mentioned it wants to analyze. Here, we extract out the color name (and NOT its value) and store it in a list representing the configuration of the values folder (regular/night). Finally when project inspection is complete (afterCheckEachProject), we report an issue for every color that exists in the regular value folder but not in the night variant folder.
Finally, update the registry to include the new check:
Run the lint check as usual and we should see new lint errors appear in the project (if there are missing night variant color resources).
That's it! With both the lint checks in place, warnings will be raised if we ever use a hardcoded hex color in our layout/drawables app and if we add a color resource but forget to add a corresponding night variant for it. By integrating lint checks with the CI system, these are a few less thing us developers need to worry about in code reviews/PRs.
The above code has been converted to a lint checks library for developers to easily integrate with their apps. Check it out at https://github.com/saurabharora90/Lint-Checks.
Remember to appreciate (clap) the post if you learned something or it was helpful.
