Tiramusu Thoughts

Leaks about what will be coming up Android 13 / Android T / Tiramusu are makingthe rounds, in places like XDA Developersand Android Police. Some of whatis discussed will have little impact on developers. Other things will be yourtypical ���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 runtimepermission. XDA has screenshotsshowing ���Notifications��� as a permission alongside other standard runtime permissionslike ���Camera��� and ���Contacts���. This suggests that there will be a new dangerouspermission for notifications.

However, ���notifications��� is a rather broad bucket. App developers are going to have todo a fair bit of work to educate users about how the app uses notifications beforepresenting the permission. Perhaps that education process alone will help to get firmsto 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 theuser. 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 NotificationManagerwould 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 Logcatbut not crashing the app.

Google went out of their way, for a better part of a decade, to shove notificationsdown 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 uponnotifications. 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 thatforeground services are impossible if users decline the permission? What happens iflibraries raise notifications? And so on.

Of all the proposed changes, this one scares me the most, just in terms of how Googlemight 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 whatthey want to allow apps to do in the background is interesting. The UI shown in thatXDA 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 Processingthat has been going on for 6+ years. Combine that withmanufacturer-specific changes and developers are completelylost as to what we can and cannot do on any given device. That in turn leads users to assumethat apps or devices are broken, just because developers cannot keep apace with documentedand undocumented rules.

IOW, it would be really rather nice if Google stuck with a plan for more than a year andtook 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 supportmultiple languages, by messing with Locale. While this appears to have held up betterthan I would have expected over the years, there are still serious gaps. The biggestis any UI that comes from other processes, such as notification dialogs ��� thoseprocesses will not have the customized Locale and will display their contents in thedefault 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 makesthe request; the latter ought to follow the language of the app that is started. Yet, inboth cases, the requesting app is just calling startActivity() or startActivityForResult().

Will Google provide Compat code that will combine the new Android 13 capabilitywith Google-supported forms of Locale switching for older devices? If yes, how willthey 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 oldhacks in the same app?

These are early leaks. The things shown in these leaks may not ship, or they may ship in substantiallydifferent 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 thebreeze and it will turn out that everything is awesome.

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