Tiramusu Thoughts

Tiramusu Ideas

Leaks about what will be coming up Android 13 / Android T / Tiramusu are building
the rounds, in spots like XDA Developers
and Android Police. Some of what
is talked over will have very little effect on developers. Other factors will be your
usual “double-edged sword” of possibility and pain.

So, let us slice some tiramisu with a sword.

Notification Permission

It seems as even though becoming capable to elevate notifications will need a runtime
authorization. XDA has screenshots
showing “Notifications” as a permission along with other regular runtime permissions
like “Camera” and “Contacts”. This indicates that there will be a new perilous
permission for notifications.

However, “notifications” is a somewhat broad bucket. Application developers are heading to have to
do a truthful bit of get the job done to educate buyers about how the app utilizes notifications right before
presenting the permission. Potentially that education and learning process alone will assistance to get companies
to minimize back on the variety of superfluous notifications that are offered.

My major worry in this article, while, is what occurs when the authorization is declined by the
person. Usually, with these permissions, that triggers a SecurityException when you
endeavor to use an API tied to the permission. So, in this situation, possibly notify() on NotificationManager
would toss a SecurityException.

My honest hope is that possibly this does not come about or it is something we can choose out of
(e.g., via StrictMode). Preferably, this is a peaceful failure, logging messages to Logcat
but not crashing the app.

Google went out of their way, for a much better section of a decade, to shove notifications
down the throats of developers. With quite a great deal all the other risky permissions,
Google merely manufactured APIs readily available, then restricted them afterwards. In the scenario of notifications,
nevertheless, Google proactively took measures to test to persuade builders to depend on
notifications. Stating that “OK, now what we explained to you to do is at possibility of crashing your app”
is just plain impolite.

We also have to offer with particular notification scenarios. For case in point, does this permission indicate that
foreground expert services are impossible if people drop the permission? What happens if
libraries elevate notifications? And so on.

Of all the proposed adjustments, this a single scares me the most, just in terms of how Google
may possibly go about implementing it and the impacts it can have on builders.

TARE: The Android Useful resource Financial state

XDA also talks about TARE: The Android Source Overall economy.

The strategy that customers may have some way of supplying good-grained tips on what
they want to permit applications to do in the history is appealing. The UI shown in that
XDA article is dreadful (WTAF is a “satiated balance”?), but the principle has some benefit.

Nevertheless, each and every 12 months Google goes in and modifications the guidelines as part of The War on Track record Processing
that has been going on for 6+ several years. Blend that with
manufacturer-specific changes and builders are completely
lost as to what we can and can not do on any presented unit. That in change leads end users to think
that applications or products are broken, just because builders are not able to retain apace with documented
and undocumented regulations.

IOW, it would be seriously instead good if Google caught with a strategy for far more than a year and
took steps (e.g., CDD regulations) to get makers to adhere with that similar plan.

For each-App Locale Configurations

For a long time, developers have resorted to hacks to make it possible for a one app to assist
several languages, by messing with Locale. When this seems to have held up much better
than I would have envisioned over the several years, there are however severe gaps. The greatest
is any UI that comes from other processes, these as notification dialogs — all those
processes will not have the custom made Locale and will exhibit their contents in the
default language specified for the device as a entire.

Through a “panlingual” attribute,
Android 13 could possibly allow for customers to decide on a locale for every app via Configurations.

On the one particular hand, this appears excellent.

On the other hand…

• Wherever does the language modify close? It will be attention-grabbing to see how they distinguish
  “showing the program file UI by way of Motion_Open_Doc” and “launching Snapchat”.
  The former, in principle, should to observe the language selected for the application that tends to make
  the ask for the latter ought to adhere to the language of the app that is started off. Nonetheless, in
  both situations, the requesting application is just contacting startActivity() or startActivityForResult().

• Will Google provide Compat code that will merge the new Android 13 ability
  with Google-supported sorts of Locale switching for more mature gadgets? If of course, how will
  they cope with suppliers that are unsuccessful to support the Intent for making it possible for users to change a language?
  If no, how will Google suggest builders on supporting the two the new method and the old
  hacks in the exact same application?

These are early leaks. The matters demonstrated in these leaks may possibly not ship, or they might ship in considerably
distinct variety. And Android 13 is likely to have several additional new attributes than these,
such as some that impression developers. With luck, all my worries will vanish in the
breeze and it will change out that almost everything is awesome.

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

— Jan 15, 2022