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 Will Piss Off Users
The phrasing around the file and directory access restrictions
puts the blame on developers. How dare we ask for the 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, in reality, the restrictions listed in this section will be placed on users,
not developers. And I have absolutely no idea 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 happy.
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 Piss Off 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.
