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.
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
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
would throw a
My sincere hope is that either this does not happen or it is something we can opt out of
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
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
Will Google provide
Compatcode that will combine the new Android 13 capability with Google-supported forms of
Localeswitching for older devices? If yes, how will they handle manufacturers that fail to support the
Intentfor 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.