Android 4.0 Platform and Updated SDK Tools

Today we are announcing Android 4.0, Ice Cream Sandwich — a new version of the platform that brings a refined, unified user experience for phones, tablets, and more.

Android 4.0 builds on the things people love most about Android — efficient multitasking, rich notifications, customizable home screens, resizable widgets, and deep interactivity — and adds powerful new ways of communicating and sharing. It includes many great features for users, including social and sharing integration, network data usage control, innovative connectivity and camera options, and an updated set of standard apps.

For developers, Android 4.0 introduces many new capabilities and APIs. Here are some highlights:

Unified UI toolkit: A single set of UI components, styles, and capabilities for phones, tablets, and other devices.

Rich communication and sharing: New social and calendar APIs, Android Beam for NFC-based instant sharing, Wi-Fi Direct support, Bluetooth Health Device Profile support.

Deep interactivity and customization: Improved notifications, lockscreen with camera and music controls, and improved app management in the launcher.

New graphics, camera, and media capabilities: Image and video effects, precise camera metering and face detection, new media codecs and containers.

Interface and input: Hardware-accelerated 2D drawing, new grid-based layout, improved soft keyboard, spell-checker API, stylus input support, and better mouse support.

Improved accessibility: New accessibility APIs and text-to-speech APIs for writing new engines.

Enhancements for enterprise: Keychain and VPN APIs for managing credentials and connections, a new administrator policy for disabling the camera.

For a complete overview of what’s new for users and developers, please read the Android 4.0 Platform Highlights.

Alongside the new Android platform, we are releasing new versions of the SDK Tools (r14) and ADT Plugin (14.0) for Eclipse. Among the highlights are:

• Improved build performance in Ant and Eclipse


• Improved layout and XML editors

To get started developing on Android 4.0, visit the Android Developers site for information about the Android 4.0 platform, the SDK Tools, and the ADT Plugin.

If you have already developed and published apps, we encourage you to download the Android 4.0 platform now, to begin testing your app before devices arrive in stores.

Check out the video below for a closer look at Android 4.0 in action.

Google Play Featured-Image Guidelines

By Natascha Bock, a Product Marketing Manager on the Google Play team

If your app is selected for featuring on Google Play,our editorial team uses your 1024 x 500 “Featured Image” to promote the app on tablets, phones, and the Web. The image can be used on the home page on all versions of Google Play (Web, tablet and phone), on your product page in the Web and tablet versions, and on current and future top-level Google Play pages on phones.

Creating a Featured Image that will do a great job of highlighting your app requires special design consideration, and localizing your featured image for your key markets is highly recommended.

Not Really Optional

While many promotional assets are listed as “optional” for publishing in Google Play, we strongly recommend treating them as required. To start with, a Featured Image is required if your app is to be featured anywhere within Google Play. They’re a good idea anyhow; they enhance your product page, making your game or app more attractive to end-users (and more likely to be considered for featuring by our editorial team).

There’s nothing optional about the size, either; it has to be 1024 x 500 pixels.

Do’s and Dont’s

Your graphic is not an ad, it’s a teaser. It’s a place for bold, creative promotional images.

Vivid background colors work best. Black and white are problems because those are the backgrounds used by the mobile-device and Web versions of Google Play.

Limit Text to your app name and maybe a few additional descriptive words. Anything else will be unreadable on phones, anyhow.

Do: Make the graphic fun and enticing./td>	Don't: Create a text-heavy advertising-style graphic.
Do: Use colors that stand out on black or white backgrounds.	Don't: Let the graphic fade into the background.
Do: Promote your brand prominently.	Don't: Overload the graphic with details.
Do: Localize your image as needed for different languages.

Scaling

Your image has to be designed to scale; it will need to look good both in a full-size Web browser and on a little handset. You can rely on the aspect ratio being constant, but not the size. Here’s a tip: Try resizing your image down to 1 inch in width. If it still looks good and conveys your brand message, you have a winner.

On the Web:

On a tablet:

On a big phone:

On a small phone:

More Dont’s

• Device imagery is tempting, but becomes dated fast, and may be inappropriate if your user’s device looks entirely different.

• In-app screenshots are inappropriate because your product page already includes a place for these.

• Just using your app icon is a failure of imagination. You have more room; put it to good use!

Consider the Context

Given the size of the form factor, the phone is the most challenging channel for your image. At right we have both the “good” and “bad” sample images in that context:

Localize your Featured Image, videos, and other promotional assets

Android's user base is global. To help you reach all of these users effectively, Google Play lets you provide a separate featured image for each language that you support, as well as separate screenshots and promotional videos. You can add your localized images and videos in the Developer Console.

