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 http://developer.android.com/reference/android/os/StrictMode.html
- 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!