Random Musings on the O Developer Preview 1
Each time Google releases a new developer preview, I rummage through
the API differences report
and the high-level overviews,
to see if there are things that warrant more attention from
developers, with an emphasis on mainstream features that any developer
might reasonably use. I also tend to emphasize things that may not
get quite as much attention, because they are buried in the JavaDocs.
As with the N Developer Preview, there is quite a bit to the O Developer Preview
that lies ���under the surface���, below what you will find as talking points in
media coverage. On the other hand, whereas N had multi-window, O seems to be
lacking a user-facing ���big-ticket��� feature. My guess is that we will
get something more in O at Google I|O and as part of the O Developer Preview 2.
First, though: many thanks to whoever decided to publish the O Developer Preview
JavaDocs live, rather than through a ZIP file download. Linking to the documentation
is hugely useful.
What Scares Me
Clearly, the biggest trouble area will be with the next phase in ���the war on
background processing���. I expect many apps to keep their targetSdkVersion low
as a result, since many of the changes only affect those apps that embrace
the new API level. I also expect many more apps to just make all their
services be foreground services. Blocking the receipt of implicit Intent
broadcasts will just add to the ���Android is unreliable��� complaints, as users
used to apps responding in real time to environment changes (e.g., toggling airplane mode)
will now find their apps lagging by seconds, minutes, or perhaps longer, waiting
for some background job to decide to run.
I am nervous about the multi-display support. This appears to allow users to
���throw��� an activity onto an external display. In principle, this sounds neat.
However, I do not know if any O preview-capable hardware can support external
displays ��� HDMI seems out, and I don���t know if any even support Miracast.
We need to be able to test this behavior, to see what it means for one of our
activities to be shown on a non-touchscreen display. Plus, apps that are using
Presentation or related techniques for handling multiple displays already
need to know how O���s multi-display changes affect their existing app behavior.
There are now disk space quotas, presently imposed solely on cache directories.
That does not scare me much, though developers using cache directories should
ensure that they are testing that thoroughly (e.g., what happens if only
part of the cache is cleared, or if the cache is cleared while your process
is running?). I am more concerned over the possibility of Android P or Q
imposing disk space quotas more broadly. As a user, this is fine; as a developer,
this is the sort of thing that should have been added years ago, and who knows
what impact such quotas will have on our apps?
And, while personally the move to support only API Level 14+ with the
Android Support Libraries
does not bother me, I worry about the splits that this and the similar Play
Services SDK limitation will cause in the developer community. In many
countries, Android 2.x are niche devices. In many countries, Android 2.x remains
relevant.
What Intrigues Me
You can now set a Notification to automatically time out at a certain time
This seems very useful, though it will be interesting to see if they handle
all the edge cases. For example, suppose you create a foreground service,
but set the Notification to time out after a minute. Do you remain at
foreground priority?
I hope that a bunch of apps using floating windows to show random stuff will
switch to the new picture-in-picture support.
I wonder to what extent we can create a quasi-backport of
the new font resources.
We cannot invent a new resource type for older devices, but we might be able
to alias fonts to point to raw resources, which could be used on older devices.
We finally get support for seekable streams backed by things other than files,
courtesy of ProxyFileDescriptorCallback
and openProxyFileDescriptor().
My guess is that this cannot be backported��� but it would be seriously useful
if it could.
The document APIs have a few interesting additions:
Providers can now offer to create ���Web links��� for documents, presumably with an
eye towards cloud storage providers
You can convert a MediaStore Uri into an equivalent document Uri
Providers can advertise that they support a ���settings��� activity for some or all
of their document Uri values, where clients can arrange to launch that activity
for the user to do��� something (rename the document?)
WebView will now honor the network security configuration allow-cleartext
setting. With luck, Google will continue migrating WebView to support
more of network security configuration.
As the Android Police pointed out,
there is now an app-level grant of rights to be able to install and uninstall
other apps. That���s a welcome acknowledgment from Google that there actually
are ways to distribute apps that does not involve the Play Store.
IPC with providers got a boost. The paged queries feature
got the attention, but there is also now a refresh() method to tell a provider
to update the data associated with a Uri.
Just as Android 4.0 gave us ActivityLifecycleCallbacks,
Android O gives us FragmentLifecycleCallbacks.
This will be good for creating fragment management utility code without forcing
everyone to have to extend specific Activity subclasses.
SmsManager can create ���SMS tokens���.
If this does what I think it does, it resolves an issue that arose in Android 4.4:
implementing SMS-based authentication became a problem, because apps could not
handle those messages automatically and avoid those messages going into the user���s inbox.
SMS-based authentication has plenty of problems,
as SMS is about as secure as a piece of tissue paper, but there are still
plenty of people trying to use this.
SharedPreferences storage is now backed by
a pluggable interface.
This raises the possibility of having better secured preference storage options
while still allowing normal SharedPreferences usage (notably the preference UI
classes).
And, as Cyril Mottier pointed out,
findViewById() now returns a typesafe value, for those still dealing with
casts there (e.g., no data binding, no Butterknife).
What Else You Might Care About
Here are some other bits that might interest you:
Proper tooltip support
Proper text justification support
Padding/margins on two sides at once
ANDROID_ID is now per-app, not per-user or per-device
However, in every Android release, there are casualties. Of note,
ZoomButton zooms no more.
About the Book
Monday, I shipped Version 8.4 of my book.
Tuesday, Google shipped the O Developer Preview, possibly in response to
some car maintenance.
As a result, it will be a few weeks before I can publish a Version 8.5 and
dive into Android O in earnest. Look for an update in April.
