Ars reviews Android 2.2 on the Nexus One

Google is rolling out Android 2.2, codenamed Froyo, to Nexus One handsets. The new version of the operating system brings an extremely noticeable performance boost, a handful of impressive new features, some minor user interface enhancements, and useful new APIs for developers. The additions in Froyo fill some of the gaps in the platform and augment its competitiveness relative to rivals.

Froyo was unveiled at at the Google I/O developer conference in May during a keynote presentation by Google VP of engineering Vic Gundotra. Stabilizing the platform for an official Nexus One release took Google a little bit longer than expected, but the software is now being made available to users through an over-the-air update. We took it for a test drive to see how it compares to the previous version.

Batch application updates

Android 2.2 introduces several long-overdue features that substantially improve application management and make software updates less painful. Google's Android Market, a program that allows users to find and install third-party Android software, gained an "Update all" button that will initiate a batch update process for all applications installed on the device that have new versions available. This addition will spare users from having to update each application manually, a tedious process that requires several taps for each program.

The Android Market's new "Update all" button

The batch updates only require user intervention in cases where the application's permissions have changed. If the new version of the application requires access to additional device functionality, the user must give it permission before the update can commence. This is a security feature that is intended to prevent applications from silently escalating their privileges without consent.

Left: Apps with permission changes are marked "manual", Right: The batch update process skips apps that must be updated manually

When the feature was announced at Google I/O, I stopped updating applications on my Nexus One and decided to wait for Froyo's batch update feature. By the time I got Froyo this week, I had 22 applications in need of updates. This gave me a good opportunity to exercise the feature. It downloads and installs the updates in parallel, displaying progress bars in the notification slider that allow the user to monitor the progress of individual applications.

Left: A batch update displayed in the Android notification slider, Right: Multiple apps downloading simultaneously during a batch update

Two of the applications failed to download (22 at once was a bit too much for my 3G connection) and two of them had to be updated manually due to permission changes. To update the two that failed, I just had to hit the "Update all" button again after the first batch update was finished. For the two that required manual updates, I had to go through the normal application update process.

It's possible to configure individual applications to update automatically without needing user intervention. When you view information about an installed application in the Market, there is an "Allow automatic updating" checkbox that can be used to toggle the feature for a specific program. This could be especially useful for applications that are prone to security problems, because it will ensure that you get the latest version as soon as possible.

Configuring an application to update automatically

Support for automatic and batch updates is easily my favorite new feature in Android 2.2. It works as expected and eliminates one of the platform's most obnoxious and long-standing frustrations.

Storing applications on SD cards

One of the biggest failings of the N1 is that it only offers a paltry 190MB of internal storage for applications—a limitation that sets a very low ceiling for how much software can be installed on the device. Games with sophisticated graphics, for example, can burn through that storage space very quickly. Android desperately needed support for installing applications on SD cards. The feature finally arrived in Froyo, but with some limitations.

Sadly, you can't simply choose to install any application on an SD card. The developer who wrote the program has to explicitly enable the feature by setting the "installLocation" parameter in the program's manifest file, an XML document that describes application metadata. If the program's installLocation is set to "auto" in the manifest file, then the package will be installed to internal storage by default, but it will be possible for the user to move it to the SD card. If the value is set to "preferExternal" then the application will be installed to the SD card by default.

The Android Market user interface doesn't currently give users the ability to choose at the time of installation. If you want to store an application on an SD card, you have to first install it to internal storage and then use the System Settings tool to move it to external storage. In the settings tool, you can get to the application manager by tapping "Applications" and then selecting the "Manage Applications" item. This will show you a complete list of software installed on the device.

The application manager in the System Settings tool

The "On SD Card" tab shows all of the software that is installed to the SD card. If you select an item from the "Downloaded" tab, you will get information about how much storage space the application uses and you will be able to move to external storage by clicking the "Move to SD card" button. Clicking that button will move the installed package to an encrypted region on the SD card.

Moving an app to the SD card

One obvious downside of external application storage is that the software installed on the SD card will only be available when the card is mounted on the device. If you plug your phone into your computer and enable USB mass storage mode, for example, the software installed on the SD card will not be accessible. Due to this limitation, Google's developer documentation warns that long-running software like background services, live wallpapers, and widgets should not allow SD installation.

