Pages

Friday 15 March 2013

Android Developer Challenge 2 open for submissions

Android Developer ChallengeThe time has come! The submission site for Android Developer Challenge 2 is now open. You can now submit applications for the Challenge at http://market.android.com/adc. Full instructions are also available on the site.

The key thing to remember is that all submissions must be entered by 11:59:59pm Pacific Time in the United States on August 31, 2009. If your applications are not submitted by that time, they won't be eligible for participation. Please carefully note what time that is in your local time zone.

It's very important that your apps only use published APIs. Some users might be judging your submissions on new phones you haven't seen or tested. If your apps depend on unpublished APIs, they might not work on some of these phones. Please note that you won't be able to submit new versions of your apps after the deadline!

Since you'll be competing against developers around the world for users' attention, it is important to focus on the fit and finish of your app. Your apps will be judged by users as a final product and not just a cool demo.

As a final note, if you've uploaded a version of your app to Android Market, you'll need to use a different Android package name for the version you submit to the Challenge.

I look forward to see all the great apps and innovations from you all.

Android Developer Challenge: Round I Results are In

The last few weeks were both extremely intense and rewarding. Based on feedback from the judges, it was apparent that large number of applications were compelling, innovative and well implemented. The quality of these entries clearly reflects the creativity and hard work that developers have invested in building their apps.

In addition to developers' participation and contributions, over 100 industry judges around the world spent weeks reviewing these submissions. I want to thank all the developers and judges who have worked incredibly hard over the last few months, making the Android Developer Challenge such a success.

Many of the top submissions took advantage of the geo and social networking capabilities of Android. These applications allow friends to share their personal experiences and favorite content such as vacations, photos, shows, music, cooking recipes, restaurants, and much more as they relate to certain locales. I've also seen applications that connect people during emergency situations and others that allow users to share information on how they can reduce their carbon footprint. One developer even turned a real city block into a playing field where gamers can role-play and chase after villains.

Furthermore, some of these applications provide rich interactive experiences by combining web services and mash-ups to bring together data that's on the web with data that's on the mobile device. One application combined weather, pollen and allergy information in the context of a map that is relevant to a user's location.

Though many applications use a traditional "download" model for data, many also enable users to publish content, such as photos or even voice memos, for others to use on other mobile devices or the web.

This is just a brief snapshot of the many impressive applications I've seen. The 50 highest scoring applications will receive $25,000 each and go on to compete in the final round. We plan to publish a list of these applications as soon as we receive the developers' consent. The real winners, however, are the consumers who will benefit from the work of these talented developers.

Android Developer Challenge Deadline Approaching Quickly

The Android Developer Challenge is proceeding nicely. We're excited about the interest people have shown so far and have enjoyed talking to everyone working on new Android Apps.

As a quick reminder, the first phase of the challenge will be ending on April 14. In the Android Developer Challenge I, the 50 most promising entries received by April 14 will each receive a $25,000 award to fund further development. Those selected will then be eligible for even greater recognition via ten $275,000 awards and ten $100,000 awards.

Keep working on your applications, and be sure to post in the forums if you have any questions!

Android at Google I/O and Developer Days

It was great to connect with everyone at the Google I/O event in San Francisco and at our recent Developer Days across the globe. We enjoyed meeting all of the Android developers and answering your questions - both at our booth and at the fireside chats.

For those of you who were unable to attend, all of the sessions are available on video:

http://sites.google.com/site/io/

Enjoy!

Android Cloud To Device Messaging

[This post is by Wei Huang, who helped implement this feature. — Tim Bray]

In the just-launched Android 2.2, we’ve added a new service to help developers send data from servers to their applications on Android phones. Android Cloud to Device Messaging (C2DM) makes it easier for mobile applications to sync data with servers.

