At the Google I/O Conference, the company announced new APIs that every developer should know about – especially those who care about location services, cloud messaging and Bluetooth.
In prior years, Google has used its I/O Conference to announce a new version of Android—to the delight of a minority of users with Nexus devices, and to the dismay of developers who knew that they’d have to support older versions for a lot longer. (The pace of Android updates from manufacturers and carriers has gotten so horrendously slow that the American Civil Liberties Union asked the Federal Trade Commission to investigate the matter.)
This time around, Google did something different: It announced a batch of new APIs that should work on Android releases going back to the 2.2 Froyo version announced at 2010’s I/O gathering in San Francisco.
(Game developers got their own set of new APIs that provide such features as cloud saves, multiplayer gaming, achievements and leaderboards; they require a Google+ sign-in by the user but can also be used in iOS titles. For more details, see Florence Ion’s breakdown of these new Google Play Game Services at Ars Technica.)
But in one area in need of repairs, Google’s fixes will require a new version of Android that most users won’t have for months, if ever.
The most important news for developers—both in terms of how many apps could benefit and the potential to address everybody’s number-one complaint, battery life—has to be Android’s three new location APIs. As Google engineer Waleed Kadous said in a presentation, they’re “probably the biggest change in location since Android was released.”
First, a Fused Location Provider service will free developers from having to call three different sources of location data (the phone’s accelerometer, compass, and other sensors; cellular network and Wi-Fi signals; and GPS). Instead, an app can simply call Google Play services to get the phone’s location, which Android will determine by combining the best data from those separate sources.
Those motion sensors play an important role in that process: If the accelerometer shows you haven’t physically moved, the OS can know not to check for a new location.
You can add basic quality-of-service requests to a location request: high accuracy via GPS, minimum power use, or a “balanced” option that only provides 100-meter accuracy. The latter promises major battery savings: a battery drain of just .6% per hour, compared to 7.25% for the high-accuracy mode.
Next comes a Geofence API that apps can call for battery-friendly determinations of when the phone exits or enters user-designated locations, up to 100 active in any one app. For instance, a demo at I/O showed a Zillow app popping up a notification to remind the user that he was near a listing he’d marked as a favorite earlier. (The app that I want to see updated for this first is Camera; I’m tired of having to remember to turn off location sharing when I’m at home, then switch it back on when I’m away.)
Finally, an ActivityRecognitionClient class will use the phone’s sensors to determine if the user is sitting still, driving, on foot, or on a bike. (Users will know they’re about to download an app written for this when it presents a new activity_recognition permission.) This should help the increasing variety of exercise-tracking apps, if not sales of such separate exercise-tracking devices as the Jawbone Up.
Google Cloud Messaging
Apps that talk to a server—that is, a huge chunk of the entire Android ecosystem—can benefit from upgrades to the Google Cloud Messaging (GCM) service launched last summer. GCM can spare apps from having to poll servers on their own; instead, the server sends a message to GCM, which in turn either sends a signal to the app that it’s time to sync or delivers up to 4 kilobytes of a data payload such as an instant message.
One change announced at I/O should gladden the hearts of anybody who switches among multiple Android devices (such as, hypothetically speaking, tech journalists whose desks bear the weight of a changing array of loaner Android phones). A new user notifications system will keep those alerts in sync across all of your devices, and in close to real time. To use it, an app has to switch from telling GCM to ping registered devices to having it send the message to a registered user—identified only by a hash of a username or an e-mail address. (Twitter and Facebook, get to work.)
Another, Cloud Connection Server, should speed up GCM for everybody and allow for upstream, device-to-cloud communication. It runs on Extensible Messaging and Presence Protocol (XMPP) instead of HTTP, although apps can keep using that older option. Google strongly endorses XMPP in this use case, citing its more efficient asynchronous operation, support for device-to-cloud notification, and lower energy use.
However, the we-love-XMPP memo did not reach all of the Google campus. Right after the announcement of a unified Hangouts messaging service at I/O, Google Talk dropped its XMPP option.
Android’s Bluetooth support historically has suffered from tardy additions of different profiles and the use of a changing assortment of Bluetooth stacks. The results have been ugly sometimes; my Nexus 4, with the latest software available, hits maybe .500 at the basic jobs of pairing with our car’s Bluetooth and transferring files to my Mac, and sometimes I can’t even turn on Bluetooth. (A Google presenter at I/O apologetically described Bluetooth on the Nexus 4 as “kind of busted.”)
The good news at I/O was that Google, having finally anointed the Broadcom-contributed BlueDroid stack as Android’s Bluetooth software, will add support for Bluetooth Low Energy. This newer version of the wireless-data standard is optimized for low-throughput, intermittent communication with peripherals like pedometers, fitness sensors, watches, game controllers, and even an upcoming door lock.
Apple’s iOS already supports BLE and therefore “Bluetooth Smart Ready” and “Bluetooth Smart” devices, but only a few Android phones—for instance, Motorola’s Droid Razr series and Samsung’s Galaxy S III and 4—have added BLE via their own software stacks.
BLE won’t help with constant, higher-bandwidth use cases such as streaming audio, but another upcoming addition—support for version 1.3 of Bluetooth’s Audio/Video Remote Control Profile (AVRCP)—will make music sharing a richer experience, thanks to its ability to send metadata and playback-state data over the same stream as a song.
The bad news shared at I/O is that all of these fixes will only ship with the next version of Android, 4.3 (or API Level 18). At an I/O presentation, that was promised “in a few short months.” Almost certainly that means that while Nexus users like me should get the enhancements soon after, everybody else can wait months for manufacturers and then carriers to certify 4.3 and ship phone-specific updates. If they do so at all.
- How to Use Google Chart Tools with Web Applications
- Using the Google Maps API to Add Cool Stuff to Your Applications
- 7 Editors for the Android — for Free or Cheap
- Show Me the Money: Which Mobile Apps are Profitable for Developers?