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.

Comments Locked

17 Comments

View All Comments

  • TurnerK - Sunday, May 19, 2013 - link

    The graphics session was definitely the most interesting and tale-telling not to mention that Romain Guy and Chet Hasse cracking jokes were hilarious. On a serious note, I'm definitely interested in running the profile GPU rendering tool on the apps I use regularly to examine their performance like I do with the show overdraw tool.
  • mayankleoboy1 - Sunday, May 19, 2013 - link

    Will hardware acceleration of non-recangle parts imprve battery life ?
  • Friendly0Fire - Sunday, May 19, 2013 - link

    Technically, hardware accelerated *anything* means you're using the most efficient device to compute what it is you're doing, which means it should be faster, which means it should go back to a lower power state faster/more often. So yes, it could.

    Obviously, the amount of non-rectangular paths used in Android is so low that I doubt the improvements would be more than a few minutes of battery life at best. The reordered and merged rendering pipeline will probably do a lot more for it.
  • hackbod - Monday, May 20, 2013 - link

    I think it is a pretty safe assumption that any battery life improvement would be negligible. Also, equating drawing on GPU with lower power consumption is overly simplistic. For example if my UI draws at 30fps all in software, and then I implement a hardware path and now have it drawing at 60fps, power use may in fact be increased -- the CPU still needs to run some, and it could well not be able to lower in frequency enough to offset the increased power use of the GPU.
  • tipoo - Monday, May 20, 2013 - link

    Yeah, I don't think hardware accelerated necessitates lower power draw. I'm fairly certain hardware accelerated browsers *lowered* my laptop battery life, same with more hardware accelerated operating systems. I get the theory, but in practice the power saved by the CPU getting to stay in lower power states longer maybe be completely offset by the GPU being powered on where it normally would be at minimum clocks.
  • chrone - Sunday, May 19, 2013 - link

    this is what i've been waiting for. get rid of all the micro stuttering on transition animation, and choppy scrolling. yay! :D
  • tipoo - Tuesday, May 21, 2013 - link

    Hasn't every Android revision promised that? :P
  • chrone - Wednesday, May 22, 2013 - link

    yeah, you are right, each time it's broken on next update or so. lol
  • mooninite - Monday, May 20, 2013 - link

    The bluetooth stack change was *not* for the "addition to enabling the Android team to rapidly add more features and profiles" but rather at the behest of Broadcom. The Bluez library is utilized by every major Linux distribution and desktop environments to provide features that the Broadcom stack *does not* provide. The switch is a *downgrade*.

    Android is still more closed than it should be. In a real, open-source world, Android changes would be communicated ... get ready ... openly.
  • Cinnabuns - Monday, May 20, 2013 - link

    I can only hope the focus for more bluetooth improvements come along with bluetooth bug fixes as well. My wife and I both have a Nexus 4 and it's quite obvious that the bluetooth functionality was a downgrade over previous Android versions. It's a major disappointment on a phone that is otherwise quite good.

    Aside from the initial audio streaming issues that were fixed in 4.2.2, there are still a number of bluetooth issues plaguing Android 4.2.2:
    - lack of MAP profile support. It was supported until 4.2. (https://code.google.com/p/android/issues/detail?id...
    - bluetooth randomly won't turn on (https://code.google.com/p/android/issues/detail?id... https://code.google.com/p/android/issues/detail?id...
    - wifi drops connection when bluetooth is in use (https://code.google.com/p/android/issues/detail?id...

    I've personally run into all of these problems. When people ask me if I'd recommend the Nexus 4 to them, I tell them that it's fine as long as they don't ever have to use bluetooth.

Log in

Don't have an account? Sign up now