Most of the useful applications on your mobile phone use the Internet to keep users connected. Traditionally, many apps use polling to fetch data periodically. POP mail clients, for example, connect to the server every 15 minutes or so. Polling is fairly easy to implement, and works well in many situations. It’s tricky, though, to select the frequency: Poll too often, you may not see any new data, and create unnecessary stress on the server and network. Poll too rarely and the data on the device may become stale. Polling is especially problematic on mobile devices, because it consumes precious network bandwidth and battery life.

Having the server push messages to the client asynchronously may be a superior choice for getting the latest data to your applications, resulting in fresher data and more efficient use of the network and your battery. However, it’s also tricky to implement a good push solution, and it isn’t free as there is some overhead in maintaining the required connection. On a mobile device like an Android phone, implementing applications to receive these messages is tricky; you have to worry about patchy network coverage and zombie connections created when the wireless carrier’s routers time out connections that are idle for too long.

Many of the Google applications on Android already use push to keep their data fresh, for example Gmail, Contacts, and Calendar. Starting with Android 2.2, C2DM allows third-party developers to use the same service the Google apps do.

Here are a few basic things to know about C2DM:

  • It requires Android 2.2; C2DM uses Google services which are present on any device running the Android Market.

  • It uses existing connections for Google services. This requires the users to sign into their Google account on Android.

  • It allows 3rd party servers to send lightweight data messages to their apps. The C2DM service is not designed for pushing a lot of user content; rather it should be used like a “tickle”, to tell the app that there is new data on the server, so the app can fetch it.

  • An application doesn’t need to be running to receive data messages. The system will wake up the app via an Intent broadcast when the the data message arrives, so long as the app is set up with the proper Intent Receiver and permissions.

  • No user interface is required for receiving the data messages. The app can post a notification (or display other UI) if it desires.

It’s easy to use the C2DM API. Here is how it works:

  • To enable C2DM, an application on the device registers with Google and get a registration ID, and sends the ID to its server.

  • When the server needs to push a message to the app on the device, it posts the message via HTTP to Google’s C2DM servers.

  • The C2DM servers route the message to the device, and an Intent broadcast is sent to the app.

  • The app is woken up to process the message in its Intent Receiver.

  • The app can unregister with C2DM when the user no longer wants messages to be pushed to it.

That’s about it! All you need is a server that knows to talk HTTP, and an Android app that knows how to use the Intent APIs. Below are some code samples:

// Use the Intent API to get a registration ID// Registration ID is compartmentalized per app/deviceIntent regIntent = new Intent( "com.google.android.c2dm.intent.REGISTER");// Identify your appregIntent.putExtra("app", PendingIntent.getBroadcast(this /* your activity */,  0, new Intent(), 0);// Identify role account server will use to sendregIntent.putExtra("sender", emailOfSender);// Start the registration processstartService(regIntent);

The registration ID will be delivered back to your app via an intent broadcast with the Intent Action com.google.android.c2dm.intent.REGISTRATION. Here is a code sample to receive the registration ID.

// Registration ID received via an Intentpublic void onReceive(Context context, Intent intent) { String action = intent.getAction(); if (“com.google.android.c2dm.intent.REGISTRATION”.equals(action)) { handleRegistration(context, intent); }}public void handleRegistration(Context context, Intent intent) { String id = intent.getExtra(“registration_id”); if ((intent.getExtra(“error”) != null) { // Registration failed. Try again later, with backoff. } else if (id != null) { // Send the registration ID to the app’s server. // Be sure to do this in a separate thread. }}

On the server side, your server needs to get a ClientLogin Auth token in order to talk to the C2DM servers. When it wants to push a message to the device, it can send an authenticated http POST with:

  • Authorization: GoogleLogin auth=

  • URL encoded parameters including the registration id, the data key/value pairs, a “collapse key” used for overriding old messages with the same key on the Google C2DM servers, and a few other optional params.

When you use the C2DM service, you no longer need to worry about dealing with flaky mobile data connections, or when the user isn’t connected to the internet (i.e. Airplane mode). C2DM keeps the messages in the server store, and delivers them when the device comes back online. Basically, you can leave all the hard work of designing a robust push service to Google. Your application can take advantage of push infrastructure we’ve already built and tested, and stay more connected to the internet. Best of all, you won’t ruin the users’ battery life.

