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.

Following the US elections on your phone

Elections in the US are coming, and the race is heating up. With Joe Biden just announced as the Democratic VP nominee, speculation is increasing about the Republican choice. To help you stay up to date on the latest election updates, we've set up a new one stop shop for your mobile electoral needs. Just go to m.google.com/elections on your mobile phone, and you can find these resources:
  • Mobile Search - Link to search results for Obama and McCain, so you don't have to type in their names on your phone each time you want information.
  • Mobile News - Read the latest! A handy link returns only elections-relevant news.
  • Mobile Reader - Are you subscribed to the Google Power Readers in Politics? If you're already following the reading lists of the presidential candidates or prominent political journalists on Google Reader, you can keep it up while you're on the go. Not yet subscribed? Manage your account and subscriptions on your desktop computer.
  • Mobile YouTube - Both presidential candidates have their own YouTube channels. Watch their latest clips of speeches and press conferences from your phone.
  • Mobile Maps - Are you going to the Democratic National Convention in Denver, or the Republican National Convention in Minneapolis? Make sure you've got Google Maps for mobile on your phone to help you get around town. (And if you're going, stop by and say hello! We'll be at both conventions.)

New Gears Geolocation API powers mobile web sites

Imagine if web sites could provide you with customized information based on your current location, even if you don't have GPS. Today we're launching the Gears Geolocation API for mobile and desktop browsers, while two third-party developers are launching the first location-enabled web apps using this API on Windows Mobile.

One of the most popular travel sites in the Europe, lastminute.com, has now location-enabled their new mobile restaurant finder to help you find restaurants near you without requiring you to type in where you are. If you're in the UK, just go to fonefood at m.lastminute.com, click the "Find your location" link on the home page, select the type of restaurant you want, and lastminute.com will automatically work out which neighbourhood and city you are in and find matching restaurants. This is great for both UK residents and the millions of tourists who visit each year.



Rummble is a new social discovery tool where you can recommend places to visit and see personalised recommendations from friends. Just go to m.rummble.com and click on the "Update location with Gears" link on the home page to see the "Rummbles" near you.

These two apps make use of the Gears Geolocation API. The API can determine your location using nearby cell-towers or GPS for your mobile device or your computer's IP address for your laptop. Google provides this service for free to both developers and users.

Gears is available on IE Mobile on mobile and Internet Explorer and Firefox on desktop. To use the location-enabled lastminute.com and Rummble web apps you will need a Windows Mobile device that supports GPS or cell-id lookup (for example the Samsung Blackjack II and HTC Touch Dual, see supported devices FAQ). We are working hard to bring Gears to more mobile platforms, such as Android and others.

Google takes your privacy very seriously. Although Gears and the Geolocation API do not record your location, you should only allow web sites that you trust to access your location. Gears will always tell you when a site wants to access your location for the first time and you can either allow or deny that site permission. Always check the privacy policy of the web site if you are in doubt as to how they may use your location information.

If you are in the UK and have a supported Windows Mobile device visit m.lastminute.com and m.rummble.com today. The first time you use the location feature you will be prompted to download and install Gears.

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!

This is a test -- ads on YouTube's mobile site

Over the past year, we’ve focused on creating and delivering a full-featured YouTube mobile user experience. We think we've made great strides in doing this, allowing you to access YouTube wherever you are, whenever you want it. YouTube for mobile continues to grow exponentially, and today, people watch hundreds of millions of YouTube videos every month on mobile devices.

You may have noticed that we started running a test of display ads on select pages of the YouTube mobile site in the U.S. and Japan. This is our first step in testing mobile advertising for YouTube -- it will give you a new way to interact with content on the go, while allowing us to learn how video viewers engage with mobile advertising. Our test advertisers will also have an additional branding tool at their disposal and the opportunity to reach the millions of people who visit YouTube every day on their phones.

At YouTube, we are constantly testing new ways to deliver the kinds of ads that contribute to the user experience while making the most sense for advertisers, and we've learned a lot about what works for YouTube and what doesn't. We're excited to explore new approaches to mobile advertising, and will evaluate this test closely over the next several weeks to make sure we provide our community, our partners and advertisers with the most valuable and effective mobile experience possible.

