Android’s Material You dynamic theming system is beautiful, but it hasn’t been adopted by many apps yet, particularly when it comes to the bigger names. That might partly be because it’s a messy process right now, and Google’s app-side libraries for implementing Material You outright impose an allowlist that limits compatibility to certain approved manufacturers. Fortunately, Google tells us that’s going to change in Android 13. And, according to a trusted source, Google has also dropped its requirement that smartphone manufacturers implement Material You on Android 12.
Those of you who haven’t been living under a rock for the last year are likely familiar with Google’s Material You theming, which allows colors from a background to be picked and parsed into a custom dynamic theme with unique accent colors and tinted background colors. It’s all automatic and preserves a minimum contrast for accessibility while providing a look many find beautiful.
The feature debuted with Pixels running Android 12 but became available in Android’s source code for other manufacturers to use with Android 12L/12.1. Google even created a series of patches that would let smartphone makers bring the feature to earlier Android 12 releases if they didn’t want to put in any more effort than absolutely required.
Custom themes on demand, courtesy of Material You.
In February, a trusted source provided us with documentation that showed Google was going to require Material You support for its GMS (Google Mobile Services) licensing. Essentially, if you wanted your phone to run Android 12 and have access to Google’s Play Store and other apps, you’d need to implement Material You. This would make sense, except that we recently discovered Google was also imposing an allowlist for the libraries it provides app makers to implement Material You. That means developers that use Google’s libraries in their apps to create Material You apps will only see it work on phones that Google has explicitly approved Material You to work on. Mix in the GMS requirement, and things start to seem incredibly restrictive, with Google both imposing Material You as a requirement but then only allowing certain companies to actually use it. It’s a confusing and frustrating situation based on an understandable limitation.
It’s not intuitive, but Google’s explanation for why there was an allowlist to begin with actually makes sense. There are two key things to remember. First, Material You was built to ensure customization didn’t interfere with accessibility. Google invented its own color space just for Material You, all to make sure that it had a perceptually accurate way of measuring lightness and contrast. This is to ensure that the colors the system generated didn’t clash in a way that makes buttons or text hard to read. The company succeeded, and this system works very well, but then this brings me to my second point: There’s nothing that stops smartphone manufacturers from making bad and stupid changes to Android. In fact, they love to do it under the guise of product differentiaton, deluding themselves into believing their weird theme, arbitrary UI changes, and confusing reorganization is somehow an added value on their product, rather than just wasted time and effort that delays updates and breaks expected behaviors.
All this means that there’s nothing stopping smartphone companies from implementing Material You but then changing it in some shortsighted way that breaks how it is supposed to work in a way that interferes with accessibility. Frankly, it’s almost certain they would do something like that if given the freedom to, simply out of ignorance. The only way Google can verify that they did it “right” is by testing each implementation, and that’s how you end up with the allowlist we have.
Fortunately, this mess will eventually be cleared up, starting with a change to that GMS licensing. We’re not sure precisely when it changed, but a trusted source tells us that Google has dropped its Material You requirement for Android 12’s GMS licensing, and it’s only imposing a specific set of standards for devices that do actually implement it. On top of that, Google plans to do away with its Material You library allowlist entirely with Android 13, according to comments regarding issues on the project’s GitHub. Google further tells us that it plans to create a series of automated tests that verify that Material You is implemented correctly, but not until Android 13. According to a Google spokesperson:
“In Android 12, there is no automated test to validate if vendors provide colors meeting requirements for visibility, readability, and accessibility. To enable vendors to participate in the Material You from day 1, we work with vendors individually to implement and verify Material You This ensures that vendors don’t accidentally create colors that affect legibility, and that developers and users can expect a consistent experience with Material You. In Android 13, automated testing of color schemes will allow a different strategy.”
In the meantime, smaller smartphone manufacturers can apply to be included in the allowlist, and Google made it sound like a simple-enough process. But there is one last unforeseen consequence.
The current allowlist state means that custom ROMs can’t implement Material You on Android 12 if the device manufacturer they’re developing software for wasn’t approved. This sounds like a “whatever” issue, but it has other ramifications. In many cases, ROM maintainers are also app makers, so this has the knock-on effect of disincentivizing some of the Android community’s most influential developers from making Material You-compatible apps right now. Google is indirectly encouraging some of its biggest and most influential fans not to adopt Material You. We’ve reached out to Google to see if there’s anything ROM developers can do to work around this issue before Android 13 “fixes” it.
Material You may be beautiful, but developers haven’t adopted its dynamic color theming as quickly as we had hoped. There are some apps updated to use Material You’s themes, but I hope these upcoming changes can make developers’ lives easier and further encourage adoption.