Information about how to build C2DM enabled applications on Android is online at the code lab, and more will be coming as we approach general release.

Android Design V2: Now with stencils

[This post is by Android designer Alex Faaborg, on behalf of the entire User Experience team. —Tim Bray]

When we initially released Android Design, by far the number one request we received was for us to release stencils as well. The fine folks on the Android User Experience team are pleased today to release some official Android Design stencils for your mockup-creating pleasure.

With these stencils you can now drag and drop your way to beautifully designed Ice Cream Sandwich (Android 4.0) applications, with grace and ease. The stencils feature the rich typography, colors, interactive controls, and icons found throughout Ice Cream Sandwich, along with some phone and tablet outlines to frame your meticulously crafted creations.

Currently we have stencils available for those venerable interactive design powerhouses Adobe® Fireworks®, and Omni® OmniGraffle® and we may expand to other applications® in the future. The source files for the various icons and controls are also available, created in Adobe® Photoshop®, and Adobe® Illustrator®. Here are the downloads.

We’ll be updating these stencils over time so, as always, please send in your feedback!

Happy mockup making,
— Your friendly Android Design Droids

Android Developer Challenge, Sub-Saharan Africa!

[This post is by Bridgette Sexton, an innovation advocate for the African tech community. — Tim Bray]

En Français.

In the past year alone, we have met with over 10,000 developers and techies across Sub Saharan Africa. We are continually impressed by the ingenuity and enthusiasm of this community in solving real problems with technology. From applications that crowd-source traffic info to mobile registration of local businesses, handheld devices have taken center stage for consumers and developers in Africa. With a number of countries in the region hovering around 80-90% mobile penetration, mobile is the screen size for the web and the communication experience.

Correspondingly, at every Google event in Africa, Android is the hottest topic; we know why. Every day over 300,000 Android devices are activated globally! A growing number of these mobile devices are powering on for the first time in emerging markets like those in Africa. As Android users multiply, so does the appeal to for developers of building apps on this free open-source platform.

An increasing number of users are searching for 'Android' on Google in Sub-Saharan Africa

For all these reasons and more, we are proud to be launching the Android Developer Challenge for Sub-Saharan Africa!

The Android Developer Challenge is designed to encourage the creation of cool and innovative Android mobile apps built by developers in Sub-Saharan Africa. Invent apps that delight users and you stand a chance to win an Android phone and $25,000 USD. To get started, choose from one of three defined eligible categories (see below), build an Android app in a team or by yourself, and submit it via the competition website by July 1st. The winning app will be announced on September 12th at G-Kenya. Get more details as well as Terms and Conditions on our site.

Categories for Entry:

  • Entertainment / Media / Games

  • Social Networking / Communication

  • Productivity / Tools / Lifestyle

(See Terms & Conditions for more details!)

To launch this competition, we have teamed up with Google Technology User Groups (GTUGs) across Africa to host Android Developer Challenge events. Check out our website for Android gatherings near you, and get coding!

Android at the 2010 Game Developers Conference

2009 has been a great year for Android Market. With the support of developers like you, Android Market now has more than 20,000 applications. Of these applications, games have proven to be particularly popular with Android users. Seven of the ten most popular paid applications on Android Market are games, so there's a significant opportunity for game developers as the number of Android devices continues to grow at a rapid pace.

To better support this trend, we are increasing our support of Android game development. As a first step, we will be presenting a number of Android sessions at the Game Developers Conference on March 9th and 10th in San Francisco. The sessions will be technical and will include everything you need to know about Android game development in Java or C++. Engineers from the Android team will also be available to answer your questions. Whether you are new to the platform or already have games in development, we would love to meet you face-to-face, answer your questions, and see what you're working on. Be sure to keep checking the GDC site because we'll be adding more sessions.

