Google Android

Update: a slightly updated version of this article has been published on the Javalobby weekly news letter and on the javalobby site itself after Matthew Schmidt invited me to do so.

Update 2: The serverside has linked here as well. Readers coming from there, the version on Javalobby linked above is the latest and also has some discussion attached.

About an hour ago, Google released some additional information on the SDK for Android, its new mobile platform. Since I work for Nokia (whom I of course not represent when writing things on my personal blog, usual disclaimers apply), 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 spent the past half hour glancing through the API documentation, just to see what is there. This 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.
  • There is no mention of any native applications or the ability to write and install native applications
  • Particularly, there’s no mention of a browser application. Given Googles involvement in Firefox and their recent announcement of a mobile Firefox, this is somewhat surprising. Browsers are increasingly important for high end phones. Without a good, modern browser, Android is doomed to competing with low end feature phones. Browser seems to be webkit, the same engine that powers the iphone browser and the S60 browser.
  • Google has chosen to not implement full Java or any of the ME variants. This in my view very bad and unnecessary.
  • 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 power management, SMS to user interface.
  • 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).

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. I’m sure that in each case there is some reason for it but 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. This openness comes however with a few Strings attached. Basically, it relies on Java’s security system. You know, the same that is used by operators and phone vendors to completely lock down J2ME to restrict access to interesting features (e.g. 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. 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 choice 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 apache 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 eSWT, a mobile version of the eclipse user interface framework SWT. 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’s 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.

8 Replies to “Google Android”

  1. I’ve also looked at the Android SDK, read the “Developing using C++” thread on the Android Developer Group and was quit disappointed to learn its merely a Java platform (though on top of a completely integrated stack). Now I’ve stumbled over your blog and have a couple of related questions: you say operators insist on locking a device down .. why? Does that apply in particular to native apps with full access? How does that fit with Symbian being quite “open” to native apps and with Maemo built into Nxxx devices with no cellular? Thx, Tobias

  2. Hi,

    In general most operators will insist on controlling software on their network for a number of reasons that include security and desire to control end user experience. Especially security is increasingly important as devices are getting hooked up to the internet and people start downloading all sorts of stuff with them. It only takes one buffer overflow in C++ for a hacker to take over the device even if the application itself was harmless. Most mobile platforms have no concept of root or a user so that makes any native application a risk.

    Anyone wanting to release a phone platform will have to deal with this in order for operators to deploy/allow phones with the platform on their networks. That’s true for everybody in the business currently. Most platforms don’t allow for native application installation at all (e.g. many of the current linux phone platforms are completely locked down). The ones that do tend to be tightly controlled by operators and vendors.

    J2ME was designed specifically to allow developers access to more sensitive parts of the functionality using a permissions system based on Java security APIs. However, J2ME was designed for really limited devices initially which means there is all sorts of technical limitations. Google seems to plan to make a fresh start but still, Google is using a similar security mechanism in their API now. Android applications need to ask permission to do stuff like making phone calls. This permission can be granted by the user but it might also be denied by the Operator … I fully expect similar mechanisms to be used by Apple when they release their SDK in a few months.

    Nokia and Symbian also provide protection for native applications. Using certificates, you can get access to parts of the API that are protected. Certification involves a process that ensures that Nokia verifies the application is not malicious and that the associated developer can be trusted. For example to programmatically send an SMS you would need the right certificate. This has proven to be an acceptable solution to operators and now that the S60 v3.x platform is stabilizing and getting on more and more phones, we’re seeing lots of interesting development happening on the platform inside and outside Nokia. Symbian was rather dismissive about Android last week. I don’t really agree with that position but clearly Google has some catching up to do with us. Nokia has large developer communities around Java, Symbian and Maemo.

    Especially the maemo development is really open. I’d say it is the only commercially backed open mobile linux platform currently with products in the shop today. Maemo as you note does not have a cellular stack currently; nor does it currently have a way to restrict access to APIs (which makes it the ideal mobile linux device for hackers since you can do anything you want on it). As announced a few weeks ago there will be wimax variant of N810 but still without call functionality (other than the various VOIP software packages). This is a similar use case as equipping a laptop with a wimax card so operators are pretty OK with this. I can’t comment on what the future will bring though.

  3. great article, saves me from having to look into it. It’s really unfortunate they chose the sandbox model, takes a lot of the revolutionary potential away from it. Looks like the only place for true open source mobile is OpenMoko

  4. Good job Jilles, a very balanced and fair assessment of the Google SDK as it stands today.

    I too was sadly disappointed to learn that Google was re-inventing the wheel and putting out yet another type of Java development environment. It will make my work harder now since I have to port my J2ME code to Android over the next few months.

    However, as a J2ME developer in the US, my experience has been that the best minds, companies and standards bodies (Sun, IBM, Motorola, Nokia, Samsung, RIM, Palm, AT&T, Verizon Wireless, Microsoft, Apple, OSGI and the JCP and of course Google itself ) to date (after many many years of effort) have yet to put out a mobile platform that provides for freedom of choice, open development and easy and open deployment, cross-platform compatibility with great security and privacy of course.

    I say let’s give someone else a chance now!

    There is a good chance that Google might be able to pull something off now if they could get carrier backing. Sun and the JCP were getting nowhere!

    Now, I only hope that Google exercises common sense and gradually rolls in all the great technical (but not managerial) work Sun and the JCP has been doing. So maybe we could end up with the best of both worlds.

    I look forward to reading some more of your excellent writing.

  5. I disagree with either Jilles and Java Man on their lament Google decided not to use J2ME as the API.

    1, I think main reason for this is won’t be possible under AL.
    2, J2ME is too limited/optional and implementations are too buggy so the whole platform is fragmented/screwed beyond repair. I think they made a good choice.
    3, it is possible to implement J2ME API on top of Android. Thus you get the best of both worlds : new, consistent platform that will simplify that ridiculous process of testing/tweaking/certifying the application on zillions of devices and you still can transform the “legacy” applications for Android quite easily as they are all Java.

    I only hope the actual devices will be same as the SDK emulator and it won’t be possible for operator to “lock” it in any way. I want to be able to install on MY device whatever I want with privilegies I decide, since it is MY device, not operator’s.

  6. I think there is much more behind this than licensing. Google is only adding to the fragmentation now and besides, J2ME is not that fragmented or screwed beyond repair. Googles’s own J2ME apps seem to work fine on most J2ME phones at least. The older, midp 1.0 API was very limited which caused vendors to add APIs of their own. This is a main reason for incompatibility. With midp 2 that is much less of a problem.

    Other problems arise from differences in formfactors and hardware capabilities. That is a hard problem to work around at the API level. J2ME does a reasonable job but it remains to be seen how Android handles this.

    Regardless of this, there is more than a billion J2ME phones out there with reasonable compatibility for MIDP 1.0 and MIDP 2.0 (for the subset that supports this) across platforms. Android doesn’t offer an alternative cross platform API. Instead it requires replacing the entire platform.

    Implementing J2ME on top of Android should indeed not be that difficult. Consequently, not making it part of Android is motivated by non technical reasons. I’m pretty sure license issues are not it.

    BTW. forget about operators and vendors not locking down the platform. The user granted privilege model is hopelessly broken since most users will just select “OK” or “YES” when confronted with a game that won’t run until you do so. This leaves the door wide open to all sorts of malware so operators will insist on proper locks so that they can control what goes on the phone. Android provides the regular Java security hooks so it should be easy to lock down access to e.g. phone or SMS APIs.

  7. If I unlock my nokia 6085 from AT&T and switch to a different operator, does the restricted API will be change or removed? I thought that different company has different set, for example, some operator will allow the JSR 135 getSnapshot without sign the jar.

    The real question is why should I pay money $500 to get my application be signed. I developed my application and want to test it on my Nokia 6085 phone (which I paied money already), why should I pay 3rd party big money???

    Nokia is the manufacture for my phone. AT&T, as the operator, provide to access to their wireless network. As long as the application doesn’t access your AT&T network, AT&T must provide a way for US to access our phone’s property! For example, to take a picture using my phone since getSnapshot is purely to access my phone’s camera, it is nothing to do with your network security. If I want test it on my phone, I know the security risk for my phone.

    I know for the same phone Nokia 6085, in different country, different operator are allow to access the JSR135 API. But Why AT&T disable it?

  8. Wrong forum for this drhu00. But let me bounce the question: why should Nokia risk its reputation or that of its partnering operators by letting you distribute your potentially very buggy and malicious software to our users? The stakes are pretty high here, Nokia sold a few hundred million phones last year. If anything goes wrong, we get the blame + cost for damage control and possibly legal cost. Your acquisition of a phone certainly doesn’t compensate Nokia for that risk. You knew (or could have known) what was in the package and allegedly it is a pretty popular phone for what it does out of the box and for what you can install on it in terms of third party software. In short, Nokia owes you nothing. Now since you got this bundled with a AT&T subscription, basically you probably got it for a pretty nice price. The downside of that is that AT&T gets to decide on how much they lock down the firmware. I can’t advice you how to get around that but unlocking and flashing with fully functional firmware provided by Nokia should in principle be possible (though it might violate terms of use with AT&T).

    I’m not a big fan of this method of restricting APIs either but it sure is very effective so far in preventing bad stuff from happening while at the same time succeeding in getting plenty of third party software signed and out there ready for you to install.

    I can’t speak for AT&T of course. The ability to disable or restrict access to certain features is important for operators, that’s just the way it is. In some places operators use this ability more than in others. The US is probably one of the worst places in that sense. Part of Nokia’s success (outside US mostly) is due to the ability to cater to operator requirements like this. The whole symbian signed deal is part of this game. I fully expect Google to do something similar; or Apple; or anyone for that matter.

    Your decision to pay up is of course up to you. It’s my understanding that barring use of restricted APIs, your cost is going to be limited to paying up to Verisign for a certificate (200$) + additional cost for testing, if you wish to distribute your binaries to others. For testing on your own device, the cost is free, check here: for more details on how to fix that. I’m actually quite sympathetic here and I think it is very regrettable & understandable if people like you decide not to support our devices for reasons of cost. But that’s just my opinion.

    BTW. For J2ME applications there is no Symbian signed at all unless you need access to specific restricted APIs. I don’t know about JSR 135 and why some operators limit it and other JSRs. I imagine AT&T is protecting or trying to protect their own business.

Leave a Reply