So far, the only application I could find that supports SD installation is the Jewels game by MHGames. I tested the feature by using the application manager and I found that it works as advertised. Although it is trivial to support, it may take some time for application developers to feel comfortable adopting SD installation and making it available for their software because it is still not totally clear how it impacts application performance and stability. Google claims that running an application from an SD card doesn't incur a performance penalty.

Support for external application storage is an important addition to Android, but I'm not convinced that it can completely mitigate the problems that are caused by the N1's poor internal application storage capacity.

Tethering

Android 2.2 has built-in support for USB and WiFi tethering, which makes it possible to share your device's 3G connection with other devices. These features can be toggled with checkboxes that are accessible through the network settings panel in the System Settings tool. When the WiFi hotspot feature is enabled, a blue WiFi icon will appear in the notification area. You can click the associated item in the notification slider to get to the hotspot settings. You can set an SSID and enable WPA2 encryption. WEP is not supported.

Left: Android 2.2 network settings, Right: Enabling WiFi tethering

Left: WiFi tethering in the notification slider, Right: Configuring WiFi tethering

I tested WiFi tethering by sharing my N1's 3G connection with my SmartQ tablet. It worked properly and required no additional configuration. As we discovered with the Evo 4G, however, WiFi tethering can be quite battery-intensive. It works well, but it isn't intended for long-term use. USB tethering works fine and is a good alternative when you don't want to suck your phone's battery dry.

Home screen

Android's home screen got several nice user interface enhancements in Froyo. The button at the bottom of the home screen that opens the full application list is now accompanied by an additional button on each side, providing quick access to the dialer and the Web browser. This is a nice addition to the user interface and a great use of the empty space at the bottom of the screen.

I was able to remove the regular home screen icons for those functions, freeing up two extra slots that I can now use for something else. Another benefit of the new bottom bar is that makes the dialer and browser easily accessible from every page of the home screen.

The improved Android home screen

Google also enhanced its home screen search widget. The widget is designed to provide a unified interface for searching the Web, applications, and contacts. The new version allows you to filter it to optionally limit it to a specific kind of search. For example, if you just want to search your installed applications, you click the icon and select "Apps" from the popup bubble. You can choose the default search behavior of the widget when you add it to the home screen.

Left: The improved Android search widget interface, Right: Searching for applications

I often use the search widget to find an installed application, and I sometimes find myself getting frustrated with how slow it gets. The performance improved a lot when I configured it to just search for applications, making it a lot more useful to me. It's a step in the right direction, but Google could do a lot more to improve its search feature. I really wish that the system would default to an application search when I click the search button on the device while the application list is open (one of many nice features that Google should imitate from HTC's Sense user experience).

Flash

Adobe's Flash browser plugin has not historically been viable in mobile environments. Poor performance and stability coupled with high susceptibility to security exploits and heavy power consumption simply made it a non-starter. Flash's performance is especially poor on Linux, a platform that Adobe has only marginally supported.

Prior to Froyo, there was no way to get the real Flash plugin on Android devices. Some handset makers instead shipped Flash Lite, a mobile variant that isn't fully compatible with standard Flash content. Adobe is finally starting to clean up its mess, however, and is working to address the problems that have kept Flash from succeeding on handheld devices.

Flash got a major overhaul for version 10.1, which was released on the desktop earlier this year. Adobe contends that the updated plugin is almost ready for smartphones and other devices with constrained hardware resources. A beta release of Flash 10.1 plugin for Android is available to Froyo users through the Android Market. It isn't supported on earlier versions of the operating system.

Installing Flash on Android 2.2

I installed the Flash 10.1 beta on my Nexus One to see if it lives up to Adobe's claims. After extensive testing, I have found that it works properly and provides adequate performance for rendering conventional Flash content. The handful of must-have Flash websites that I use on a regular basis all functioned properly on my N1:

Left: You can do anything at Zombo.com... if you have Flash installed

TROLOLOLOLO

