Google I/O 2013 recently wrapped up, and I've been spending some time ingesting all the information from sessions during the event, including ones I couldn't directly attend. While Google didn't announce a new version of Android at the event, something nearly everyone speculated would happen, it did directly allude to new upcoming features that will be implemented in this still unnamed upcoming version.
Google allegedly assigns version numbers late in the process, but what is known is that this next release will implement upcoming API level 18. If you follow the progression there's a likelihood this will be Jelly Bean MR2 (Management Release 2), where Android 4.2 was management release 1. Based on some other discussions and sources I also suspect this might be Jelly Bean MR2. All of that is really just semantics however, what really matters are what specific features are coming and which of those Google touched on during I/O.
Bluetooth 4.0 LE Support
In a session on day one, Google announced upcoming support for Bluetooth 4.0 Low Energy. Bluetooth low energy has been branded as Bluetooth Smart for low energy only devices, and Smart Ready for devices which support low energy in addition to classic (such as a mobile phone). Bluetooth LE implements a completely different physical layer compared to Bluetooth classic, with lower duty cycles that enable deployment in lower energy devices like proximity tags, sensors, pedometers, and watches which rely on small batteries that go longer than a day between charges. There's a misnomer that implementing Bluetooth LE will magically result in lower power consumption, it simply enables a completely different architecture optimized for different use cases. The Nexus 4 recently went through the Bluetooth SIG with Bluetooth 4.0 certification, the WCN3660 Qualcomm WLAN+BT combo chip inside has in fact always had compatibility for Bluetooth 4.0, it was just a matter of adding the APIs to Android to make it useful.
With Android 4.2, Google changed both NFC and Bluetooth stacks. In the case of Bluetooth, from BlueZ to BlueDroid with an open source disclosure by Broadcom. It's now becoming clear this was done partially with the forward-looking benefit of enabling support for Bluetooth LE and addition to enabling the Android team to rapidly add more features and profiles.
API level 18 Bluetooth LE features will be added to the Android Compatibility Test Suite as well, which means OEMs who have already implemented Bluetooth LE features via their own APIs will have to support their third party APIs and the canonical Google ones in this future version of Android. The API will support the central profile role only, which means both transmit, receive, and the ability to initiate connections plus serve as the master. Peripheral role is not supported.
API level 18 also adds support for AVRCP 1.3 (Audio / Video Remote Control Profile) which essentially enables compatibility with things like a car head unit, AV receiver, or so forth. This enables the device to control commands like play or pause, as well as metadata such as album artwork, artist, name, and status of the music. This enables much better compatibility with car audio and so on. Interestingly on the last slide from this session the date for API level 18 is given as coming in "a few short months."
Graphics
Perhaps the most revealing session was the one I was most interested in on Android Graphics Performance. It was here that we essentially were given a few glimpses of the new platform features which improve the performance of the hardware accelerated 2D rendering pipeline running on a device as well.
First up is intelligent reordering and merging of draw commands for given UI elements. Like elements are reordered and then issued together to take advantage of the GPU in an optimal manner without incurring a change in the shader state to render bitmaps, text, or nine-patches for example. This also minimizes the number of draw calls issued to the GPU for the same equivalent UI.
Google showed an example before and after with the same Google+ UI going from 88 draw calls to 39 after this feature was enabled.
Second is multithreading of additional parts of the hardware accelerated 2D rendering pipeline for some tasks. Rendering operations will now happen automatically on multiple cores if present.
Third, hardware acceleration for non-rectangular clipping was added, previously this was not hardware accelerated. This includes clipping around paths and transformed rects.
There are new developer tools present in this new version as well. In Android 4.2 Google added an on-device overdraw visualization, similar on-device functionality is coming to the rendering profile tool previously added in 4.1 which required a longer tedious workflow.
Toggling the profile GPU rendering option now gives the option to draw frame time (display list, rendering, then buffer swap) with a bar graph or line graph at the bottom of the screen in a persistent fashion instead of off-device in a spreadsheet. There's a handy green line which corresponds to 16ms (60 FPS).
This is a major boon for developers wanting to debug frame render time or occasional hitching. We saw this demonstrated on a device running the new tool and profiling parts of the Android UI, this was the first glimpse of the new Android version running on a device in public I'm aware of.
Systrace also gets a handful of improvements in this unnamed upcoming version of Android with an easier to run command line script invoking it, and the ability to trace each OpenGL call. Systrace is a very powerful tool for looking at what an Android device's underlying hardware is doing during a trace.
Conclusions
Even though we weren't explicitly told there's a new version of Android coming, nor its nickname or version number, there were repeated direct allusions and references to it throughout this year's I/O. Although many lamented it not being directly announced, it was there if you looked for it, including a few direct glimpses.
It's clear that the new version will implement API level 18 and bring further improvements to 2D rendering performance throughout Android as well as support for Bluetooth Smart (LE). These are both things closer to hardware and system which require changing the platform software entirely as opposed to pushing an update out to Google Play Services.