Presenting the Winners of the Android Developer Challenge I

Since we started the first Android Developer Challenge late last year, we all have been eager to see who the winners of $275,000 and $100,000 would be. All 50 applications that emerged from Round 1 of ADC I showed great promise, and these teams have been working intensely for the past several months to polish their apps for the final round.

Similar to round 1 we sent laptops preconfigured with the judging environment, emulator, and all entries to each of our seven judges. In this round, each judge reviewed all 50 applications, took collaborative notes and gave initial scores. Then, all judges met together over conference calls to discuss and debate these applications, finally coming to consensus on which applications should receive $275,000 and which should receive $100,000.

We're pleased to present all of the winners and finalists in our detailed ADC gallery. Peruse and enjoy — there are awesome applications and unique uses of the Android platform. We would like to congratulate the winners and thank all the entrants for their hard work!

Android Market: a user-driven content distribution system

When we talk to developers, a common topic is the challenge of getting applications in the hands of users. That's why today I'm happy to share early details of Android Market—an open content distribution system that will help end users find, purchase, download and install various types of content on their Android-powered devices. The concept is simple: leverage Google's expertise in infrastructure, search and relevance to connect users with content created by developers like you.

Developers will be able to make their content available on an open service hosted by Google that features a feedback and rating system similar to YouTube. We chose the term "market" rather than "store" because we feel that developers should have an open and unobstructed environment to make their content available. Similar to YouTube, content can debut in the marketplace after only three simple steps: register as a merchant, upload and describe your content and publish it. We also intend to provide developers with a useful dashboard and analytics to help drive their business and ultimately improve their offerings.

I also wanted to share some early details to help with planning your efforts so that you can be ready as our partners release the first Android-powered handsets. Developers can expect the first handsets to be enabled with a beta version of Android Market. Some decisions are still being made, but at a minimum you can expect support for free (unpaid) applications. Soon after launch an update will be provided that supports download of paid content and more features such as versioning, multiple device profile support, analytics, etc. Below are some screenshots that illustrate some of the security features and workflow.

With the addition of a marketplace, the Android ecosystem is becoming even more robust. I am incredibly energized by the support and amazing content I've seen so far. We will share more details as they are available and I look forward to working with many of you in the coming months.

Some information on APIs removed in the Android 0.9 SDK beta

Earlier this week, we released a beta of the Android SDK. In the accompanying post, I mentioned that we had to remove some APIs from the platform for Android 1.0, and as a result they don't appear in the 0.9 beta SDK, and won't appear in 1.0-compatible SDKs. Today, I want to take a few minutes to explain why.

GTalkService

We were all really excited when the "XMPPService" (as it was called, at first) was included in the first early-look SDK. Once we brought in our security review team to examine Android, however, they soon realized that, as exciting as it is, the GTalkService has some fundamental security problems. Rich Cannings is one of our security researchers, and here's his explanation of the issues:

When I first read about GTalkService, I was both excited and scared. As a developer, I was interested in a feature that provided a simple interface to send messages between two Google Talk friends. The messages would appear on the receiving device as a standard Intent that was easy to handle. How simple and beautiful is that? Unfortunately, when I put my tin foil hat on, I recognized that things are a little more complicated than that.

We decided to postpone GTalkService's data-messaging functionality for the following reasons:

1. "Repurposing" Google Talk Friends

   
   

   Google Talk friends are intended for a different purpose than that envisioned by the GTalkService. Your Google Talk friends can contact you at any time via IM. They can see your email address and often can see your real name. However, the idea of a Google Talk friend does not always line up with the types of people who may want to interact with via an Android application.

   
   

   For example, imagine a really cool mobile Massively Multiplayer Online Roleplaying Game using GTalkService. You would have to add all the players to your Google Talk friends list in order to play with them. Next time you log in to Google Talk from your desktop or on the web, you would notice that you have many new "friends". You may not want to chat with these friends -- and perhaps worse, you may not want them to know what your real name or email is.

   
   

   We do realize that Android users will want to interact with other Android users anonymously and for short periods of time, especially in gaming scenarios. Unfortunately, it turns out that using Instant Messaging is not really a good way to do that.




2. Verifying Remote Intent Senders

   
   

   Intents were designed to send messages within the device. The Intent subsystem can conclusively determine who sent Intents only when the Intents originate from the same device that services the Intent. When Intents come from other devices, the Intent subsystem cannot determine what application sent the Intent.

   
   

   This can lead to a variety of problems. At first, remote applications could send arbitrary Intents, meaning that your Google Talk friends had almost the same control of your device as you did. Even once that issue was resolved, we recognized that we could not trust the identity of the application who sent the request. We could only trust the identity of the user. So a "bad" application on your friend's device could send a message to a "good" application on your device which would negatively affect the good application.

   
   

   In the end, we determined that the Intent system, as designed for local use, did not lend itself well to being the vehicle for a Remote Procedure Call (RPC).

3. Placing Too Much Security Burden on Developers

   
   

   As originally designed, the GTalkService placed a significant burden on the application developer to avoid security flaws and perform user and relationship management. An Android application using GTalkService would be reachable from all of the user's Google Talk friends, and a flaw in that application could pose an inviting target to a malicious "friend" or automated malware. There are automated mechanisms that could be used to help protect vulnerable applications or stop the spread of malware, but the deployment of these technologies was not possible in time for the launch of the first Android handsets.

   
   

