Android 2.2 (FroYo) review
Among the many exciting announcements in their annual I/O conference, Google released the Android 2.2 SDK (FroYo) to developers. This highly anticipated platform upgrade brings with it exciting improvements and features for users and new tools for application developers and publishers. Here’s what we make of it…
Two of the most highly anticipated user features of the Android 2.2 release are built-in tethering and portable Wi-Fi hotspot capabilities. Tethering allows a USB-connected computer to share an Android device’s data connection. The portable hotspot feature turns an Android device into a Wi-Fi hotspot (open or secured), usable by nearly any Wi-Fi device. We suspect some carriers may charge for this feature.
Speaking of the web experience, Android 2.2 now supports Adobe Flash 10.1. Flash is provided as an Android Market download for handsets that run Android 2.2 and higher. When installed, Flash content runs seamlessly in the Browser application. This will enable many websites to reach millions of new mobile users. Adobe has also enabled Android as a target for AIR applications (Flash apps packaged as Android apps). If you believe Steve Jobs’ memo, Thoughts on Flash, Apple will not be supporting Flash (or other cross-platform environments) on iOS anytime soon. This is a distinct marketing advantage for Android; it also invites a whole new class of developers and publishers to the Android development community.
Along the lines of features not technically part of Android 2.2, but that require the platform to function properly, Google has announced an enhanced web-based market for Android applications. Here users can browse and purchase Android applications from the comfort of their computer. The applications are then pushed to the device over-the-air. This enables Android application developers to easily market their applications on the Internet. Google has also added a music store to the Market, allowing consumers to buy music content while browsing online and have it instantly delivered to their Android handset–without syncing. This feature takes direct aim at the Apple store’s music features.
The ability to push data to the device isn’t just for the web-based app store. Developers can take advantage of the new push service called Android Cloud to Device Messaging (C2DM). This service has been developed as a Google Labs project in conjunction with Android 2.2, allowing developers to push data to their Android applications remotely. C2DM integrates with all Android devices running the Google APIs and uses a single, shared background service to handle messaging traffic for all Android applications. From the application perspective, messages come in as normal ‘Intent’ objects. C2DM message quotas are strictly enforced and the size of a given message is limited to 1k, but the utility for such a service is broad-reaching. The only issue is that C2DM is currently available as a closed beta–it’s unclear when C2DM will be publicly available to all Android developers.
Each new Android SDK enables more innovative and interesting applications to be developed, filling users’ devices to the brim. Prior to Android 2.2, applications could only be installed on internal device storage—not terribly flexible, given the most device storage comes in the form of external SD cards. Starting in 2.2, developers can enable their applications to be installable on external storage, allowing for larger and more resource-intensive applications to run smoothly on the platform.
Until now, the relationship between the developer/publisher and the user has been very loose and informal, managed almost completely within the Android Market rating and review system. When an Android app crashed in the field, the app’s developer might not find out about it until frustrated users posted negative reviews and ratings for the app. This mechanism was not especially productive, helpful, or flexible. Android 2.2 now has built-in end-to-end bug reporting mechanism. When an application crashes, a dialog appears, allowing the user to report the error. The error (and related diagnostic information) is sent to the developer so they can find and fix the problem.