|
Google Android: Initial Impressions and Criticism
By Jilles van Gurp
Yesterday, Google released the SDK for Android, their new mobile software platform. Since I work for Nokia, I'm naturally interested in new software platforms for mobile phones. Additionally, since I'm a Java developer, I'm particularly interested in this one. I should at this point mention that these are just my personal views and impressions and that I am not representing Nokia.
I spent half an hour glancing through the API documentation and watched the youtube videos, just to see what is there. This of course does not provide me with enough information for a really detailed review, but it does allow me to extract some highlights that, in my view, will matter enormously for platform adoption:
- The SDK is Java based. No surprise since they announced it but it is nice to see that this doesn't mean they are doing J2ME but instead use Java as the core implementation platform for all applications on the platform.
- The Linux kernel and native libraries are just there to run applications on top of Google's custom JVM Dalvik which is optimized for running on embedded hardware.
- Google has chosen to not implement full Java, any of the ME variants, or support for the many JSRs (mobile and others). This in my view very bad, unnecessary and will be a barrier to developer adoption.
- Instead a small subset of the Java API is implemented. Probably the closest is the J2ME CDC profile. So why not go all the way and save us developers a few headaches?
- Additionally Google has bundled a few external libraries (httpclient, junit and a few others). That's nice since they are quite good libraries. I'm especially fond of httpclient, which I miss very much when doing J2ME CLDC development.
- The bulk of the library concerns android.* packages that control everything from Telephony APIs, power management, SMS to the user interface. Admittedly, some of these things require a custom approach since there is no existing Java APIs or code out there for them.
- I did not spot any OSGi implementation in the package; Google seems to intent to reinvent components and package management. This is disappointing since it is very popular across the Java spectrum, including J2ME where it is already shipping in some products (e.g. Nokia E90, which supports both OSGi and eRCP).
- It seems Google is relying on various XML descriptors to define UI and manifest files. This is a bit odd considering their Guice platform which is trying to undo similar madness for server development.
- There is no mention of any native applications or the ability to write and install native applications
- The browser seems to be Webkit, the same engine that powers the Apple iPhone browser and the S60 Browser. This is nice but it raises some question marks about mobile Firefox (Google is a major sponsor of Mozilla). Anyway, webkit is an excellent choice.
In my opinion this is all a bit disappointing. Not aligning with an existing profile of Java is a design choice that is regrettable. It makes Android incompatible with everything else out there, which is unnecessary in my view. Additionally, Android seems to duplicate a lot of existing functionality from full Java, J2ME and various open source projects. For example android sports an inter process communication mechanism that is not based on Corba, OSGI, DBUS, RMI, Soap, or any other mechanism that could have filled the gap. I'm sure that in each of these cases there is some valid reason for doing an android specific solution. However, the net result seems reinvention of a lot of wheels. Overall, I doubt that Android APIs are significantly faster, more flexible, usable, etc. than what is already out there.
On the other hand, the platform seems to be open, so not all is lost. Google is planning to release the SDK under Apache 2.0 license. The current SDK however is not under that license yet. This openness comes however with a few strings attached. Basically, it relies on Java's security system. You know, the same mechanism that is used by operators and phone vendors to completely lock down J2ME to restrict access to interesting features (e.g. sending SMS, accessing file system, making phone calls, installing applications). I'm not saying that Google will do this but they certainly enable operators and phone vendors to do this for them and are providing all the necessary hooks to make it really easy. This is not surprising since in the current market, operators insist on this, especially in the US. The likely result will be that Android application developers will have to deal with locked down phones just like J2ME developers have to deal with that today.
The choice for the Apache 2.0 license is a very wise since it is a very liberal license that will make it easy for telecom companies to integrate it with their existing products. Provided that the Android APIs are reasonably well designed, it may be possible to port some or all of it to other platforms. The Apache license ensures that doing so minimizes risk for underlying proprietary platforms.
Additionally, the license also allows for some interesting other things to happen. For example, there's the Apache Harmony project that is still working on a full implementation of Java. Reusing this work might of course also make much of android.* redundant. Additionally, there is a lot of interesting mobile Java code under eclipse's EPL, which is similar to the Apache license. This includes eRCP, an embedded version of the eclipse application framework. Eclipse also provides a popular OSGi implementation called equinox. Again, lack of OSGi is a missed opportunity and I don't care what they put in its place.
Frankly, I don't understand why Google intends to ignore the vast amount of existing implementation out there. It seems like a bad case of "not invented here" to me. Ultimately, this will slow adoption. There are already too many Java platforms for the mobile world and this is yet another one. The opportunity was to align with mainstream Java, as Sun is planning to do over the next few years. Instead Google has chosen to reinvent the wheel. We'll just have to see how good a job they did. Luckily, the Apache license will allow people to rip this thing apart and do something more productive with it. OpenMoko + some apache licensed Java code might be nice. Also our Nokia Maemo platform can probably benefit from some components. Especially the lower level stuff they've done with the VM and kernel might be interesting.
Until next time,
Jilles van Gurp
http://www.jillesvangurp.com
|
Perspective