But that's not all. Google and GDC will also be providing complimentary Android phones to attendees who register for All Access or Tutorials and Summits passes by the Early Bird deadline of February 4, 2010. Qualified attendees will receive either a Nexus One or a Verizon Droid by Motorola, so they can quickly apply what they learn from the various Android sessions. You can find more details about the Android phone offer on the GDC site.

Our goal is to make it as easy as possible to develop awesome games for Android, and this is a first step. Hope to see you at GDC!

Android Developer Challenge Judges

We have received a few inquiries regarding the judges who will be evaluating entries to the Android Developer Challenge (ADC). All Entries will be judged by a panel of experts in the fields of mobile devices, cellular telecommunications, software development, and/or technology innovation ("Judges"). Google will select the Judges from the member organizations of the Open Handset Alliance, Google and/or mobile experts.

As a reminder, the deadline for the Android Developer Challenge is April 14, 2008. We're really looking forward to seeing what you've created so make sure you submit in time. Good luck!

Android C2DM — Client Login key expiration

[This post is by Francesco Nerieri, engineering team lead for C2DM — Tim Bray]

In the upcoming weeks, some of the older Client Login authentication keys will expire. If you generated the token you’re currently using to authenticate with the C2DM servers before October 2011, it will stop working.

If the response from the C2DM servers contains an Update-Client-Auth header, you’ll need to replace the current token with the one included in the header.

 // Check for updated token header String updatedAuthToken = conn.getHeaderField(UPDATE_CLIENT_AUTH); if (updatedAuthToken != null && !authToken.equals(updatedAuthToken)) { log.info("Got updated auth token from datamessaging servers: " + updatedAuthToken); serverConfig.updateToken(updatedAuthToken); }

We suggest that you start using the Update-Client-Auth response header to update tokens regularly, as keys will expire periodically from now on. For example, have a look at the Chrome to Phone service hosted on code.google.com; this code takes care of authenticating via Client Login and then sending a message:

Alternatively, you can manually generate a new Client Login token now and replace the one currently in use. ClientLogin can be used with any application that can make an HTTPS POST request. The POST request should be structured as a form post with the default encoding application/x-www-form-urlencoded, like this:

POST /accounts/ClientLogin HTTP/1.0Content-type: application/x-www-form-urlencodedaccountType=GOOGLE&Email=johndoe@gmail.com&Passwd=north23AZ&service=ac2dm

If the POST succeeds, the response contains the authorization token, labeled "Auth", which is your new token. You could even do this from the command line:

curl -d \ "accountType=HOSTED_OR_GOOGLE&Email=johndoe@gmail.com&Passwd=north23AZ&service=ac2dm" \ https://www.google.com/accounts/ClientLogin | \ grep Auth

If your request fails or if you are prompted for captchas, please read ClientLogin for Installed Applications. And of course, if you updated your code to use the Update-Client-Auth header after the keys had expired, then you will first need to manually generate a new token.

Have fun with C2DM!

Android Apps Break the 50MB Barrier

Android applications have historically been limited to a maximum size of 50MB. This works for most apps, and smaller is usually better — every megabyte you add makes it harder for your users to download and get started. However, some types of apps, like high-quality 3D interactive games, require more local resources.

So today, we’re expanding the Android app size limit to 4GB.

The size of your APK file will still be limited to 50MB to ensure secure on-device storage, but you can now attach expansion files to your APK.

  • Each app can have two expansion files, each one up to 2GB, in whatever format you choose.

  • Android Market will host the files to save you the hassle and cost of file serving.

  • Users will see the total size of your app and all of the downloads before they install/purchase.

On most newer devices, when users download your app from Android Market, the expansion files will be downloaded automatically, and the refund period won’t start until the expansion files are downloaded. On older devices, your app will download the expansion files the first time it runs, via a downloader library which we’ve provided below.

While you can use the two expansion files any way you wish, we recommend that one serve as the initial download and be rarely if ever updated; the second can be smaller and serve as a “patch carrier,” getting versioned with each major release.

Helpful Resources

