Tiramusu Thoughts

Leaks about what will be coming up Android 13 / Android T / Tiramusu are making the rounds, in places like XDA Developers and Android Police. Some of what is discussed will have little impact on developers. Other things will be your typical “double-edged sword” of opportunity and pain.

So, let’s slice some tiramisu with a sword.

Notification Permission

It appears as though being able to raise notifications will require a runtime permission. XDA has screenshots showing “Notifications” as a permission alongside other standard runtime permissions like “Camera” and “Contacts”. This suggests that there will be a new dangerous permission for notifications.

However, “notifications” is a rather broad bucket. App developers are going to have to do a fair bit of work to educate users about how the app uses notifications before presenting the permission. Perhaps that education process alone will help to get firms to cut back on the number of superfluous notifications that are presented.

My biggest concern here, though, is what happens when the permission is declined by the user. Typically, with these permissions, that triggers a SecurityException when you attempt to use an API tied to the permission. So, in this case, perhaps notify() on NotificationManager would throw a SecurityException.

My sincere hope is that either this does not happen or it is something we can opt out of (e.g., via StrictMode). Ideally, this is a quiet failure, logging messages to Logcat but not crashing the app.

Google went out of their way, for a better part of a decade, to shove notifications down the throats of developers. With pretty much all the other dangerous permissions, Google simply made APIs available, then restricted them later. In the case of notifications, though, Google proactively took steps to try to convince developers to rely upon notifications. Saying that “OK, now what we told you to do is at risk of crashing your app” is just plain rude.

We also have to deal with specific notification scenarios. For example, does this permission imply that foreground services are impossible if users decline the permission? What happens if libraries raise notifications? And so on.

Of all the proposed changes, this one scares me the most, just in terms of how Google might go about implementing it and the impacts it can have on developers.

TARE: The Android Resource Economy

XDA also talks about TARE: The Android Resource Economy.

The idea that users might have some way of offering fine-grained advice on what they want to allow apps to do in the background is interesting. The UI shown in that XDA article is dreadful (WTAF is a “satiated balance”?), but the concept has some merit.

However, each year Google goes in and changes the rules as part of The War on Background Processing that has been going on for 6+ years. Combine that with manufacturer-specific changes and developers are completely lost as to what we can and cannot do on any given device. That in turn leads users to assume that apps or devices are broken, just because developers cannot keep apace with documented and undocumented rules.

IOW, it would be really rather nice if Google stuck with a plan for more than a year and took steps (e.g., CDD rules) to get manufacturers to stick with that same plan.

Per-App Locale Settings

For a long time, developers have resorted to hacks to allow a single app to support multiple languages, by messing with Locale. While this appears to have held up better than I would have expected over the years, there are still serious gaps. The biggest is any UI that comes from other processes, such as notification dialogs — those processes will not have the customized Locale and will display their contents in the default language specified for the device as a whole.

Through a “panlingual” feature, Android 13 might allow users to choose a locale per app via Settings.

On the one hand, this seems wonderful.

On the other hand…

• Where does the language change end? It will be interesting to see how they distinguish “showing the system file UI via ACTION_OPEN_DOCUMENT” and “launching Snapchat”. The former, in theory, ought to follow the language chosen for the app that makes the request; the latter ought to follow the language of the app that is started. Yet, in both cases, the requesting app is just calling startActivity() or startActivityForResult().

• Will Google provide Compat code that will combine the new Android 13 capability with Google-supported forms of Locale switching for older devices? If yes, how will they handle manufacturers that fail to support the Intent for allowing users to switch a language? If no, how will Google advise developers on supporting both the new approach and the old hacks in the same app?

These are early leaks. The things shown in these leaks may not ship, or they may ship in substantially different form. And Android 13 is likely to have many more new features than these, including some that impact developers. With luck, all my worries will vanish in the breeze and it will turn out that everything is awesome.

I’m a Murphy, though, so I’m not counting on that.