While there’s a ton of headline features of Android O and behavior changes to take into account, digging through the API Diff reveals a number of hidden gems that I’m personally really excited to see.

Keep in mind that Android O is in “preview” state right now, so these APIs may certainly change between now and when the final APIs are published.

Improvements to the Storage Access Framework

One could easily say that I’m a fan of the Storage Access Framework, having written a deep dive into Building a DocumentsProvider and built a DocumentsProvider into Muzei.

So I was certainly happy to see that the improvements have continued, with a number of new capabilities being added to DocumentsContract (the class you use to interact with document URIs):

• createWebLinkIntent() allows you ask the owner of the document URI to build a web link to a document that you can share with others, rather than do the download/upload dance — perfect for cloud storage providers. FLAG_WEB_LINKABLE tells you if this is available for the document URI you have.
• findDocumentPath() gives you a DocumentContract.Path from a tree URI, giving you the full hierarchy of document URIs. With the help of the display name, you can now show users the exact set of breadcrumbs up the hierarchy.
• You can add an activity that handles ACTION_DOCUMENT_SETTINGS to give users quick access to the settings of a particular file (this would be particularly useful when it comes to controlling sharing access)
• When selecting a location to save a file using ACTION_CREATE_DOCUMENT or when opening a document, the new EXTRA_INITIAL_URI allows you to override the default initial location (the last location the user selected) with your own custom starting location.

I think the web links functionality will go really well with virtual files and I’m excited to see cloud providers take advantage of them.

On a related note to virtual files, apps using ACTION_SEND can now use CATEGORY_TYPED_OPENABLE to indicate that they are okay with receiving non-openable files if and only if they have an alternate file type available (i.e., there’s at least some way of getting an InputStream to the sent file).

Recovering from SecurityExceptions

For those of you targeting API 23+ and using runtime permissions, you might have seen a SecurityException or two during development. Now there’s a new RecoverableSecurityException, which extends SecurityException and adds some incredibly useful methods including ways to get:

• A human readable error message
• An easy way to show that message as a dialog
• Show the error message as a notification
• Use a RemoteAction that allows you to embed the recovery path directly into your UI with an icon, title, and the PendingIntent you can start to recover from the RecoverableSecurityException.

One use case that immediately comes to mind is when it comes to a DocumentsProvider or ContentProvider — this would make it a lot easier to build a password protected DocumentsProvider.

SharedPreferences is dead. Long live SharedPreferences

SharedPreferences is fantastic for the simple storage of a few key/value pairs. In Android O, individual preferences or even the entire PreferenceManagercan call setPreferenceDataStore(), allowing your app to keep the same simple key/value pair API, but provide your own mechanism for storing the underlying data.

If someone could write a multi-process capable PreferenceDataStore, that’d be great. kthx

An actually good SMS verification flow

I get why some apps using SMS verification, but there’s got to be something better than requesting the READ_SMS permission to all of my SMSs or doing the multiple app dance to copy/paste a code over.

Thankfully, that looks like exactly what SmsManager’s createAppSpecificSmsToken() looks to solve. It gives you a token you can send through whatever SMS gateway your app uses and if the user receives an SMS with that token in it, you’ll get a callback to your PendingIntent. No reading SMSs directly, leaving the app, or permission dialog.

Making it easier to work with the Keyguard

The Keyguard is the lock on your device. Certainly, if your device is securely locked, it should just be unlocking on its own, but there are certainly apps that need to go from above the keyguard (say, Google Maps when you are navigating) to totally unlocked — say, to show some personal information. That’s where dismissKeyguard() comes in — helping an activity that is showing above the keyguard with FLAG_SHOW_WHEN_LOCKED or right below the keyguard to dismiss the keyguard and get on with what you’re actually trying to do like pull up that person’s address. (Did I mention how much better it is to use something like Android Auto is when driving?)

Seamless rotations for fullscreen activities

API with the most potential has to be the new rotationAnimation attribute, which you can now apply to (fullscreen) activities in your manifest. Before, you had to set that via the same-named WindowManager.LayoutParamsattribute, but by declaring it in the manifest you avoid race conditions with transition animations.

With such values as rotate (the default you are certainly familiar with), crossfade, jumpcut, and finally seamless:

Seamless: This works like JUMPCUT but will fall back to CROSSFADE if rotation can’t be applied without pausing the screen. For example, this is ideal for Camera apps which don’t want the viewfinder contents to ever rotate or fade (and rather to be seamless) but also don’t want ROTATION_ANIMATION_JUMPCUTduring app transition scenarios where seamless rotation can’t be applied.

If you’re a camera app, you should definitely install the Android O Dev Preview on a device and try this out.

Never too early to explore what’s new in Android O

By far the best part of getting involved in Android O testing right now (you know, besides making sure your app works at all) is that you can have a say in the development of Android. There are undoubtedly more of you with unique situations and important use cases that we would love to hear from.

I’d encourage you to search through the open issues, star the issues that affect you, or file new issues to get them fixed before Android O rolls out to users.