Localizing your featured image is highly recommended as a powerful way to get your message across to users around the world. It goes hand-in-hand with localizing your app's description and other details and it's built-in string resources.

Don’t Forget

A 1024 x 500 Featured Image is required for feature placement consideration. Don't miss out on the opportunity!

Android’s HTTP Clients

[This post is by Jesse Wilson from the Dalvik team. —Tim Bray]

Most network-connected Android apps will use HTTP to send and receive data. Android includes two HTTP clients: HttpURLConnection and Apache HTTP Client. Both support HTTPS, streaming uploads and downloads, configurable timeouts, IPv6 and connection pooling.

Apache HTTP Client

DefaultHttpClient and its sibling AndroidHttpClient are extensible HTTP clients suitable for web browsers. They have large and flexible APIs. Their implementation is stable and they have few bugs.

But the large size of this API makes it difficult for us to improve it without breaking compatibility. The Android team is not actively working on Apache HTTP Client.

HttpURLConnection

HttpURLConnection is a general-purpose, lightweight HTTP client suitable for most applications. This class has humble beginnings, but its focused API has made it easy for us to improve steadily.

Prior to Froyo, HttpURLConnection had some frustrating bugs. In particular, calling close() on a readable InputStream could poison the connection pool. Work around this by disabling connection pooling:

private void disableConnectionReuseIfNecessary() {
    // HTTP connection reuse which was buggy pre-froyo
    if (Integer.parseInt(Build.VERSION.SDK) < Build.VERSION_CODES.FROYO) {
        System.setProperty("http.keepAlive", "false");
    }
}

In Gingerbread, we added transparent response compression. HttpURLConnection will automatically add this header to outgoing requests, and handle the corresponding response:

Accept-Encoding: gzip

Take advantage of this by configuring your Web server to compress responses for clients that can support it. If response compression is problematic, the class documentation shows how to disable it.

Since HTTP’s Content-Length header returns the compressed size, it is an error to use getContentLength() to size buffers for the uncompressed data. Instead, read bytes from the response until InputStream.read() returns -1.

We also made several improvements to HTTPS in Gingerbread. HttpsURLConnection attempts to connect with Server Name Indication (SNI) which allows multiple HTTPS hosts to share an IP address. It also enables compression and session tickets. Should the connection fail, it is automatically retried without these features. This makes HttpsURLConnection efficient when connecting to up-to-date servers, without breaking compatibility with older ones.

In Ice Cream Sandwich, we are adding a response cache. With the cache installed, HTTP requests will be satisfied in one of three ways:

• Fully cached responses are served directly from local storage. Because no network connection needs to be made such responses are available immediately.




• Conditionally cached responses must have their freshness validated by the webserver. The client sends a request like “Give me /foo.png if it changed since yesterday” and the server replies with either the updated content or a 304 Not Modified status. If the content is unchanged it will not be downloaded!




• Uncached responses are served from the web. These responses will get stored in the response cache for later.

Use reflection to enable HTTP response caching on devices that support it. This sample code will turn on the response cache on Ice Cream Sandwich without affecting earlier releases:

private void enableHttpResponseCache() {
    try {
        long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
        File httpCacheDir = new File(getCacheDir(), "http");
        Class.forName("android.net.http.HttpResponseCache")
            .getMethod("install", File.class, long.class)
            .invoke(null, httpCacheDir, httpCacheSize);
    } catch (Exception httpResponseCacheNotAvailable) {
    }
}

You should also configure your Web server to set cache headers on its HTTP responses.

Which client is best?

Apache HTTP client has fewer bugs on Eclair and Froyo. It is the best choice for these releases.

For Gingerbread and better, HttpURLConnection is the best choice. Its simple API and small size makes it great fit for Android. Transparent compression and response caching reduce network use, improve speed and save battery. New applications should use HttpURLConnection; it is where we will be spending our energy going forward.

Euro Android Developer Labs

This series started last month, and now registration is open for the European leg:

• Berlin — September 28 and 29.

• London — October 3 and 5.

• Paris — October 27 and 28.

Remember, this ADL series isn’t another set of introduction-to-Android sessions, nor any other kind of general overview. It's specifically aimed at optimizing Android apps for tablets, in particular creating high-quality tablet apps with an emphasis on polish and user-experience.

Registration is a two-step process. Anyone can register, but we can only accommodate a relatively small number of attendees from among the registrants, based on whether they already have an Android app with the potential to be a top-tier tablet app in terms of quality, fit, and finish. The goal is to bring your app to the ADL, and leave equipped to make it into one that makes Android tablet users smile.