orkut for S60, now with photo uploads and picture galleries

When we launched the mobile (xhtml) version of orkut back in April on m.orkut.com, we were overwhelmed by its adoption.

However, Google always tries to build our products for a diverse group of users. Many people access orkut from their smartphones, many of which can support more advanced functionality. So today we are launching a new mobile orkut experience that is optimized for Symbian Series 60 (3rd edition) phones. The new orkut works on many popular phones, including Nokia's Nseries (N95, N82, etc.) and Samsung's SGH models. And we have added a bunch of new features including photo uploads, picture galleries, click-to-call, and quick friend searches. But the best part of it all - everything is available without the need to download any special client. Just open your phone browser, type http://m.orkut.com, and if you have a Symbian Series 60 3rd edition phone, you are good to go!

So go ahead and upload all those wonderful pictures you took at the beach or at the city's latest dancing spot, and then start calling your orkut friends to plan the next gathering.

And, don't forget to write to us and share your ideas for how we can make the orkut experience on your mobile phone even better.

Posted by Ankit Gupta, Software Engineer



Google Translate now for iPhone

A few months ago I was planning a vacation to Austria and Italy. I knew a few words and phrases in German and Italian, but that was about it. So I looked around for some portable language dictionaries. I thought Google Translate was great, but the web page didn't work that well on the iPhone. So I teamed up with David Singleton, a fellow engineer in our London office, to build an iPhone interface for Google Translate.

Google Translate for iPhone is optimized for speed, supports all of the existing Google Translate language pairs, and uses a client-side data-store on your iPhone to hang on to your past translations so you always have them at hand, even if you can't use the local data network. We wrote this using the AJAX Language API, so every time the Google Translate team updates the languages they support, the languages will automatically be added here.

I tried an early version of this interface out on my trip and it was great -- although my pronunciation wasn't. So every now and then, I would just hold up my phone to let people read what I couldn't. If you're wondering about data costs, I found that I could get between 200 and 400 translations in 1MB of data download. Although we don't charge for this service, your carrier may charge for the data usage so be sure to know what your roaming rates are. For my plan, I found that I could translate 400 phrases for less than $10 when roaming internationally.

To try Google Translate for iPhone, point your iPhone or iPod Touch web browser to www.google.com and choose the "more" tab. Or you can go directly to translate.google.com in your browser. If you are traveling this summer (perhaps on your way to Beijing?) we hope you find this useful.

On your mark, get set, go! Follow the Summer Games on your phone.

It's that time again... time for the Summer Games to begin! It may still be August 7th here in Mountain View, but it's already August 8th in Beijing, and the Opening Ceremonies are getting ready to kick off another global celebration of athleticism. We marvel at the elegance of the swimmers, the power of the pole vaulters, and the artistry of the gymnasts. And of course, we cheer on our favorite athletes.

If you're like me you'll want quick updates for the Games all day long. (I'll be following Michael Phelps's gold medal quest, and I can't wait to see how the US swimming team does.) We've launched a new mobile search tool that gets you sport results, country medal count, and event schedules right at the top of your search results. Go to www.google.com on your phone and try a search for "swimming." You'll get something like this:

Once the events have begun, you'll be able to search for things like "gymnastics medals" or "Russia medal count" to get updated medal counts and rankings in your search results as well. Fast updates are now at your fingertips, and you don't even need to click through to an extra webpage.

Want to browse through all of the events? Go to
www.google.com/m/summergames on your mobile phone. You can discover sports you may not have even known were part of the Games, such as the new Cycling BMX event. Since the Summer Games are a worldwide event, we made this new search tool available in 36 languages and over 60 countries. Alors, par exemple, if you were in France you could browse on the French domain, or get the same search tool when you search for "natation."

We're also excited to announce our first-ever worldwide mobile doodle in celebration of the Summer Games. Go to the Google homepage on your phone to see it.

And for all that we're excited here on Mobile, this is far from the only tool you'll have for the Summer Games. Check out what else Google has to offer on our post on the Official Google Blog. And now... let the games begin!