In order to make expansion file downloading as easy as possible for developers, we're providing sample code and libraries in the Android SDK Manager.

  • In the Google Market Licensing package, an updated License Verification Library (LVL). This minor update mostly adds the ability to obtain expansion file details from the licensing server.

  • From the Google Market APK Expansion package, the downloader service example. The library makes it relatively simple to implement a downloader service in your application that follows many of our best practices, including resuming downloads and displaying a progress notification.

Because many developers may not be used to working with one or two large files for all of their secondary content, the example code also includes support for using a Zip file as the secondary file. The Zip example implements a reasonable patching strategy that allows for the main expansion file to “patch” the APK and the patch file to “patch” both the APK and the main expansion file by searching for asset files in all three places, in the order patch->main->APK.

Expansion File Basics

Expansion files have a specific naming convention and are located in a specific place for each app. As expansion files are uploaded to the publisher site, they are assigned a version code based upon the version of the APK that they are associated with. The naming convention and location are as follows:

Location: /Android/obb//
Filename: [main|patch]...obb
Example: /sdcard/Android/obb/com.example.myapp/main.5.com.example.myapp.obb

Expansion files are stored in shared storage. Unlike APK files, they can be read by any application.

Downloading and Using the Expansion Files

When the primary activity for the app is created, it should check to make sure the expansion files are available. The downloader library provides helper functions (for example the “Helpers” class in the code below) to make this easy.

