Random Musings on a Trio of Bugs and Regressions in Android 12

Welcome to the first edition of my new column, Android Dessert Bites. Every week, I’ll be sharing news about the Android platform that should be of interest to developers and power users. If you’re looking for a news recap that doesn’t come in the form of 280-character tweets, then the Android Dessert Bites column is for you.

Without further ado, here’s the latest news that caught my attention.

Google broke an API in Android 12 ... but told nobody about it

When Google releases a new version of Android, there will always be breaking changes for many developers. APIs get deprecated or tweaked, and platform behaviors change to limit app functionality (often in the name of security or privacy). Keeping up with Android’s yearly release cadence can and will cause some headaches due to the sheer breadth of Android’s API surface, but we can at least rely on Google documenting breaking changes somewhere, right? Well, not always, as many developers of media apps recently found out.

If you build an app that can cast audio to an external device, then you need to be aware that Android 12 no longer passes the volume key event to remote media sessions. This means that users can’t adjust the volume of a cast session once they navigate away from your app. Expect a lot of angry emails from users who think you’re trying to lock them to your app just to change the volume.

You won’t find this new behavior documented anywhere on the Android docs, which is unusual because of how many apps are affected. One possible reason for Google’s poor communication is that the change wasn’t planned — it was forced. This is hinted at by comments left on a Google Issue Tracker report about this issue. On the Issue Tracker, a Googler apologized to developers for the breaking change, stating that it had to be done to address an unspecified “legal issue.” Whether that “legal issue” refers to the Sonos v. Google patent dispute is anyone’s guess, but what’s important is that the same Googler confirmed that “a solution to mitigate the situation” will be included in Android 12L.

Android 12L won’t be released until Q1 2022, though, so it looks like developers and users will have to live with this breaking change for a few months. That is, unless Google decides to backport the patches to Android 12 for the upcoming QPR1 release, which is technically feasible.

A stupid DoS is still a DoS

Upon Android 12’s release (for Pixel phones), the one feature that caught everyone’s attention is Material You’s dynamic theming system. It doesn’t really have a formal marketing name, so we’ve taken to calling Google’s algorithmic theming system by its code-name: monet. The theming engine employs a color extraction algorithm to pick the main hues from the user’s wallpaper, a palette generation algorithm to create a rich palette of colors based on those hues, and a color appearance model to resolve contrast issues. These dynamically generated colors are stored in an index that various system apps use, and third-party apps can call, to match their colors.

In order for the dynamically generated theme to be immediately reflected across the entire system and supported third-party apps, Android will recreate the activities of every currently running app. There are already a myriad of device configuration changes that can occur during runtime, so a new one shouldn’t ordinarily pose a problem for developers. However, theme changes in Android 12 effectively trigger an unblockable configuration change, so apps that can’t gracefully handle activity restarts — like games — will look to the user like they just crashed. The user may not realize the wallpaper change was the trigger, so you’ll likely see some users complain about “random” crashes on Android 12, especially if they have an app that automatically cycles the wallpaper in the background.

Speaking of which, since changing the wallpaper effectively results in a configuration change — thereby destroying and recreating all activities — and wallpaper changes can automatically occur in the background, this can be abused to set up a rudimentary denial-of-service attack. Google will likely mitigate this by preventing theme changes when a background app changes the wallpaper, but that fix won’t be available until Android 12L, which is coincidentally when “monet” will hit AOSP.

Android Episode 12: The Phantom (Process) Menace

In its never-ending quest to limit what apps can do in the background (while still appeasing OEMs, of course), Google has imposed a new (undocumented) background restriction in Android 12. This change likely won’t affect most developers, but if you’re a power user, you may be affected.

Android 12 now tracks “phantom processes,” which are child processes forked from a background app process. If these phantom processes use too much CPU or their number exceeds 32, then the system will terminate them. The “32” cap on the number of phantom processes is a global and not per-app limit, so an app that frequently spawns child processes in the background may not be able to run any background process if that limit is reached. This is beneficial in one sense in that it limits the CPU draw from phantom processes that were previously unmonitored by the framework, but it also means that apps whose functionality depends on forked child processes are crippled by the default parameters.

A developer who works on the Termux app — a popular Android terminal emulator and Linux environment — first brought this issue to our attention after users complained about errors following the Android 12 update. Following extensive research of the Android 12 source code, the developer published a lengthy report on the Google Issue Tracker that documents the new phantom process killing behavior, how it affects their application, and how to reproduce the problem. It’s worth a read if you’re interested in how Android tracks foreground and background process and how Android’s low memory killer decides how to terminate processes.

I hope you’ve enjoyed this tasty Snow Cone-flavored treat with me. (It’s always hot in Texas, so I’ll take a nice, cold dessert any time of the year!) This week’s column focused on bugs and feature regressions in Android 12, but not every column will have a central theme.

Android is such a large and quickly evolving platform that there’s always something new to talk about. The Android Dessert Bites column provides a sampling of the news that you won’t find in many other places, while the Esper blog is where to go if you want a broader, in-depth overview of the latest developments in the Android platform.

While we try to stay on top of things by scouring the AOSP Gerrit, Google Issue Tracker, and developer communities, there’s always a chance we’ll miss something worth talking about. If you find something you want us to talk about, or if you have something you want us to draw attention to, please reach out to me at mishaal@esper.io!

Android Device Management