Random Musings on the R Developer Preview 2

Each time Google releases a new developer preview, I read what I can
to see if there are things that warrant more attention from
developers. I try to emphasize mainstream features that any developer
might reasonably use, along with things that may not
get quite as much attention, because they are buried in the JavaDocs.

This time, I can���t readily do the ���buried in the JavaDocs��� part, because
the release notes
lacks a link to the DP1 -> DP2 API difference report. Instead, it has two
links pointing to the API 29 -> DP2 report,
which makes it more difficult for me to identify what is new to DP2.
If this gets fixed, I may
follow up with another blog post.

In the meantime, here are some musings, as random as ever���

Things That Might Piss Off Users

Apparently, Android R will nag users to not use a USB headset
with apps that��� don���t record audio. The workaround: have the app say that it records audio.
��\_(���)_/��.

Things That Could Break Your App

I worry that the package visibility changes
are going to break more apps than perhaps Google realizes. While I haven���t tested
this aspect of R DP2 yet, it appears that your app now can���t find out what other apps are installed,
on a general basis. The cited example is queryIntentActivities(), but to make
this really work you would need to seriously lobotomize PackageManager.
You can whitelist certain packages and certain <intent-filter>
structures to try to get by this for certain use cases. And, this is where
the mysterious QUERY_ALL_PACKAGES permission seen in DP1 comes into play ���
this permission removes these new restrictions. Given the ���look for Google Play
to provide guidelines for apps that need this permission��� caveat, it is safest to assume
that if you try using it, eventually you will be banned from the Play Store by a
bot.

If your app has been dutifully following the new Android 10 rules for
background location access��� get ready for new user flows.

If your app has been clearing the cache of other apps��� sorry, but
that appears to no longer be an option.

Probably the move to Conscrypt for SSLSocket
will not cause problems for most apps, but it���s something to keep an eye on.

Things That Are Generally Positive

android:preserveLegacyExternalStorage
might be useful for some developers, though I suspect not all that many.
Basically, it allows you to say that users who upgrade your app get old-style
external storage while new users get scoped storage, by my read of it.

Being able to use more than one camera
seems nice.

The blog post
mentions some new window inset options for more synchronized behavior with
soft keyboards as they collapse and expand. Strangely, I don���t see this in the main Android R
release documentation. It���s a slick feature, albeit one that I do not expect will get
adopted that much. As with Android 10���s gesture-based navigation, I think Google
is seriously over-estimating developers��� willingness to rewrite UIs for these sorts of things.
After all, we can���t get apps to support landscape, and that feature has been around since API Level 1.
So, while I���m sure highly-polished apps will use this new synchronized IME
stuff to become even more highly-polished��� most apps will muddle along as they have been.

Things That Make Me Go ���Hmmmmmm������

The per-process network access control
feature seems great��� except that the supplied XML is mystifying. Where
does this go? What does an empty <process /> element mean? What does
a <process> element without children mean? Does the allow-permission and
deny-permission element names, coupled with the fully-qualified permission names,
mean that this works for all permissions, not just android.permission.INTERNET?

What is referred to as dynamic intent filters
seems to overstate the case: the only dynamic element is the roster of supported
MIME types. The rationale given for this feature is:

This is a problem for virtualization apps (such as virtual machines and remote desktops) because they have no way of knowing exactly what software the user will install inside them.

That rationale seems odd to me. I certainly can���t rule it out, but it is unclear
under what circumstances ���virtual machines and remote desktops��� would know about
particular MIME types that they should support dynamically. Plus, virtual machines
would seem to be in violation of Play Store policies regarding dynamic code loading
just by existing. The feature seems fine, but something seems fishy.

What Happens Next?

I think I have found enough stuff that works to warrant releasing an
Elements of Android R in the coming weeks, so stay tuned!