Tiramusu Ideas


Tiramusu Ideas

Leaks about what can be developing Android 13 / Android T / Tiramusu are making
the rounds, in locations like XDA Builders
and Android Police. A few of what
is mentioned can have little impression on builders. Different issues can be your
typical “double-edged sword” of alternative and ache.

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

Notification Permission

It seems as if with the ability to increase notifications would require a runtime
permission. XDA has screenshots
displaying “Notifications” as a permission alongside different normal runtime permissions
like “Digital camera” and “Contacts”. This implies that there can be a brand new harmful
permission for notifications.

Nevertheless, “notifications” is a relatively broad bucket. App builders are going to need to
do a good bit of labor to coach customers about how the app makes use of notifications earlier than
presenting the permission. Maybe that schooling course of alone will assist to get companies
to chop again on the variety of superfluous notifications which are introduced.

My largest concern right here, although, is what occurs when the permission is declined by the
consumer. Usually, with these permissions, that triggers a SecurityException while you
try to make use of an API tied to the permission. So, on this case, maybe notify() on NotificationManager
would throw a SecurityException.

My honest hope is that both this doesn’t occur or it’s one thing we will choose out of
(e.g., by way of StrictMode). Ideally, this can be a quiet failure, logging messages to Logcat
however not crashing the app.

Google went out of their method, for a greater a part of a decade, to shove notifications
down the throats of builders. With just about all the opposite harmful permissions,
Google merely made APIs out there, then restricted them later. Within the case of notifications,
although, Google proactively took steps to attempt to persuade builders to depend on
notifications. Saying that “OK, now what we instructed you to do is susceptible to crashing your app”
is simply plain impolite.

We additionally need to take care of particular notification situations. For instance, does this permission suggest that
foreground companies are unimaginable if customers decline the permission? What occurs if
libraries increase notifications? And so forth.

Of all of the proposed adjustments, this one scares me probably the most, simply when it comes to how Google
may go about implementing it and the impacts it might probably have on builders.

TARE: The Android Useful resource Financial system

XDA additionally talks about TARE: The Android Useful resource Financial system.

The concept customers might need a way of providing fine-grained recommendation on what
they wish to permit apps to do within the background is fascinating. The UI proven in that
XDA article is dreadful (WTAF is a “satiated stability”?), however the idea has some advantage.

Nevertheless, every year Google goes in and adjustments the principles as a part of The Battle on Background Processing
that has been occurring for six+ years. Mix that with
manufacturer-specific adjustments and builders are utterly
misplaced as to what we will and can’t do on any given gadget. That in flip leads customers to imagine
that apps or gadgets are damaged, simply because builders can’t hold apace with documented
and undocumented guidelines.

IOW, it could be actually relatively good if Google caught with a plan for greater than a yr and
took steps (e.g., CDD guidelines) to get producers to stay with that very same plan.

Per-App Locale Settings

For a very long time, builders have resorted to hacks to permit a single app to help
a number of languages, by messing with Locale. Whereas this seems to have held up higher
than I might have anticipated over time, there are nonetheless critical gaps. The most important
is any UI that comes from different processes, reminiscent of notification dialogs — these
processes won’t have the custom-made Locale and can show their contents within the
default language specified for the gadget as an entire.

By a “panlingual” characteristic,
Android 13 may permit customers to decide on a locale per app by way of Settings.

On the one hand, this appears fantastic.

Alternatively…

  • The place does the language change finish? It will likely be fascinating to see how they distinguish
    “displaying the system file UI by way of ACTION_OPEN_DOCUMENT” and “launching Snapchat”.
    The previous, in idea, should observe the language chosen for the app that makes
    the request; the latter should observe the language of the app that’s began. But, in
    each circumstances, the requesting app is simply calling startActivity() or startActivityForResult().

  • Will Google present Compat code that may mix the brand new Android 13 functionality
    with Google-supported types of Locale switching for older gadgets? If sure, how will
    they deal with producers that fail to help the Intent for permitting customers to change a language?
    If no, how will Google advise builders on supporting each the brand new method and the previous
    hacks in the identical app?


These are early leaks. The issues proven in these leaks might not ship, or they might ship in considerably
totally different type. And Android 13 is prone to have many extra new options than these,
together with some that impression builders. With luck, all my worries will vanish within the
breeze and it’ll end up that every part is superior.

I’m a Murphy, although, so I’m not relying on that.