Initial Thoughts on Android 2.3 from a Game Developer’s Perspective

Super awesome. This is the first Android release that is really game developer friendly. Whether you work in Java or in C/C++, development is a breeze. I especially like the additions to the new NDK release which are heavily focused on game development. My highlights so far:

  • Fix for high CPU usage on input events: It seems that they rewrote the complete input event dispatching system, judging from the new class hierarchy of InputEvent, MotionEvent and so on. The CPU usage when touching the screen should be greatly reduced, as is the lag in between the original dispatch and you processing it in your app. The only bummer: this is not going to get backported and devices that suffer the most of this issue (Hero, G1, anything not a N1 or Samsung Galaxy S) won’t benefit from this. Good times, bad times :/. I wished they’d already done that in 1.6.
  • GLES20 VBO fuckup: They fixed the GLES20 Java JNI wrapper and added support for VBOs :p
  • Concurrent Garbage Collector: this is most awesome. Instead of stopping the world the GC will now just use up some CPU resources while your app runs alongside it. It will probably result in a little drop of FPS as CPU resources are divided, but it’s a major step up from the old GC
  • NativeActivity: now this is just plain awesome. They have fully integrated support for native applications now and allow them to directly interact with the UI APIs. This means you can implement the activity lifecycle and input event handling in native code! Check out the documentation of the NativeActivity class to see how simple this really is.
  • STLPort and other APIs: along with NativeActivity come major improvements in the native APIs available. We now have STLPort integration, OpenSL (by Khronos) as well as direct access to assets within the APK from the native side. This is huge, as OpenSL finally gives us low latency audio (on most devices i hope at least). The only beef i have with this is that i don’t see exposure of OpenSL via a Java API. Maybe i can hack something up 🙂 See the changelog for more info or download the latest r5 release for even more info and examples. Edit: well, turns out OpenSL won’t provide any benefit over standard Java APIs really. From the NDK docs: ” use of OpenSL ES does not result in lower audio latency, higher scheduling priority, etc. than what the platform generally provides.” So i guess we are still stuck with 100ms buffer sizes. Sad bunny face 🙁 Edit 2: this is getting better and better. Turns out EGL wasn’t supported in previous NDK releases, at least not for surface creation. That’s in r5 as well now 🙂
  • Standalone cross-compiler support: besides going to gcc 4.4.3 they now also support using this as a standalone cross-compiler. That means that you can more easily compile things like Box2D and the like with the standard configure/make procedure. Note however that you still have to check that configure configures your stuff correctly for Android which might need some more love.
  • Java side Audio API: this received some love as well it seems. You can now attach effects to an AudioTrack. How performant that is has yet to be seen. It’s a nice addition in any case.
  • New Mediaframwork: It seems like OpenCore has been completely replaced with a new media framework. Still no direct decoding facilities to analyse audio though. Or i have to dig deeper.
  • Support for more peripherals: gyroscope, front facing cameras etc. Given that those will take some time to show up in actual devices i think we can savely ignore them for now:)
  • StrictMode: that sounds like a nice new promising way to profile your app with respect to net and disk I/O. It basically tells you when you do disk/net IO on the UI thread which is a pretty nasty no-go. Keep your UI thread responsive! More info at
  • i probably missed more awesome things

To summarize: THIS IS FUCKING GREAT! They really got things right this time. I don’t know about the user facing side as i’m not all that interested in that. My 2.2.1 Froyo works great already. But the developer facing side has now become just plain awesome. The only thing that bugs me a little is that we can’t use any of those new featuers on Android versions < 2.3 so we'll have to wait for a year until enough devices run 2.3. Judging by the current will of manufacturers and carriers to update phones i wouldn't count on any current gen phone to be updated to 2.3. Not Google's fault in this case though. So what does this mean for libgdx? Well, first of all the adoption of 2.3 will take quite some time. Secondly, i still think that you can write high-performance games on Android in Java alone with just a little help from native code. While you could have a complete native code game working on both the desktop and Android (and other platforms) the managment of this is much more involved then going straight Java. So, libgdx will stay Java for the time being 🙂 I might write a small gamedev lib on top of the 2.3 features in the future though. Haven't done much C++ in the past few years and it sounds like a fun project get get into that again a little. Great job Google folks, keep it up!

