Random Musings on the R Developer Preview 1

Each time Google releases a new developer preview, I rummage through the API differences report the high-level overviews, and even the release blog post, 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.

As with the previous three releases, R seems to be lacking a prominent user-facing feature. I have no idea what I will tell my mother that she’ll gain if her phone gets the R update at some point.

Even the changes for developers seem relatively modest this time around. It’s almost like Android is maturing as a platform!

That being said, here are some things that caught my eye.

What May Make Users Unhappy

The phrasing around the file and directory access restrictions puts the blame on developers, suggesting that we ask users to grant us access Downloads/ document tree, or for files in Android/data/ directories.

In reality, developers don’t do that. Developers simply fire off ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, or ACTION_CREATE_DOCUMENT Intents. Where the user winds up choosing is up to the user.

So, the restrictions listed in this section will be placed on users, not developers. I do not know what sort of messaging Google could use in the Storage Access Framework UI that would justify to the user blocking them from navigating to certain portions of external and removable storage. “Sorry, you can’t choose Downloads/, because ¯\_(ツ)_/¯” doesn’t strike me as something that will make users very pleased.

I am all for improved user control over privacy and security concerns, but the boundaries between what is and is not allowed need to make sense to users and, secondarily, to developers.

What Will Irritate Developers

On the one hand, the “All Files Access” support should be a good thing. It gives file managers and similar sorts of apps an option for accessing more stuff on external and removable storage. However, it is not really “all files”, as Android/data/ is still blocked off. IMHO, the next step is to use the one-time permission system to allow these apps to have access to these protected areas (e.g., so a backup app can actually do a backup).

The background location restrictions are confusing as documented. I’ll be playing around with these and hopefully will work out some samples soon.

What Got Better

The batch media file access and access to media via “raw file paths” represent welcome improvements to the scoped storage restrictions added in Android 10.

The data access auditing – allowing you to track where you are accessing sensitive data and by what app feature – is promising, albeit confusing. I’m sensing a book chapter in my future…

The shared datasets feature, for apps sharing large quantities of static data – is a nice addition, but it is one of those things that may be difficult to backport. And, without a backport, its utility will be limited until Android 11+ is dominant, which will take years.

Resource loaders is a hugely useful addition, so we can create an officially-supported solution for updating resources and assets without shipping a new app update. I can see appcompat gaining a backport of this.

Conversations are interesting if somewhat narrow in effective scope.

What’s Old and New Again

In summary:

• Bubbles: back!
• Blossom and Buttercup: still missing

What’s Obscure But Cool

We can get a list of “historical process exit reasons”, including crashes, low-memory pressure, permission changes, etc. IMHO, there should be a unique identifier on these, but even without it, having this data can be very useful for understanding what’s going on with the app in production.

There are a new series of methods on MediaStore for creating PendingIntent objects that perform actions against the store itself, such as marking items as favorites or deleting items. These could be attached to notification actions, app widget buttons, and other places where we need a PendingIntent, and we don’t have to fuss with our own code for implementing them.

What Has Me Worried

The documentation around one-time permissions is too limited. In particular, the explanation of the lifetime of the permission grant is unclear. Some developers claim that you need to re-request the permission even after onPause() of some activity, whereas in light testing I’m finding that the permission grant lasts for the entire process lifetime.

There is a new QUERY_ALL_PACKAGES permission, which “allows query of any normal app on the device, regardless of manifest declarations” (emphasis added). I worry about what it means for an app to declare itself as not being visible via PackageManager.

What’s Dead

Google is continuing the trend of deprecating highly-visible classes that have better replacements nowadays. In Android 11, this includes:

• AsyncTask: use coroutines, RxJava, custom executors, etc.

• IntentService: use JobIntentService or a regular Service

• ListActivity and ExpandableListActivity: use a RecyclerView

• TabHost and TabWidget: there are a million tab solutions out there, pick one

Also, they deprecated TimingLogger and LauncherActivity. I rarely used TimingLogger and might never have known about LauncherActivity.

setView() on Toast is dead. If you are using this, it will stop working once your targetSdkVersion reaches R.

And, we can no longer get official translations of “yes” and “no”, inexplicably.

What Makes Me Go “Hmmmmm”

As usual, there is a bunch of stuff that shows up in the API differences report that is interesting, confusing, and sometimes both:

• ACTION_WIFI_ADD_NETWORKS seems like an interesting addition to the WiFi network suggestion APIs from Android 10, but I’d need to put it to use to have a better sense for what the flow will be like.

• Usually, we try to avoid ANRs (“application not responding” dialogs). In Android 11, we can ANR ourselves.

• ActivityManager has an undocumented isLowMemoryKillReportSupported() method.

• A tiny bit of protobuf wandered into the SDK, which seems odd. Why would this be a framework class?

• The inline presentation API seems intriguing but lacks any obvious things that use it.

• There is an APP_SEARCH_SERVICE system service name that supposedly is for an AppSearchManager, but the SDK does not have an entry for AppSearchManager. Perhaps this will show up in DP2.

• FileIntegrityManager has a sweet name, though its use cases seem fairly limited.

• Devices can have a feature (e.g., uses-feature) for being “a Context Hub”. It is unclear what a “Context Hub” is and why it needs a Title Case name.

• There are two new foreground service types: camera and microphone

• It is very strange that they added getStorageDirectory(), since most apps cannot access it. Perhaps it is there for MANAGE_EXTERNAL_STORAGE holders.

• We got java.util.concurrent.Flow. If you are using coroutines, make sure you don’t import the wrong Flow.

What Happens Now?

I am working on Elements of Android R and should have a 0.1 version out for subscribers within a few weeks. And, I will be continuing to blog any scary findings (scary bad or scary cool) as I stumble upon them.