Random Musings on Q Beta 4
Each time Google releases a new developer preview beta, I putter around
the API differences report
the high-level overviews,
and even the release blog post,
to see if there are things that developers should pay more attention to.
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.
We are now up to Beta 4, so this extends upon my notes for
Beta 1,
Beta 2,
and Beta 3.
Q Beta 4 is supposed to have the final APIs. However, I
was surprised as to how much is different in Q Beta 4.
Hey, Can We Call It API Level 29 Now?
Yes, we can. We no longer have to dance around the API level. Build.VERSION_CODES.Q
has the proper value instead of the 10000 placeholder. And you are able to
publish apps with targetSdkVersion set to 29 if you so choose��� though you
may or may not be ready for that just yet.
So, What���s Up with Scoped Storage?
In a nutshell, it changed again, based on the description in the docs.
The sandboxes are gone. Instead, there is one unified external storage
location that all apps and the user sees. However, apps only see their
own files in external storage, in general. So, instead of scoped storage
being sandboxed, it is filtered instead.
From the user���s standpoint, this should be simpler. Now files that apps write
to external storage will be where they had been previously. This is really
important for legacy apps that are not being regularly updated and which might
never adapt to the Storage Access Framework. Yet, at the same time, apps should
still unable to manipulate other apps��� files through the filesystem, meaning that
users still get enhanced security.
Also, apps are still able to opt out of the filtered view, at least until next
year sometime, when targetSdkVersion 29 becomes required for the Play Store
and select other app distribution channels.
My biggest fear right now is that there have been so many changes over the past
three months that we are at risk of more bugs than we might otherwise have had.
Note that getExternalStorageDirectory() and getExternalStoragePublicDirectory()
on Environment
are now deprecated, to further steer developers towards using the Storage Access
Framework or MediaStore.
I will be ���kicking the tires��� on this stuff today and will write up more about
the current state of scoped storage tomorrow.
What Else Got Deprecated or Removed?
The biggest surprise ��� and a pleasant one ��� is that android:sharedUserId
is deprecated. Moreover, it is planned to be dropped entirely in some future
release. For device manufacturers, android:sharedUserId was a handy shortcut
for data sharing, but even there it really was not a particularly good practice.
For ordinary app developers, android:sharedUserId was a
footgun, one that I have been advising
against people using since the very beginning. Having an app suite is awesome,
but please use IPC for data sharing, not some sort of shared file that may or may
not be managed properly for simultaneous multi-process access.
DownloadManager deprecated some things, as a side effect of scoped storage:
addCompletedDownload()
allowScanningByMediaScanner() on DownloadManager.Request
setVisibleInDownloadsUi() on DownloadManager.Request
Items listed in the new MediaStore.Downloads collection will be what appears
in the Downloads UI now. So, if you have content that was not downloaded to the
Downloads/ directory by DownloadManager, and you want it to appear in the Downloads
UI, you need to write it to a Uri supplied by MediaStore.Downloads, I guess.
A bunch of fields from MediaStore.MediaColumns were removed, including ORIENTATION,
DURATION, and DATE_TAKEN. If your app has been querying on those columns, they
may no longer be available to you.
Also, MediaPlayer2 and related classes vanished without a trace.
They Didn���t Add Anything New, Did They?
Well, yes, they did, a lot more than I would expect at this late stage. Here are
a few things of note:
Activity now has onGetDirectActions() and onPerformDirectAction(). A
DirectAction is an opaque identifier of something that somebody can do with
or in the activity. The idea is that an activity can supply the available actions
in onGetDirectActions(), and a VoiceInteractor can let the user act upon
one. The chosen action then gets delivered to onPerformDirectAction(), for
the activity to go do something. Unfortunately, there isn���t a lot to go on
in terms of how all of this is supposed to work. Hopefully, more documentation
is forthcoming.
Intent now has getIdentifier() and setIdentifier(). The identifier
���is an arbitrary identity of the Intent to distinguish it from other Intents���.
My assumption is that this does not affect Intent routing and is basically a specific
���extra��� bit of data that gets passed along. It is unclear what the value of this
is over, well, extras.
Intent also adds CATEGORY_APP_FILES to identify file managers.
There are four new DisplayMetrics screen densities: 140, 180, 200, 220.
Those are the first new low-end densities we have had in years, and it is unclear
what hardware would have such screens. It���s possible this is tied to desktop mode,
if those are meant to be used for certain external displays. Regardless, most
developers will not need to worry about these, as Android will scale mdpi or
hdpi drawables for you. But, if you have other code that cares about these
DENSITY_ constants on DisplayMetrics, you have four more to deal with.
android:hasFragileUserData is a new manifest setting (I���m guessing on <application>).
���If true the user is prompted to keep the app���s data on uninstall���. This
seems ripe for abuse, but I can see where it might be useful for some apps.
What Was Renamed?
One common thing late in the beta sequence is to have classes and methods be renamed,
as somebody lost a fight in a code review or something. Of particular note:
isExternalStorageSandboxed() on Environment is now isExternalStorageLegacy()
ContentResolver.TypeInfo is now ContentResolver.MimeTypeInfo
They Must Be Done With Changes Now, Right?
Perhaps not.
There is still a reference to
RecoverableSecurityException being enabled in a future beta.
Certain types of I/O might throw that exception,
which contains a RemoteAction that you can use to bring up some UI to help
recover from that exception. In particular, if you do not have rights to modify
some media, you might get a RecoverableSecurityException, where the RemoteAction
would bring up UI to allow the user to grant you write access. It is unclear if
this might show up in a future Q beta, whether it already is in Beta 4 (without
the docs being changed), or what.
OK, So Where Do We Go From Here?
In theory, there should be few changes from here on out in terms of the API. There
may yet be bug fixes, which is good, as a bunch of the bugs that I filed are still
reproducible on Q Beta 4. But if you have been holding off testing your app with
Android Q, waiting for things to stabilize, you should not wait any longer. I
expect Android Q to ship in final form to end users in 2-4 months, and you will
want to make sure that your app will survive that upgrade.
As for me, I will update Elements of Android Q shortly to reflect some
of these changes and explore more dusty corners of this release, such as desktop
mode.
