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.

UPDATE 2020-03-20: Rich Hong pointed me to the DP1 -> DP2 API differences report.

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. ¯\_(ツ)_/¯.

UPDATE 2020-03-25: They have refined the language here — the “nag” dialog to which I was referring is only for apps that use UsbManager. That reduces the scope of this problem dramatically.

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. UPDATE 2020-03-20: A Googler reached out to correct me on this one. Conscrypt has been used for SSLSocket for some time. However, there are some implementation tweaks in Android R — now SSLSocket is “just a wrapper” of SSLEngine. Again, there should be few problems here, but it is something to note.

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!

UPDATE 2020-03-20: I have more musings on R DP2!