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.

US Closing Mobile Usage Gap

I posted a piece back in January this year about the Rise of the Mobile Wallet and was pleased to see that it was quoted in an Experian Consumer Research Report about the US Mobile Usage Gap.

The report suggests that while only 2% of US consumers regularly make purchases via a mobile device, already 16% use mobile banking services, roughly equally distributed among different age groups.

Interestingly, the research shows that the age profile of GPS users is heavily skewed towards 18-24 year olds, with a severe drop off in usage rates in the age groups 45-54 and over.

Mobile advertising acceptance is confirmed as being higher than for traditional web, with over a third of consumers who are online for at least one hour a week rating themselves as interested in receiving ads via their mobile provided there is a tangible incentive.

You can read the full 9-page report by clicking on the title of this post.

Social Network Valuations Reach Record Levels

I wrote back in March about AOL's acquisition of Bebo and the (inflated) purchase price they splurged for it (USD$850m). This, you may remember, equated to $38 paid per Bebo user.

Now an article in Mashable.com suggests that frenzied interest in social networks is taking these frothy valuations to new heights, and that Facebook's 100m users are worth at least $150 each based on the company's estimated value of USD$15bn.

Clearly, the exact calculation of Facebook's theoretical value remains a mystery, but by all accounts makes it the most valuable social network in the world and sets the marker in terms of premium valuations.

CEO Mark Zuckerberg, whose personal stake is worth an extravagant USD$3bn., must be rubbing his hands with glee. And execs at Microsoft must be praying that their investment in 2% of the company pays off strategically.

Meanwhile, market analysts anticipate that Facebook has the capability to continue expanding its user base to over 200m members, which would ramp up its value even further...someone please prepare the smelling salts...

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.

Killer Apps in Mobile Social Networking-Part 2

I posted earlier this week on potential candidates for the next Killer Application in Mobile Social Networking, identifying the following 4 potential candidates (so far):




-Mobile Dating Apps
-Mobile Social Network Aggregrators
-Virtual World or Second Life type applications with chat
-Phone Address Book

Here are my thoughts on the latter two candidates:

Second Life type applications with chat

There is no doubt that people are spending more and more time in virtual worlds. A company called Vollee has already released a public beta that allows you to make a connection to the Second Life Grid while handling the technical heavy lifting of rendering objects. The company then streams video output to your phone like any other media file.

By combining SL or other virtual worlds with chat on a mobile phone, a new dimension opens up for social interaction on mobile-anonymous and faceless maybe, but also with fewer boundaries than in the ‘real’ world. These characteristics may make it the next killer application in mobile social networking (at least in Japan, where anonymity in social networks is valued highly).

The Phone Address Book

The humble phone address book has been, is and will be one of the cornerstones of the social dimension of the mobile phone. Before anyone learnt to SMS, they learnt to add contacts to the phone address book. And when anyone loses their mobile phone, the thing they grieve about the most is the loss of their phone contacts.

The phone address book is the mobile social network par excellence –albeit a bit limited in its current state. But, let’s think about this…ALL one’s valuable contacts are already in the address book (no need to ‘add’ any friends), often with full contact details (including e-mail) and a photo…all we need is for a phone manufacturer to transform the phone book from its current state and integrate things like ‘preferences’, photo tagging and maybe some location-related info (“where are my contacts?”) and hey presto, you have a powerful social network ready to use!

Ok, some issues around privacy remain (will everyone be willing to make their phone address book public?) but the trend amongst mobile handset manufacturers is definitely towards beefing up their mobile software applications, and what better way to do this by transforming the now old-fashioned address book?

uLocate announces deal with Garmin for Buddy Beacon

BOSTON-In line with a trend that has been developing this year, uLocate (well-known for its WHERE platform) is the latest LBS company to announce a deal with a device manufacturer. Today, the company has released a note stating that they will integrate their Buddy Beacon application into Garmin's connected devices and their Mobile XT Platform.

The full press release is as follows:

" August 19, 2008—uLocate Communications, the world’s leading developer of location enabled applications, announces an agreement with Garmin to add friend-finding capabilities to select current and future Garmin GPS devices. The partnership leverages APIs on uLocate’s WHERE™ platform to enable Garmin users to easily find and connect with friends nearby through the leading friend finding network, Buddy Beacon.

“The team over at uLocate continues to drive innovation with their open WHERE platform, enabling the broadest set of location based applications across the largest distribution network in wireless,” said Jeff Rath, vice president, global head of technology research of Canaccord Adams. “This represents a powerful combination – the largest PND manufacturer and the dominant platform in the market bringing together the universe of location enabled connected devices.”

With access to WHERE’s Buddy Beacon network, Garmin customers will be able to connect with their friends, share their location and update their status across a variety of online social networking sites including Facebook. Unlike other friend-finding applications, WHERE’s Buddy Beacon operates seamlessly across multiple networks, making it possible to connect with friends regardless of phone or carrier.

