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
In reality, developers don’t do that. Developers simply fire off
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
¯\_(ツ)_/¯” 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
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.
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
gaining a backport of this.
Conversations are interesting if somewhat narrow in effective scope.
What’s Old and New Again
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
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
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
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
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.
JobIntentServiceor a regular
ExpandableListActivity: use a
TabWidget: there are a million tab solutions out there, pick one
Also, they deprecated
LauncherActivity. I rarely used
TimingLogger and might never have known about
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_NETWORKSseems 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.
ActivityManagerhas an undocumented
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_SERVICEsystem 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.
FileIntegrityManagerhas 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
java.util.concurrent.Flow. If you are using coroutines, make sure you don’t import the wrong
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.
Learn second-generation Android app development — with Kotlin and the Android Jetpack — through CommonsWare’s Android app development training!