boolean expansionFilesDelivered() { // get filename where main == true and version == 3 String fileName = Helpers.getExpansionAPKFileName(this, true, 3); // does the file exist with FILE_SIZE? if (!Helpers.doesFileExist(this, fileName, FILE_SIZE, false)) { return false; } return true;}

If the file does not exist, fire up the downloader service with DownloaderClientMarshaller.startDownloadServiceIfRequired(). The downloader will perform an LVL check against the server. This check will deliver the names of the files, file sizes, and the file URLs.

Once that check has been completed, it will begin downloading the files. You don’t have to use our download solution, but you might want to because we:

  • Include a notification UI that provides progress and estimated completion time in layouts customized for ICS and pre-ICS devices

  • Resume large files safely

  • Handle redirection with appropriate limits

  • Run in the background as a service

  • Pause and resume downloads when WiFi is not available

Enjoy! We can’t wait to see what kinds of things developers do with this! For more information about how to use expansion files with your app, read the APK Expansion Files developer guide.

[This post wasn’t actually written by anyone, but bashed out by a posse of engineering and product-management people. Heavy bashers included Dan Galpin, Ilya Firman, Andy Stadler, Michael Siliski, and Ellie Powers.]

Android at Mobile World Congress

I'm happy to announce that we'll be hosting a very special Android Developer Lab at Mobile World Congress (MWC) in Barcelona on Wednesday, February 17th as part of the inaugural App Planet event.

There will be technical presentations throughout the day and a developer lounge where you can talk to Android team members and meet others in the growing Android developer community.

Whether you’re already developing Android apps, you're an experienced mobile developer, or you’re considering making your ?rst foray into writing mobile applications, the Android Developer Lab will provide access to the resources you need to create innovative and compelling apps for the Android platform.

Space is limited in the technical sessions, so if you're attending MWC and want to come by the Android Developer Lab, make sure to sign up now.

Also, we're offering a limited number of complimentary passes that provide access to the Android Developer Lab, the rest of App Planet, and the general exhibition areas for MWC. Sign up to be considered to receive a pass.

Hope to see you in Barcelona!

Android Browser User-Agent Issues

[This post is by Bart Sears, who manages the Android Browser team. —Tim Bray]

This posting describes some issues when browsing websites with mobile variants using large-form-factor Android devices. This posting will be of interest both to OEMs (with recommendations on how to set the User Agent string for the device) and to web site designers/administrators (with recommendations on how to decide to provide either a mobile version, a desktop version, or a large-form-factor touch device version of the site).

Details

With the advent of Android devices with larger form factors, we’ve been evaluating the best way for web sites to provide a UI appropriate for the various Android devices that are now available to consumers. We have received feedback that consumers using larger-form-factor devices often prefer the “full” or “desktop” version of the site over the “mobile” version. Most websites providing “mobile” versions key off of the HTTP User-Agent header field to determine whether to provide the full site or a mobile version.

While large-form-factor Android devices could use “User Agent Spoofing” to provide a desktop User Agent in the HTTP header, we recommend against this. There may be site customizations needed for Android devices (for example changes in the way that mouseover is used) and the site would be unable to provide these customizations if it receives a spoofed User Agent that did not indicate that this was an Android device.

Currently, Android devices provide the following (in addition to standard info) in the User-Agent: "Android", a version number, a device name, a specific build, Webkit version info, and "Mobile". For example, Froyo on a Nexus One has the following User Agent:

Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

The "Mobile" string in the User Agent indicates that this device would prefer a version of the website optimized for Mobile (small form factor devices), if available.

We recommend that manufactures of large-form-factor devices (where the user may prefer the standard web site over a mobile optimized version) remove "Mobile" from the User Agent (and keep the rest of the User Agent as currently implemented). Web sites can then key off "Mobile" in the User Agent to decide on which UI version to present to the device. So a large screen device running Froyo would have a User Agent similar to:

Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; device Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Safari/533.1

Where "device" would be replaced with the actual name of the new device. Sites can continue to use “Android” in the User Agent to optimize for Android specific features and can also key off of “Mobile” to determine which UI to present.

Android at the Game Developer's Conference

Tuesday, March 9 marks the start of the 2010 Game Developers Conference in San Francisco, and Android will be there! There has been a lot of interest about Android from the game development community, and our presence at GDC is intended to provide developers everything they need to get started with the platform. We are hosting several technical sessions and participating in two industry panels.

We also want to meet you and answer your questions about Android game development, so we've set aside time for "office hours." Android team engineers will be on-hand to answer your questions, and if you have a game in development for Android, we'd love to see a demo.

Below, you can see the technical sessions that we're hosting and industry panels that we're participating in. We look forward to seeing you at GDC2010!

Technical sessions

Tuesday, March 9

Bootstrapping Games on Android
Chris Pruett
Everything you need to know about games on Android in 60 minutes.
1:45 PM - 2:45 PM
Room 309, South Hall

Wednesday, March 10

Bring Your Games to Android
Jack Palevich
An in-depth look at writing and porting C++ games using the NDK and a thin Java shell.
10:30 AM - 11:30 AM
Room 302, South Hall

Get the Most out of Android Media APIs
Dave Sparks & Jason Sams
Tips and tricks for optimizing your sound, video, and graphics for compatibility, efficiency, and battery life.
11:45 AM - 12:45 PM
Room 302, South Hall

Android Office Hours
The Android team
Come meet the team, ask us your questions, and show off your games!
3:00 PM - 4:00 PM
Room 302, South Hall

Industry panels

Wednesday, March 10

GamesBeat2010: A sea of mobile devices
Eric Chu
Industry experts weigh in on the future of mobile game development.
4:30 PM - 5:30 PM
Moscone Convention Center

Thursday, March 11

After the iPhone...what?
Dave Sparks
Audio experts discuss the nitty gritty technical details of alternative gaming platforms.
10:30 AM - 11:30 AM
Room 112, North Hall

Android Developer Challenge Judges and Top 50 Details

It's been a busy few weeks here as we've wrapped up the first round of the Android Developer Challenge. We'd like to share a couple pieces of information with you:

  • The full list of judges is now available. It was fun to work with such a diverse group of judges from different companies all around the world.
  • A slide deck of the Android Developer Challenge prize recipients is also available. The deck includes descriptions and screenshots of the 46 recipients who consented to sharing their information and is a great way to get a feel for the quality of apps submitted.

The prize recipients' entries were just the tip of the iceberg in terms of great applications submitted, and we'd like to thank and congratulate everyone who entered the challenge. We look forward to seeing all of the application in the hands of consumers with Android devices.