Although we would have loved to ship this service, in the end, the Android team decided to pull the API instead of exposing users to risk and breaking compatibility with a future, more secure version of the feature. We think it's obvious that this kind of functionality would be incredibly useful, and would open lots of new doors for developers. One of our top priorities after the first devices ship is to develop a device-to-device (and possibly device-to-server) RPC mechanism that is fast, reliable, and protective of developers and users alike.

As a final note, I want to point out that since the GTalkService was always a Google "value-added" service anyway, it was never guaranteed that it would be present on every Android device. That is, GTalkService was never part of core Android. As a result this change actually allows us the potential to build a new system that is part of the core of a future version of Android.

Bluetooth API

The 1.0 version of Android and the first devices will include support for Bluetooth; for instance, Android will support Bluetooth headsets. In the early-look SDKs, there was an incomplete draft of an API that exposed Bluetooth functionality to developers. Unfortunately we had to remove that API from the 1.0 release. To get the skinny on why, I contacted Nick Pelly, one of the Android engineers responsible for that functionality. Here's the story on Bluetooth, in Nick's words:

The reason is that we plain ran out of time. The Android Bluetooth API was pretty far along, but needs some clean-up before we can commit to it for the SDK. Keep in mind that putting it in the 1.0 SDK would have locked us into that API for years to come.

Here's an example of the problems in the API. Client code is required to pass around IBluetoothDeviceCallback objects in order to receive asynchronous callbacks, but IBluetoothDeviceCallback is meant to be an internal interface. That client code would break the moment we added new callbacks to IBluetoothDeviceCallback.aidl. This is not a recipe for future-proof apps.

To make things even more tricky, the recent introduction of the bluez 4.x series brings its own new API. The Android Bluetooth stack uses bluez for GAP and SDP so you'll see more than a passing resemblance to bluez's interfaces in Android. The bluez 4.x change requires us to carefully consider how to structure our API for the future. Again, remember that once we settle on an interface we need to support it for years going forward.

Rather than ship a broken API that we knew was going to change a lot, we chose not to include it. We absolutely intend to support a Bluetooth API in a future release, although we don't know exactly when that will be. This should include some tasty features, such as:

• Bindings to GAP and SDP functionality.


• Access to RFCOMM and SCO sockets.


• Potentially, L2CAP socket support from Java. (This one is under consideration.)


• An API to our headset and handsfree profiles.

On a personal note, Nick adds, "I would love nothing more than to start seeing some neat third-party applications and games over Bluetooth. In my opinion, Bluetooth is completely under-utilized on most mobile platforms and I'm excited to someday see what the developer community can do with Android."

I'm definitely bummed about these API removals. I was particularly looking forward to the P2P capabilities offered by GTalkService, but, as always, user security and privacy must come first. In all these cases, we'll work with the developer community to create some great APIs that balance these concerns.

Announcing a beta release of the Android SDK

I'm pretty happy today, for two reasons. First, I'm happy because I get to let everyone know that we're releasing a beta SDK. You can read about the new Android 0.9 SDK beta at the Android Developers' Site, or if you want to get straight to the bits, you can visit the download page. Once you've got it, be sure to visit our Developer Forum if you have any questions.

Back in November, we made some SDK builds available that we referred to as "early look" SDKs. The goal was to give developers insight into the platform as early on as possible, and to get some initial feedback. Since then, we've been working with our Open Handset Alliance partners to incorporate much of that feedback, and finish the first devices. Since those devices are shipping in the fourth quarter, the platform is now converging on a final "Android 1.0" version.

The beta SDK that we're releasing today is the first big step on the SDK's road to compatibility with 1.0. Since this is a beta release, applications developed with it may not quite be compatible with devices running the final Android 1.0. However, the APIs are now pretty stable and we don't expect any major changes. If you're one of the many developers who were waiting for something a bit more mature, this might be a good time to take another look.

Since we're now moving quickly toward 1.0, it may also help to know which direction we're headed. To help out, we've also prepared a development roadmap. This will be a living document, and we'll keep it up to date as the Android landscape evolves. Currently it covers the next few months, roughly through the end of the year and a bit into next year. We'll update it with additional detail as we are able to, but even right now it can help give you a picture of how things will play out as the first phones draw near.

Enough of that though -- you're probably wondering what's actually new in the SDK. Well, you should read the Release Notes, the Change Overview and the API Delta Report for all the details, but here are a few highlights:

• First and most obviously, the new Home screen is included, along with a ton of UI changes for 1.0.
• Some new applications are included: an Alarm Clock, Calculator, Camera, Music player, Picture viewer, and Messaging (for SMS/MMS conversations.)
• Several new development tools were added, such as a graphical preview for XML layouts for users of Eclipse, and a tool for constructing 9-patch images.
• Since we've got a new Home screen application now, we thought the now-obsolete version from the M5 early-look SDK might be helpful to developers, so its source is included as a sample.
• A number of new APIs are fleshed out and improved, and others are now close to their final forms for 1.0.
• Tons of bugs were fixed, of course. (If you had problems with the MediaPlayer, try it now!)

There are a lot of changes -- the ones in the list above are just my personal favorites, so you should check out the links above for the full story. Not all the changes are additions, though: I'm sorry to say that we had to remove a few things, such as the GTalkService (for security reasons), and the Bluetooth API. There's a bit more detail in the links above, and we'll follow up on those in particular here in this blog to give you the scoop. In fact, we've got a little list of topics we want to talk about here, so stay tuned.

At the top of this post I said I was happy for two reasons, and now you know one of them -- but what about the other? Well, the second reason is because now that this is out I can finally go get some sleep!