The Flash Android port's support for touchscreen interaction and browser integration are relatively good. It generally behaves as expected, but it struggles with certain kinds of extremely heavy Flash content, such as the John F. Kennedy Presidential Library's "We Choose the Moon" website.

Streaming video was the first thing that I tested after installing Flash. Sadly, I wasn't able to play anything from Hulu, but this limitation on mobile viewing is imposed from Hulu's end.

No Hulu for you

Several other popular streaming video sites worked properly. For example, I had no trouble watching a Star Trek episode at the CBS website. The video played smoothly even though it was streaming over my 3G connection. I was able to switch to full-screen mode while the video was playing.

Froyo boldly goes where no Android phone has gone before

In the Android Web browser, embedded Flash content tends to have a detrimental impact on page scrolling performance. Scrolling and page drawing can become choppy, especially when there are multiple Flash elements. Fortunately, you can configure the browser to not show Flash content by default. In the browser settings panel, there is a plug-in configuration option that allows you to disable plugins or set them to a special "on-demand" mode.

When you switch the browser to the on-demand plugin mode, Flash items will not be loaded by default. Instead, you will see placeholders that you can tap to load the underlying Flash content. It works a lot like the popular Flashblock add-ons that are available for desktop Web browsers. This option is particularly advantageous on mobile devices because it ensures that Flash will only chew up resources when you actually want to view Flash content.

Flash interfaces that use drag-and-drop or mouse hovering for navigation seem to work on Android. Hovering can be a bit tricky sometimes, but it's usually just a matter of holding your finger down and moving it in the area where you want to simulate a hover event. I was initially concerned that I'd accidentally pause a video when I was trying to make the controls visible in full-screen mode, but it wasn't really a challenge in practice. Hover menus are a little bit more problematic, especially when the target is small.

When you use pinch-zooming on the N1, embedded Flash media will grow and shrink with the rest of the page. Other touch gestures like pan-dragging will usually work as expected too, but will sometimes not be recognized if there are conflicting mouse hover recognition regions in the Flash content.

One of the biggest problems that I encountered with Flash on my N1 is that it doesn't pop up the on-screen keyboard when you activate a text input element. There doesn't appear to be a way to do text entry in Flash on touchscreen Android devices. This will hopefully be rectified before the final release. Text selection works in cases where the text is intended to be selectable, but there was no way to copy it to the clipboard.

The new 10.1 update isn't a cure-all for Flash's multitude of technical deficiencies, but it does handily make the plugin run on mobile devices. As it stands, the argument for excluding Flash on smartphones is a lot less compelling today than it was prior to version 10.1. Users who are concerned about the impact on performance and battery life can use the on-demand mode to ensure that it doesn't hog resources when it isn't wanted.

Performance

Although Android applications are coded in Java, they do not run on a regular Java virtual machine. Google created its own bytecode format and a highly specialized runtime engine called Dalvik. Using a managed runtime instead of native code offers some advantages in portability and security at the expense of performance. The performance cost has been especially profound on Android because the Dalvik runtime was designed like a conventional interpreter.

The introduction of just-in-time (JIT) compilation in Android 2.2 delivers a very significant performance boost and dramatically increases execution speed. A JIT is a component of the runtime environment that can automatically convert bytecode into native code when a program is executed, allowing it to run faster. Its performance is still not comparable to that of purely native C or C++ code, but it's fast enough to noticeably improve the responsiveness of Android applications.

A JIT was not used in previous versions because the developers were concerned about the memory footprint and how it would impact application startup speed. They wanted to make sure that their JIT wouldn't have a detrimental impact on other aspects of the user experience. Their work appears to have paid off. According to Android engineer Dan Bornstein, the new JIT can make some computationally intensive Android applications two to five times faster. It doesn't degrade application startup performance and it only costs an additional 100k of memory per process.

Subjectively, just about everything in Android 2.2 feels faster and smoother. In some applications where I used to commonly notice lag when switching between tabs or waiting for lists to populate, general performance is perceivably better. Although I'm uncertain if it relates to the JIT, I'm also seeing a significant improvement in the fluidity of multitasking. Switching between applications is faster and less intrusive.

