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:

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.

 

Meta


Creative Commons License