23 thoughts on “Initial Thoughts on Android 2.3 from a Game Developer’s Perspective

  1. Great article 😉

    But as you said, “we can’t use any of those new featuers on Android versions < 2.3" … it's a pain in the ass and we'll have to wait a few months or even more to be using all of those great features 🙂

  2. Any device that runs well with Froyo should run even better with Gingerbread. The base hardware requirements have not changed. Of course OEM updates do depend on individual OEM efforts, and I can’t speak for the OEMs, but there’s no technical reason devices able to run Froyo shouldn’t be upgradeable.

    I think the Froyo->Gingerbread migration should be less painful for device developers than Cupcake->Donut or Eclair->Froyo.

  3. This is great news! Thanks for clearing that up. Let’s hope manufacturer and carrier adoption will be faster than it was with 2.2.

  4. i think you have summed up the most points nicely. One thing which should be pointed out too is the new adt. It brings some very nice improvements like

    * integrated proguard support on
    * less recompiling of the whole workspace
    * not required to change the debug flag all the time
    * integration of the HierarchyViewer (and i really do hope that the next integration step will be the traceviewer. great tool.)
    * improved visual editor (although i don’t see me using that more often i think)

  5. That went completely under my radar as i don’t mess with the UI Apis often. Integrated proguard support and faster compile times are awesome though! Thanks for adding that here.

  6. After a rather frustrating day at work, it was a pleasant surprise to power up my laptop and find the Android 2.3 SDK ready for download. Your take on it is similar to mine and far more eloquently stated. I’m particularly pleased to see NativeActivity. Maybe it’s time for me to start coding for Android in my old native language, C.

  7. Oh and one more thing…

    In the LogCat view of the ADT you can now doubleclick on an exceptionen entry and it will bring you right into the line in the editor. Most requested feature i ever had. 😉

    Now if they could only add to create filter for the LogCat from the running process (eg right click menu).

  8. yeah, proguard is good choice because it’s like obfuscation from source code, but becare that your string chars are still there i think (will test it)

  9. “…i guess we are still stuck with 100ms buffer sizes. Sad bunny face.”

    This is disgusting. Audio latency in Android has been a reported problem for over 2 years now. Google devs have given zero feedback on the issue and simple workarounds have been suggested by competent programmers. Unfortunately, unless Google give their blessing for one of these solutions it’s pretty much a waste of time for any 3rd parties to do this work.

    Why is it that my old 600MHz P3 laptop running Fedora with RT kernel patches can run multiple audio channels and LADSPA effects with sub 60ms latency but my 1GHz HTC Desire HD can’t run a fart button app without 100ms of latency?

    Google: Fix Audio!

  10. Impressive, nice summary there too Mario. One thing I will say though to developers is please don’t shoot yourself in the foot by running to change your development lang from Java to C, just because you can! I’ve got a few years of experience with C++ game development and I have to say the move to Java has made my life so much better. Go native only when there’s a solid case for it (I can’t imagine any other case besides ‘isolated performance bottleneck’).

    Just my opinion 🙂

  11. well, i think there are benefits. Porting to IOs is pssible if you go native (with quite some extra work though). You could even have desktop ports as you have with libgdx.

    In general i agree though. Java makes many things more pleasant.

  12. I think we will be surprised how fast OEMs prepare devices to get updated to 2.3. I think behind-the-scenes Google/OHA is stressing faster device-OS updates decreases customer churn as far as mobile operators are concerned.

  13. Pingback: Anonymous

Leave a Reply

Your email address will not be published.