The browser is another major area where Froyo brings performance improvements. JavaScript execution is significantly faster, leading to a better experience on script-heavy websites. I conducted some JavaScript benchmarks before and after updating to Froyo so that we could measure the extent of the improvements.

As you can see, the difference is profound. For the interested, you might compare these to the results of our iPhone 4 tests.

Cloud Messaging

Android has a daemon that maintains persistent background communication with Google's servers. The always-on connection is used to facilitate some of the push synchronization capabilities that Google offers for its own applications, such as the calendar. In Android 2.2, Google has opened it up for third-party access with a new framework called Cloud to Device Messaging (C2DM).

The C2DM framework allows external Web services to send push notifications over the air to Android handsets. When you think of push notifications in the traditional sense, you probably imagine a popup bubble with some kind of text message. The magic of C2DM is that it's a hell of a lot smarter than that. It allows cloud notifications to trigger Intents—programmatic operations that are exposed by individual Android applications.

Intents are one of the key components of Android's interprocess-communication (IPC) system. You can use an Intent to launch an activity from an application on the phone and populate it with some data. For example, Android programs can use standard Intents to load a webpage in the user's default Web browser, start writing an e-mail to a specific address, launch a background service, or perform any number of other operations that are exposed through the Intent system.

C2DM basically just provides a simple way for external Web services to broadcast Intents to Android devices over the Internet. In that sense, it feels a little bit like a network-transparent IPC channel. It's an incredibly clever concept that offers a lot of flexibility.

When a third-party Web service transmits a C2DM push notification to Google's servers, the notification will be relayed to the proper device. When it arrives on a device, the Android platform determines which application is registered to receive the Intent that was embedded in the notification. The platform will hand off the Intent to the program, which causes the program to launch automatically if it isn't already running.

The Intent receiver code in the receiving application will be solely responsible for determining how to act on the Intent. There is no standard behavior for push notifications—it's entirely up to the programmer who implements the application that is registered to receive the relevant Intent. The application could be designed to display a text notification to the user, for example, but it could also just silently perform some action in the background.

The level of flexibility afforded by C2DM makes it possible to use push notifications for all kinds of novel things besides conventional messaging. At the recent Google I/O conference where the feature was first revealed, Google showed how it could be used to send map directions from your browser on a desktop computer directly to your phone—automatically opening the map application displaying the desired route. The demo was implemented with a Chrome extension that transmits an Intent via C2DM that is interpreted on an Android device by the mapping application.

Third-party Web services send C2DM notifications by issuing POST requests to a REST API endpoint on Google's servers. A registration ID value has to be supplied in the request so that Google knows which device should receive the message. As such, Android applications that rely on C2DM have to initially send the registration ID to third-party Web services from which push notifications are expected.

As developers start to take advantage of C2DM, it's likely that a lot of the messaging and network synchronization activity on Android phones will become more transparent. The need for polling remote services will reduce, potentially leading to better battery life.

The C2DM service is still very new and there are a lot of unanswered questions about its scalability. If you want to use the feature in your own software, you will have to go through a signup process on the Google Code website. You will also obviously have to be able to operate your own Web service to transmit the notifications and receive registration IDs from devices. Fortunately, it's easy to get started on App Engine if you don't have your own server.

Backup

Google has introduced a new cloud backup service in Android 2.2 that will hopefully make life easier for Android users who lose a handset or want to migrate their settings and application data to a new device. The backup service is designed to be invisible to regular end users. Applications that support the feature will use it transparently in the background.

Application developers can add cloud backup support to their software by implementing a "BackupAgent" and registering it in their application's manifest file. An agent has "onBackup" and "onRestore" functions that are called by the system. The backup function serializes data into the supported format and then hands it off to the backup manager, which is responsible for storing it in the cloud. The restore function is invoked and supplied with any available backup data when the application is installed.

The high-level APIs that are used by application developers to create backup agents completely abstract away the actual storage mechanism, leaving it hidden as an implementation detail. By default, the backup manager is designed to use Google's cloud storage to house the backup data. The backup manager is modular, however, meaning that it could potentially be adapted by the device manufacturer to use a different backend storage solution.