Developer Preview Rules of the Road

Google I|O 2014 so far has been marked by a distinct emphasis on “coming soon” rather than “right now”. Of course, the biggest element of that is today’s planned release of the Android L Developer Preview.

Dave Burke apparently said in the Android Fireside Chat that the developer preview model is likely to be a fixture going forward (hat tip to Dave Smith for tweeting that, as I was having some livestream issues). However, we have not had a developer preview since the Android 1.x days, and many of you reading this blog post were not doing Android development way back then.

One of the keys with a developer preview is expectation management, between Google and developers, and to a lesser extent between developers and power users. Here is my take on the rules of the road for the L developer preview.

YMMV

L is going to be big, big enough that IMHO it is fairly safe to assume that this will be branded “Android 5.0”. But L is also a moving target, as some of the presentations indicated that work is continuing on L, at least at the framework level. What we will get today probably closely resembles – but is not identical to – the bits that are given to the OEMs to begin integration on new handsets. But it will not be the final version of an Android 5.0, and there’s a decent chance that there will be a “fast follow” 5.0.1 that fixes some things, possibly in ways that affect us as developers.

Hence, this developer preview will contain a lot of things that will wind up in L, but not everything in L will be in the developer preview. Please do not panic when L does ship to see things that you did not see in the preview.

Caution: Switchbacks Ahead

Conversely, it is possible that there will be things in the developer preview that might be intended for L but get stripped out late.

Perhaps there are too many bugs, and they lack the calendar time to get them fixed for a 5.0 release. This could result in a patch-level release that bumps the API level, as we saw most recently with Android 2.3 (API Level 9) and Android 2.3.3 (API Level 10).

Perhaps it is more generally “not ready for prime time” and is moved back to the drawing board for consideration in some future Android update. The Bluetooth APIs in the pre-1.0 beta releases of Android suffered this fate, not returning to the SDK until Android 2.0, while they were retooled during the intervening year-plus.

It is fine, even intended, that you use the developer preview to start making plans, and even code, to support L when L becomes available. However, just be careful to manage your L time investment properly, in case some developer preview piece that you are “hanging your hat on” winds up being pulled from the final release.

Bridge Ices Before Road

Just because your app works awesome on the developer preview of L does not mean that it will work awesome on L itself. Again, there will be differences, many beneath the level of the SDK, and some of those differences could have an impact on your app.

The developer preview is a way to spread out the work to get your app L-ready. However, it is not a replacement for testing on L itself, to make sure your app really does what it is supposed to do on what users will be using (L), as opposed to what you were initially given for testing (L developer preview).

Stay On Your Side of the Road

It is conceivable that we will get access to some of the source code that forms the developer preview.

It is also conceivable that you feel that you are not limited by source code availability, and that you will use reverse-engineering tools to figure out what is going on “under the hood”.

That is fine. However, be careful how you use that knowledge because, again, the preview release is not the final release. In particular, while using this stuff to experiment with a backport (where none is available) is fine, I’d be a bit hesitant about releasing a backport based solely on the preview bits.

Caution: Construction Ahead

While what we are getting today is a “developer preview”, not only developers will be previewing it. If, as described, there are hardware images available to load onto some recent Nexus devices, there will be non-developer power users who will elect to start running L, and some of them will be trying to use your app.

On the plus side, if your app starts crashing, and you are collecting crash logs, this will give you valuable intel on where things need work in your app to get it to work on the L developer preview, and perhaps on L itself.

On the other hand, you may also wind up with a lot of support questions related to L, more so than you would normally have for a non-existent release.

Power users often poke around with various features that are supposed to be developer-only, whether that is ART previews, READ_EXTERNAL_STORAGE previews, etc. Unfortunately, not all of those power users understand that “preview” does not mean “instantly works”. You may get some complaints as a result, and it will be up to you to decide how much to cater to users of a preview release of Android.

Scenic Lookout Ahead on Right

Don’t let these rules scare you. Developer previews are awesome, in that we actually have time to try to adapt to new Android releases, rather than having releases land like cartoon anvils on our roadmaps whenever Google decides to ship them. We may not have budgeted time to consider Theme.Material, or new notification styles, or employing JobScheduler to replace select uses of AlarmManager. At least now we have the opportunity to consider them.

Android 5.0 will not ship until October or November, in all likelihood, giving us months of lead time, lead time that we are not used to having. Use the time wisely, and your app can shine on Lollipop, Lemonhead, Lindt, or Limburger, whenever the new Android release ships and under whatever name it ships.