“We are delighted to team up with Garmin and through our WHERE platform, provide their users with access to Buddy Beacon,” said Walt Doyle, CEO of uLocate Communications. “The partnership connects two leaders in their industries that are committed to offering customers new and exciting interfaces."

Expect other companies in the LBS scene to come out with further announcements in the coming months, as new distribution and monetization models come to the fore.

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!

Killer Apps in Mobile Social Networking

I will be contributing to a speaker panel on the Next Killer Application in Mobile Social Networking at the Mobile Web Europe conference in London in September and am gathering some thoughts on the subject.

So far, I have identified 4 potential candidates for what this next Killer App could be:


1. Mobile Dating applications
2. Mobile Social Network Aggregators
3. Virtual World or Second Life type applications that incorporate Instant Messaging
4. the Phone Address Book

I will be discussing the first 2 candidates in this post, while the remainder will be the object of a subsequent post:

1. Mobile dating applications are currently limited in their use of technology and frankly, have not made their case powerfully enough compared to web-based dating sites. Meetmoi, a $1.5m-backed mobile dating service launched last year still relies on SMS texting and requires the user to update his location manually-hardly revolutionary in the light of advances in location technology.

However, rumour has it that Microsoft is developing a mobile dating service that relies on Image-based face search in order to match prospective dates…a step in the right direction in terms of killer applications.

2.Mobile Social Network Aggregators (such as Spokeo) have attracted increasing levels of interest this year, in part due to the proliferation of mobile social networks and the tiresome task of keeping up with 4-5 different profiles and passwords. Different strategies are being deployed, with some aggregators going for Identity consolidation, others for message consolidation and others still for friend tracking.

Only a few days ago, news emerged that SonyEricsson was planning to release soon its own version of a social network aggregator, 3GLifestore.The game is hotting up…though would I pay €29/year to join Spokeo? Maybe not…

...to be continued

Online Social Network Rules

One of my readers from Youth Radio highlighted this Current.com video about young people's attitudes towards web-based social networks and privacy.

It gives a quick snapshot of current opinion but offers further proof that web users are wisening up to the risks of over-exposure via the web and adopting their own set of rules for using their favourite social networks sites.

Mobile Internet Blog reaches 3000 Readers (or thereabouts)

BARCELONA-I launched this blog in January this year to be able to share my passion about all things mobile with the large (and growing) mobile community out there.

Now, with the blog's global readership about to reach 3000, it is a good time to say thank you to all of you out there for reading, commenting on, bookmarking and sharing my blog -your support makes it all worthwhile!

In the first 7 months of this year, I have been privileged to participate in a number of mobile events, from the Mobile World Congress to the Mobile 2.0 Europe event, and have enjoyed sharing the latest news and buzz from these events with you (it has been great to share with readers from all corners of the world, from New Zealand, to Trinidad, Hawaii, UAE and India).

If you like the blog, please remember to subscribe to the RSS Feed so as not to miss out and also join the blog community on MyBlogLog. Above all, keep those comments flowing!

Beijing.mobi-coming soon?

With the 2008 Olympic Games in Beijing scheduled to kick-off on Friday 8th August, speculation is mounting as to whether or not the often gossiped about flagship dot.mobi site for the city, beijing.mobi, will finally be unveiled.

The mTLD or dot.mobi consortium has, since its inception, focussed heavily on developing city mobile sites, with barcelona.mobi following the initial helsinki.mobi development.

One of the touted strategies of the consortium is to synchronise city.mobi launches with prominent events, and the 2008 Olympics could not offer a better platform for this, given the substantial amount of publicity (both postive and negative) that the games have attracted this year. Much of this media frenzy will peak this month, offering a great opportunity for mTLD to achieve a truly global launch for the site.

It would also help to stave off critics and sceptics alike, who have pointed out how the m.dot domain still remains predominant in North America.It would also give the whole dot.mobi movement a shot in the arm at a time when its main shareholders (the mobile operators and equipment manufacturers) are increasingly coming head-to-head with each other in their attempt to retain (or attain) control over the mobile subscriber.

I love Mobile Web Awards

I will be on a speaker panel at Informa's Mobile Web Europe event on the 22-24 September in London to discuss the next killer ap in mobile social networking (what do YOU think it is?) -the mix of topics on the conference programme is probably the most comprehensive available for this area, and so there are bound to be interesting learning points and clues to the future shape of things to come.

One of the side events is the I love Mobile Web Awards sponsored by the dotmobi consortium, aimed at recognising the best designed and developed mobile internet site.

Enter one of six exciting categories for free before 22 August 2008, and you can have your work featured online at ilovemobileweb.com for the industry to view.The judging panel includes Michael o'Farrell, Chairman of the dotmobi advisory group.This is a unique opportunity to have your innovative ideas showcased to a highly qualified audience, so if you are in the .mobi site space, don't miss out!