Dashing through the snow... with NORAD and Google

(Cross-posted from the Official Google Blog and Lat Long Blog)

Every Christmas Eve, children all over the world ask themselves—and their parents—questions about Santa’s magical journey. How does Santa visit so many children in one night? Will he eat the cookies I left out? How does he fit all those presents into his sleigh? These childhood mysteries are part of what makes the Santa tradition so special.

There’s one timeless question that we’re proud to say we can help answer: Where in the world is Santa at this very moment? Thanks in part to recent advances in warp-speed GPS technology and some very clever elves (elveneering?) NORAD Tracks Santa is once again prepped and ready to go.

Starting tomorrow, December 24 at 2:00am EST, visit www.noradsanta.org to follow Santa as he journeys around the world delivering presents to children in more than 200 countries and territories. There are a few different ways to find the jolly old man in his unmistakable red suit over the course of the day, so feel free to track him using any of the following methods:
  • See Santa on a Google Map: On your home computer or laptop, visit www.noradsanta.org and choose your preferred language. You’ll see a large Google Map on the page displaying Santa’s current location and his next stop. Click the video icons to watch “Santa Cam” videos, and click the gift icons to learn more about each city.

  • Watch Santa fly with the Google Earth Plug-in: From www.noradsanta.org, click on the link Track Santa in Google Earth. You'll see Santa steering his sleigh right on the webpage. If you don't have the Google Earth plug-in, you can get ready by downloading it ahead of time.

  • Follow Santa on your phone: Track Santa from your mobile phone by opening Google Maps for mobile and searching for [santa]. Or, visit m.noradsanta.org on your phone’s browser.

  • Subscribe to his YouTube channel: Santa’s home on YouTube is at http://www.youtube.com/noradtrackssanta. That’s where you can find videos from his journey throughout the night.

  • Get real-time information about Santa’s location: Use Google’s Realtime Search to get updates from social networks, news and micro-blogs like Twitter at @noradsanta, and keep up with news about his journey on this Facebook page.
For any techie questions you might have, we’ve also put together some helpful tips and tricks about all the cool ways you can experience Santa’s journey. Now that you know how to follow Saint Nick on Christmas Eve, it’s our tradition to tell the story of how this all started...

NORAD (North American Aerospace Defence Command) first began to track Santa in 1955 when a misprinted advertisement in a Sears & Roebuck catalogue mistakenly led callers expecting a Santa-hotline to the NORAD commander-in-chief's telephone. Embracing the spirit of the season, NORAD used its satellite and radar capabilities to offer callers sleigh-location updates, and has tracked Santa's whereabouts on Christmas Eve ever since. Then in 2004, Google started tracking Santa on Google Earth as a 20% project, which in 2007 grew into a partnership with NORAD, adding the mapping technology of Google Maps and Google Earth to the NORAD experience. Over the years, other Google teams have also joined in the holiday fun (YouTube, Google Voice’s www.SendACallFromSanta.com and Google SketchUp).

As we approach this year’s Christmas Eve adventure, Santa was able to take a break from the preparations to visit the New York Stock Exchange this past Monday. His helpful elves kept everything at the North Pole on schedule while folks from Google and NORAD attended the Closing Bell ceremony, and stood alongside Santa from Macy’s going over last minute details about tomorrow’s big ride.

Santa with NORAD, Google and members of the Marine Toys for Tots Foundation (that’s me, the tall guy in the back row clapping)

So don’t forget to visit www.noradsanta.org tomorrow morning starting at 2:00am EST when Santa embarks on his flight. From all of us here at Google, happy holidays and here’s to a very happy New Year!


More Payment Options in Android Market

[This post is by Eric Chu, Android Developer Ecosystem. —Dirk Dougherty]



A key to a great purchasing experience is providing users with simple and fast payment methods. The Android Market team has been working hard to deliver more forms of payment to further reduce purchase friction.


Today, I am pleased to announce the availability of AT&T Direct Carrier Billing for Android users on the AT&T network. AT&T Android users can now easily charge their Android Market purchases to their monthly accounts with only a few clicks. With the combination of Android Market’s new app discovery features and a carrier-backed frictionless payment method, users will find it significantly easier to discover and purchase applications of their choice.


We’ve been rolling out Direct Carrier Billing to all AT&T users over the past several days, as part of a general update to the Market service. Also in the update, please watch for the arrival of new features we announced recently, including the 15-minute refund window, dynamic Wallpaper and Widget categories, new 50MB max .apk size, and more. In addition, we’ve added even more categories to make it easier to find great apps in popular categories, such as “Media & Video”, “Music & Audio”, “Business”, “Sports” (in "Games"), and more. If you have one or more published apps on Android Market, please take a look at these new categories and decide if they are more suitable for your products.


We strongly believe carrier billing is a great way to make it easy for users to purchase and pay for applications. In addition to the availability of AT&T and T-Mobile US carrier billing, we’ll continue to partner with more carriers to offer carrier billing options for their subscribers.


2010 has been an awesome year for Android due in large part to your support. We have seen tremendous growth in Android Market both in terms of application volume and quality. In 2011, we remain committed to making Android Market the best mobile application store possible. As always, please don’t hesitate to continue giving us feedback through Market Help Center.


Best wishes for the new year!

Android In Spaaaace!

Here at Google, we’re all about exploration. It’s no surprise that some of our favorite products are built to let you explore the world in ways never before possible. Google Maps lets you find your way all around the world. Google Earth lets you explore the planet in detail, complete with trees and oceans. And Google Sky Map lets you explore the skies right from your Android device. Well, we wanted to do a little exploring of our own, so we decided to venture into near space, with the help of some Androids.

Recently, we travelled to Ione, CA and sent seven payloads up, up, and away into near space, each equipped with a Nexus S. We took some cues from others who have sent homemade weather balloon rigs far up, and we wanted an opportunity to collect some interesting data about the sensors in Nexus S – GPS, gyroscope, accelerometer, and magnetometer. We also couldn’t resist what looked like a great way to spend a weekend. Sending the balloons up also gave us an opportunity to capture some stunning imagery and videos of Earth. Take a look at unaltered footage of an Android at over 100,000 ft above the Earth’s surface:




The Rig
How did we get our little Android commanders that high up? Well, first the Android platform provides a robust development environment and Nexus S has a great set of embedded sensors, both of which made it easy for us to write the apps we needed for this project. Going forward with other similar projects we have an open environment that we can modify at any level necessary. We then worked with UCSC student Greg Klein to prepare each of the payloads, which were housed in foam coolers. We secured a nylon load line to the cooler and attached to it a radar reflector, a parachute, and finally, a weather balloon. Every payload had an APRS transmitter attached to a GPS that was known to work at high altitudes, as well as batteries for power. The remainder of each payload was different for each balloon: some had digital cameras taking pictures and some had video cameras mounted at various angles (up, down, and at the horizon).

These phones were running a variety of apps: Google Maps for Mobile 5.0 (with offline map data) which allowed us to see what was directly below the balloon, Google Sky Map to see if we could identify the real stars in the backdrop, Latitude to report location when the phones had a data connection, and our own custom sensor logging app that sampled all the available sensors on the device. We even manned our payloads with some special astronauts: small Android robots, and boy did they fly. Check out an in-depth look at how we prepared and launched the payloads:




What We Found
The payloads collected a lot of data, and many reached high altitudes, with the highest topping out at 107,375 ft., over 20 miles high, or over three times the height of an average commercial jet. We also clocked one of the payloads at 139 mph at its fastest.

In tracking the sensors on each of the phones, we observed that the GPS in Nexus S could function up to altitudes of about 60,000 ft. and would actually start working again on the balloon’s descent. We also saw that Nexus S could withstand some pretty harsh temperatures (as low as -50˚C). Some interesting data we collected:
Maximum Speed: 139 mph
Maximum Altitude: 107,375 ft (over 20 miles, over 30 km)
Maximum Ascent Rate: 5.44 m/s
Average Flight Duration: 2 hours, 40 minutes
Average Descent Time: 34 minutes

By analyzing all the collected data, we were able to find some interesting trends. For instance, we determined the speed and altitude of the jet stream: about 130mph at 35,000 ft.

In the end, the team recovered all of the payloads sent up, we even recovered the payload we sent as a test a week prior to the actual launch. We had a blast taking Android all the way up to near space. If you're interested in launching a balloon of your own, click here for more info. We have more exciting things coming your way as we use the openness of the Android platform to experiment here at mission Android headquarters.

*Special thanks to Arshan Poursohi, Greg Klein, and Tommy Nourse for all their help.

Posted by Zi Wang, Captain, Mission Android Headquarters

It’s not “rooting”, it’s openness

[This post is by Nick Kralevich, an engineer on the Android Security Team. — Tim Bray]

“Nexus S has been rooted, let the madness commence!” proclaims Engadget. “This is only possible because Android's security is crap and it's exploited easily to gain root priviledges [sic]” adds a commenter.

You’ll have to excuse me if I strongly disagree.

The Nexus S, like the Nexus One before it, is designed to allow enthusiasts to install custom operating systems. Allowing your own boot image on a pure Nexus S is as simple as running fastboot oem unlock. It should be no surprise that modifying the operating system can give you root access to your phone. Hopefully that’s just the beginning of the changes you might make.

Legitimately gaining root access to your device is a far cry from most rooting exploits. Traditional rooting attacks are typically performed by exploiting an unpatched security hole on the device. Rooting is not a feature of a device; rather, it is the active exploitation of a known security hole.

Android has a strong security strategy, backed by a solid implementation. By default, all Android applications are sandboxed from each other, helping to ensure that a malicious or buggy application cannot interfere with another. All applications are required to declare the permissions they use, ensuring the user is in control of the information they share. And yes, we aggressively fix known security holes, including those that can be used for rooting. Our peers in the security community have recognized our contribution to mobile security, and for that, we are extremely grateful.

Unfortunately, until carriers and manufacturers provide an easy method to legitimately unlock devices, there will be a natural tension between the rooting and security communities. We can only hope that carriers and manufacturers will recognize this, and not force users to choose between device openness and security. It’s possible to design unlocking techniques that protect the integrity of the mobile network, the rights of content providers, and the rights of application developers, while at the same time giving users choice. Users should demand no less.

Under the hood of Google Maps 5.0 for Android

(Cross-posted from the Official Google Blog)

Yesterday we introduced Google Maps 5.0 for Android with two significant new features: 3D interaction and offline reliability. In order to create these features, we rebuilt Maps using vector graphics to dynamically draw the map as you use it. Building a vector graphics engine capable of achieving the visual quality and performance level you expect from Google Maps was a major technical challenge and enables all sorts of future possibilities. So we wanted to give you a closer look under the hood at the technology driving the next generation of mobile maps.

Vector graphics
Before diving into how Maps uses vector graphics, it may be helpful to understand how maps were created before. Previously, Google Maps downloaded the map as sets of individual 256x256 pixel “image tiles.” Each pre-rendered image tile was downloaded with its own section of map imagery, roads, labels and other features baked right in. Google Maps would download each tile as you needed it and then stitch sets together to form the map you see. It takes more than 360 billion tiles to cover the whole world at 20 zoom levels!

Now, we use vector graphics to dynamically draw the map. Maps will download “vector tiles” that describe the underlying geometry of the map. You can think of them as the blueprints needed to draw a map, instead of static map images. Because you only need to download the blueprints, the amount of data needed to draw maps from vector tiles is drastically less than when downloading pre-rendered image tiles. Google Maps isn’t the first mobile app to use vector graphics—in fact, Google Earth and our Navigation (Beta) feature do already. But a combination of modern device hardware and innovative engineering allow us to stream vector tiles efficiently and render them smoothly, while maintaining the speed and readability we require in Google Maps. Just try it out and see for yourself!

See the difference between image tiles (left) and vector tiles (right) tilted to show 3D buildings.

One map, many perspectives
Using vector tiles instead of image tiles gives Maps the flexibility to re-draw the same map from different perspectives using the same set of data. Zooming is one example of this at work. If you magnify an map image tile by 2x, lines such as roads and text would get twice as wide and appear blurry. As a result, we had to constrain Maps to 20 fixed “zoom levels,” each one twice as close as the last. Every time you zoomed in further, you’d need to download a completely new set of image tiles. It took time to load new data over a mobile data connection, and would fail when you lost your connection in a subway or large building.

Compared to image tiles (left), vector tiles (right) keep lines and labels crisp as you zoom.

With vector graphics, you no longer need to “round” to the nearest zoom level and then download all the tiles for that level. One vector tile has the underlying vector data (or blueprints) to draw the map at many different levels of scale. So when you zoom, the map stops when your fingers stop, and roads and labels always stay crisp. This same technique powers the new 3D map interactions: tilt, rotate and compass mode. Just like with zooming, Maps uses the same vector data to draw the map from any angle or direction as you tilt or rotate.

We can also display entirely new levels of detail that weren’t possible with flat image tiles. For example, in the 100+ cities where we have 3D building data, each building is drawn in 3D using a polygonal building footprint and heights for different parts of the building. And with tilt and rotate, you can see them from a variety of different angles.

Reading the map
Just like other map features, labels are dynamically drawn so they continue to face you and stay legible if you rotate the rest of the map or use compass mode. Maps also “chooses” the best labels to show you based on several factors. You’ll notice labels fade in and out as you interact with the map so that the most useful ones appear and the map never gets too cluttered.

See the difference between rotating maps with static labels (left) and dynamic labels (right).

Vector graphics also allow us to draw additional data on the map more clearly. For example, traffic or transit lines no longer block the labels beneath them. We can also draw the same map in different styles — like “satellite view” where the roads are translucent over aerial imagery, or Navigation’s “night mode” where a darker palette helps your eyes adjust quickly in the lower light.

Previously, map features like labels and traffic could conflict (left) instead of blend seamlessly (right).

Offline reliability
Vector graphics also enable another significant new feature: the ability to continue viewing maps even when you have poor—or no—network connections. Because each vector tile works across multiple zoom levels, it requires more than 100 times less data to view maps across all zoom levels than before, allowing Maps to cache much larger areas of the map on your device.

With this first version, Maps proactively caches map data for the places you use Maps the most—where you’re actively using it as well as places for which you search or get directions. Then when you’re plugged in and connected over WiFi, caching happens automatically. Near your frequent places, you’ll get detailed vector tiles for city-sized regions so you can see every road labeled. Further away, you’ll have less detail but will typically have towns and highways labeled for miles. We’re continuing to work on these algorithms, so you’ll see improvements over time.

Offline rerouting
With Google Maps Navigation (Beta), you’ll also see the benefits of additional caching with offline rerouting. This feature is only possible because Navigation caches not only map data but also data like turn restrictions for the areas surrounding your route. You’ll still need to be connected when you first start a trip to download and cache your route. But this way, even if you take a wrong turn after losing your connection, Navigation can use the cached data to get you back on your way. We will be rolling this feature out gradually over the next few weeks.

This is just the start, and we’re really excited about all the possible ways to use vector graphics technology for the next generation of Google Maps. So please stay tuned!

Update (12:47pm PST): Tweaked the description of the difference between image maps zoom levels.

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.

The next generation of mobile maps

(Cross-posted from the Official Google Blog and the Google Lat Long Blog)

Update (12/17/2010 11:30am PST): Check out a related post on the technology powering Google Maps 5.0 for Android.

I’m excited to announce Google Maps 5.0 for Android, with two significant new features: 3D interaction and offline reliability.

We launched Google Maps for mobile a little more than five years ago. Since then, we’ve added dozens of features, and we’ve grown from a few thousand to more than 100 million users. Still, a couple of things have remained the same: a flat, north-up map and the need for a strong Internet connection. Today, we’re changing that for the first time.

Tilt while zoomed in (left) or use compass mode (right) to orient yourself with 3D buildings.

Explore maps in 3D
Until now, Google Maps has always downloaded the map as a set of small, square images that we stitch together to form the map you see. (You’ve probably seen those gray squares getting filled in, block-by-block, as the images load over the network.) Starting today, we’ll use vector graphics to dynamically draw the map on your device as you use it, allowing you to interact with it in new ways:
  • Tilting: Drag down with two fingers to tilt the map. Tilt while zoomed in on one of the 100+ cities around the world with 3D buildings to see a skyline spring to life.
  • Rotating: Twist with two fingers to rotate the map. After tilting to see 3D buildings, rotate around them to gain a new perspective from any direction.
  • Smooth zooming: Slide two fingers together or apart, and see the map and labels continuously scale to any zoom level, stopping when your fingers stop.
  • Compass mode: Center the map on your location, and then tap the compass button in the top right corner. The map will flip into 3D mode and start rotating to match your perspective, while still keeping all the labels upright and readable.
I found 3D buildings especially useful on a recent trip to New York. From my hotel to the Google office in Chelsea and bars on the Lower East Side, this richer representation of the real world made the map much more helpful. And whenever I walked out of a building or subway station, I used compass mode to get myself quickly oriented and on my way. Check out the video below to see tilt, rotation, zoom and compass mode in action, or see more pictures.



Offline reliability
Google Maps has always been, and continues to be, a fundamentally Internet-connected experience, meaning you always get the freshest map and place data, search and voice search, live traffic conditions, satellite and Street View imagery, and much more. Still, we understand that mobile Internet connections aren’t 100% reliable. So today we’re happy to take the first steps toward greater offline reliability, so you can find your way even if you lose your connection.

In the past, you’ve probably had frustrating moments when you get stranded without a map, whether ducking into the subway, sitting at the back of a restaurant or traveling anywhere with a flaky Internet connection. But dynamically drawing maps requires 100 times less data to get maps across all zoom levels, so now we’re able to proactively cache (or store) large areas on your device based on where you use Maps the most. This way, you can rely on having fast, robust maps available to you where you’re most likely to need them.

For example, I live in San Francisco and work in Mountain View, so Maps makes sure I can always pull up detailed street maps of each city and area maps for the whole San Francisco Bay Area. When I do have an Internet connection, I still get live traffic, imagery, richer map details and all the other features I’m used to with Google Maps.

Rather than having a static set of maps when installed, Maps will automatically start caching the areas you visit the most when your device is plugged in and connected to WiFi (e.g., the nightly charge). We’re already hard at work improving the algorithms and technology behind these features, so over time you can expect to see maps work better in more offline situations.

Offline rerouting
If you’re one of the more than 10 million people relying on Google Maps Navigation (Beta), our free turn-by-turn GPS navigation feature, losing your Internet connection can be particularly painful. (This happened to me on a recent ski trip to Tahoe, and I was left trying to manually find my way back to my route.) So we’re also introducing offline rerouting. You’ll still need a connection to start a route, but if you miss a turn along the way, we’ll quickly get you back on track, even if you don’t have an Internet connection. We’ll be rolling this feature out gradually over the next few weeks.

Google Maps Navigation now automatically reroutes you, even if you lose your connection.

These new features are just the first steps in maximizing dynamic map drawing technology to create a faster, more interactive experience where efficiency really matters: mobile devices. For example, we estimate that viewing maps now requires almost 70% less mobile network data overall than before. We can’t wait to take the next steps in making Google Maps faster, more reliable and even more useful no matter where you take it.

Get Google Maps for mobile 5.0 by searching for Google Maps in Android Market (or tap on this link if you’re on your phone). Android 1.6+ devices can get Maps 5.0, but 3D and offline features require Android 2.0+, and some features may not be supported for all devices or countries.

So try it out. Wander around in compass mode, explore 3D buildings—even dare to open Maps on the subway! I hope you enjoy all the new features as much as we do.

The wait is over: Announcing Nexus S availability in the U.S.

Last week we announced Nexus S, a pure Google phone. With a brilliant 4” Contour Display, a 1GHz Hummingbird processor, the latest Google mobile apps and Android 2.3 (Gingerbread) pre-installed, we’re excited about getting this great device out there.

We’re pleased to announce that starting today, this phone will be available for sale through Best Buy and Best Buy Mobile stores across the U.S. and online. The phone is sold unlocked and can be bought for $529.99 without a service plan or for $199.99 with a T-Mobile service plan.

Can't make it to a store? Order online now through Best Buy. By the way, some of our old friends also can’t wait to get their hands on a Nexus S!

Update Dec 16 10:52am PST: Looking to purchase a no-contract Nexus S from Best Buy? Look no further

Posted by Kenzo Fong Hing, Product Marketing Manager

Analytics for Android Apps

[This post is by Alexander Lucas, an Android Developer Advocate bent on saving the world 5 minutes. —Tim Bray]

With the addition of custom variables to the Mobile Analytics SDK for Android, it strikes me as a good time to cover something many of you might not have known was possible — using Google Analytics to easily track app usage. Using the mobile SDK is a handy way to get real data on how users interact with your Android apps. So today I'm going to explain how to track usage of your application with Google Analytics.

Prereqs Ahoy!

Before you take off running with this shiny new toy, there’s a few things you’ll need to set up first:

  • Download the mobile SDK. Download and installation instructions are available in the getting started section of the Mobile SDK docs, but the summarized version is:

    • Download the zip file from the download page

    • Put the libGoogleAnalytics.jar file in your project’s /libs directory

    • Be sure the following lines are in your AndroidManifest.XML file:
      <uses-permission android:name="android.permission.INTERNET" />
      <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

  • You’re going to need a Google Analytics account. Go to google.com/analytics and set up an account if you don’t already have one. Then set up a profile for your Android application. When you’re done you’ll see a javascript snippet to insert into your “site”. Copy the part that looks like UA-XXXXXXX-X. You’ll use this in the Android application to tell Analytics which profile the data is being sent for.

Get Tracking

Previous Google Analytics users are going to find a lot of this familiar. In fact, we’ve made a point of keeping the interface as familiar as possible.

First, get your tracker object, and initialize it using the UA code for the Analytics profile you want to track. It makes the most sense to do this in the onCreate() method for your activity main, so it only fires when your application starts up.

GoogleAnalyticsTracker tracker;
protected void onCreate(Bundle savedInstanceState) {
...
tracker = GoogleAnalyticsTracker.getInstance();
tracker.start(“UA-1234-1”, this);

}

The mobile SDK provides support for the 3 main types of data sent to the Google Analytics servers: Pageviews, events, and custom variables.

Pageviews

A pageview is a standard means to measure traffic volume to a traditional website. Given that this is going into an Android app and not a website, it’s going to be up to you to decide what a “pageview” means. Depending on the type of app, each Activity or different views within the same activity (for instance, different tabs within a TabActivity) could count as a pageview.

Whenever you want to trigger a pageview, call the trackPageView() method. It only takes one parameter, the URL you want a pageview counted towards.

tracker.trackPageView("/HomeScreen");

Pageviews make the most sense as full screen transitions, which in most cases will mean “one pageview per Activity.” Therefor it makes the most sense to put the call to trackPageView in the onCreate() method for each activity in your application. An exception would be if you were using a TabActivity, or other scenario where there were multiple full-screen transitions which all occurred within the same Activity, and conceptually mapped to seperate full-screen “pages” being viewed.

Events

In Analytics, events are designed to track user interaction to that doesn’t map to pageviews, like hitting play/pause/stop in a multimedia app. This maps very well to Android usage — Any form of interaction, from hitting certain buttons to adding/removing data from the datastore, can be tracked using Events.

Events are a little more complicated than pageviews, but just slightly. Instead of 1 parameter, you have 4: Category, Action, Label (optional), Value (optional).

To see how to make use of these, let’s imagine you had a media player application, and wanted to track how many times play, pause, and stop were clicked. The code would look like this:

   playButton.setOnClickListener(new OnClickListener() {
@Override
public void onClick(View v) {
...
tracker.trackEvent(
"Media Player", // Category
"Click", // Action
"Play", // Label
0); // Value
}
});

pauseButton.setOnClickListener(new OnClickListener() {
@Override
public void onClick(View v) {
...
tracker.trackEvent(
"Media Player", // Category
"Click", // Action
"Pause", // Label
0); // Value
});

stopEventButton.setOnClickListener(new OnClickListener() {
@Override
public void onClick(View v) {
...
tracker.trackEvent(
"Media Player", // Category
"Click", // Action
"Stop", // Label
currentVideo.getPositionInSeconds()); // Value
});

myMediaPlayer.setFinishedListener(new FinishedListener() {
@Override
public void onFinished(View v) {
...
tracker.trackEvent(
"Media Player", // Category
"Video Finished", // Action
"Stop", // Label
currentVideo.getLengthInSeconds()); // Value
});

Remember that in the Google Analytics web interface, this data is displayed hierarchically — For instance, if you click on Categories in the left nav, and then on “Media Player”, you’ll see a list of all the different possible values of “Action” which have happened in the “media Player” category. Clicking on “Click” will show all the labels which were sent in the Media Player category with an action of “Click”.

The 4th parameter, “value”, is optional, and behaves differently from the others. It’s meant to be cumulative; In this example, I’m sending the amount of video watched when a video is either stopped or allowed to finish. This is aggregated server-side, and when I go to look at my data I’ll be able to see the total time people have spent watching videos using my application.

Custom Variables

The new hotness! Custom variables are name-value pair tags that you can insert in your tracking code in order to refine Google Analytics tracking. The easiest way to think of this is as meta-data accompanying your pageviews and events. Using this metadata, it becomes easy to split off and look at segments of your data, much the same way you use labels in Gmail. One Android-specific example would be to have a “AppType” status with “Full” or “Lite” depending on whether the user has the full version of the app or not. You could then use the Analytics web interface to look at only the “Lite” users, and see how their usage / userbase differs from the “Full” segment. Custom variables are a ridiculously powerful analytical tool, but they’re also a deep topic. I heartily recommend giving the docs a once-through before implementing them in your Android application. Especially make sure to read the section on scoping. Twice. I’m mean it... I’ll wait.

There are 4 parameters in a custom variable: Index (1 to 5 inclusive), Name, Value, and Scope (Optional, defaults to Page Scope).

The place in your code where setCustomVar() will be called depends largely on what scope that variable will be:

  • Visitor scope: Call once the first time your application is run on a device. Don’t create any custom variables at the same index, or they will overwrite the first one. Useful for sending data about which version of the app is being used, what kind of phone, lite vs full version of the app, or anything that won’t change during the lifetime of the installation of that application.

  • Session scope: Call once at the beginning of every Activity startup. Will apply to all pageviews and events for the lifecycle of the activity, unless a different custom variable is created at the same index.

  • Page scope: Call right before trackEvent or trackPageView that the custom variable should apply to, every time that method is called. If no scope is specified, this is the default.

The call to set a custom variable will look like the following:

// Scopes are encoded to integers:  Visitor=1, Session=2, Page=3
tracker.setCustomVar(1, "Navigation type", "Button click", 3);

Choose a Dispatch Mode

In order to optimize for battery life, a request isn’t actually sent out to the server every time you fire a pageview or custom variable. Instead, all the pageviews, events, and their associated custom variables are stored in a local SQLITE database until they’re dispatched as a group to the server. You can set this up to happen one of two ways: Either have the dispatch occur automatically every n seconds, or manually when you call “dispatch” in code. The mode is chosen when you call the start method on your tracker.

Manual dispatch looks like this:

// No time increment sent as a parameter
tracker.start(“UA-1234-1”, this);

// Call this when you want to send the entire event queue to the server
tracker.dispatch();

The timed automatic dispatch looks similar, but sends an extra parameter (the number of seconds between dispatches). In timed dispatch, you never have to manually call dispatch.

// Dispatch all queued pagevies/events every 300 seconds (5 minutes)
tracker.start("UA-YOUR-ACCOUNT-HERE", 300, this);

It’s important to remember that Google Analytics uses the timestamp for when it receives your data, not when the actual pageview/event occurred. This can potentially lead to inaccurate Analytics data, since events can be sent on different days than when they occurred, so take care to dispatch regularly.

The end result

Let’s go back to that onCreate() method we used to instantiate the tracker earlier, and see what it looks like with all the pieces in place:

GoogleAnalyticsTracker tracker;

protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

tracker = GoogleAnalyticsTracker.getInstance();
tracker.start(“UA-1234-1”, this);

if(isFirstTimeRunningApplication()) {
tracker.setCustomVar(1, “App Type”, “Demo”, 1);
}
tracker.trackPageView("/HomeScreen");


}

How to look at all this data

There are two ways you can approach this. First, Google Analytics has a pretty snazzy web interface, which does a very good job of surfacing useful information for you. If you’re new to Analytics and don’t really know what you’re looking for yet, the web interface is a great way to explore your data and understand your users.

If you already have a strong idea of the questions you want to ask (app usage across versions of the Android platform, growth rates, time-in-app per demo user vs full user, how many people beat level 3 on their first try, etc), and just want to automate the asking, Google Analytics also has a swanky data export API, with client libraries to facilitate the querying of your data in Java, Python, JavaScript, and C#.

Abiding by the TOS

Google Analytics comes with its own TOS, and it’s important to read and abide by it. The important bit, especially since this will be used inside Android applications, is that you cannot send personally identifying information to Analytics servers. This is a big deal. It means, for instance, that a visitor-level custom variable cannot contain a phone number, first name, or email address. Less intuitively, but still important, it means that if this application is a client to a web application (say, CRM software or a shopping site), you also cannot store information in Analytics which can be combined with your own backend software to identify the user, such as user ID or a transaction ID identical to the one stored on your web backend.

Voice Search gets personal

When we launched Voice Search more than two years ago, we wanted it to “just work” right out of the box, without an initial setup process. And so, we built speech models broad enough to accommodate a wide variety of people, regardless of gender, age, and accents, or variations in pitch, pace, and other factors. But we always knew we could build a more accurate model by listening to your voice, and learning how you -- as a unique individual -- speak. So today we’re launching personalized recognition.

If you opt into personalized recognition, we begin to associate the recordings of the words that you ask us to recognize with your Google account. We then automatically use these words to build a speech model specifically for you. This speech model enables us to deliver greater recognition accuracy. Although subtle, accuracy improvements begin fairly quickly and will build over time.

The first time you use Voice Search, you’ll be presented with a dialog to turn on personalized recognition. Google takes your privacy seriously, so you can enable or disable personalized recognition at any time through the Google voice recognition settings on your phone. If you’d like to disassociate your voice recordings from your Google Account, you can do so through the Google Dashboard in the Speech section.

The personalized recognition functionality is currently available for English in the United States. We plan to support other countries and languages in the near future. To enable it, you must have Android 2.2 or higher, and download the latest version of the Voice Search app from Android Market. The new app also includes some improvements to name recognition and speed, especially over 3G and EDGE connections.

So go ahead and download the latest Voice Search app, and let’s get personal!

Scan this QR code to download:

Google Voice app now supports iPad & iPod Touch

(cross-posted from the Google Voice Blog)

Since we launched Google Voice for iPhone a few weeks ago, we’ve been hard at work to add a few improvements that didn’t make it into the first release.

At the top of the list was adding support for iPod Touch and iPad. Starting today, you can download a new version of Google Voice that lets you use all the features of the app on these devices, such as sending and receiving free text messages - except, of course, make cellular calls.

While you can’t use your iPod or iPad as a phone, you can use it to initiate Google Voice calls with your phones. We call this feature Click2Call. Simply click any ‘Call’ button in the Google Voice app on your iPod or iPad and then select which of your phones you want to ring. Google Voice will call your phone and then connect your call.


While we were at it, we also made a few other improvements to the app:
  • When you enable Push Notifications, we will automatically disable Text forwarding for you, so you won’t receive multiple notifications.
  • Want some quiet time? You can send all callers straight to voicemail by turning on Do not disturb in the Settings tab.
  • We made it easier for you to place calls from the address book by adding a dedicated Contacts button to the Dialer tab.
  • Sending text messages is now more streamlined since you don’t need to press the OK button anymore.
Bonus Tip: Tap and hold messages in your inbox to archive or delete them.

The Google Voice app is available to download from the Apple App Store today. You’ll need an iPhone, iPad, or iPod Touch with iOS 3.1 or later and a valid Google Voice account to use the app. At this time, Google Voice is available in the U.S. only.

你好, नमस्ते and bonjour to better mobile web Gmail

There are many ways to get your Gmail on your phone. The mobile webapp version of Gmail (which you can get to by going to gmail.com in your browser) is the best way to get the most Gmail features on your iPhone or Android-powered device. Features such as search, stars, labels and threaded conversations all work in the mobile webapp just as they do in the desktop Gmail experience. Today, we’re bringing the latest version of our HTML5 webapp to 44 new languages.



Before today, this new version was only available for U.S. English, but we’re now expanding to Arabic, Bulgarian, Catalan, Chinese (Traditional and Simplified), Croatian, Czech, Danish, Dutch, English (UK and American), Estonian, Filipino, Finnish, French, German, Greek, Hebrew, Hindi, Hungarian, Icelandic, Indonesian, Italian, Japanese, Korean, Latvian, Lithuanian, Malay, Norwegian (Bokmal), Polish, Portuguese (for both Portugal and Brazil), Romanian, Russian, Serbian, Slovak, Slovenian, Spanish (for both Spain and South America), Swedish, Thai, Turkish, Ukranian, Urdu and Vietnamese.

If your phone’s default language is one of those listed, go to gmail.com in your phone’s browser and the new interface will appear in your language automatically. We’ve been rolling these changes out, so some of you may have already seen them. You’ll get a bunch of new goodies including offline support, smart links (titles will appear in links for Google Maps, YouTube and Google Docs), the ability to add and remove labels, layout improvements and more—in addition to the existing features like starring, better threaded conversations and search.

This new version works for iPhones running iOS 2.2.1 and above, and all versions of Android. Go to gmail.com in the browser of your iPhone or Android-powered device to try it out, and if you have any feedback, let us know in our forum.

Posted by Scott Eblen, Product Manager

How to check your email from your phone (and 50 other things you might want to teach your parents)

My dad loves planning big family gatherings around the holidays. He always emails our extended family a few weeks early, and we’ll all plan out logistics in an email thread - food responsibilities, addresses, times-- everything. Logistics can get pretty crazy when it comes to the actual day of the event, and we’re rarely at a computer on that day. I always find that my dad starts to lose track of the million things in his email that he needs to remember.

If only my dad knew that he could check Gmail on his Android phone using either the built-in mail app or the web app. Then he could always keep track of his messages while on the go, especially during the busy holiday season.

To help my dad, and parents everywhere, a few of us at Google decided to create a website, TeachParentsTech.org, where “kids” of any age can send how-to videos to their moms, dads, uncles - everybody! Here’s a video I made that walks you through how to check email from your mobile phone.



To see more videos or to send someone a tech support care package of your own, visit TeachParentsTech.org.


Post content

Introducing the Google Latitude app for iPhone

“Where are you?”

Starting today, you’ll never again have to answer (or ask) that question when you’re on the go with your iPhone. With the new Google Latitude app for iPhone, you can see where your friends are and now, continuously share where you are – even in the background once you’ve closed the app.


Since launching last year, Latitude’s focus has always been on one goal: make it simple to stay in touch with friends and family by sharing where you are with each other. Simple setup. Simple sharing without fumbling for your phone. Now, you can use Latitude on your iPhone just like the more than 9 million people actively using it from Android, BlackBerry, Symbian, and Windows Mobile smartphones. Use the app to:
  • See where your friends are
  • Share your location continuously with whomever you choose
  • Contact friends by phone, text message, or email
  • Control your location and privacy



Watch the Latitude app for iPhone in action

You still get simple control over your privacy. Remember, Latitude is 100% opt-in. You must install the app and add friends (or accept requests) to start sharing your location. You can turn off background updating if you’d like and control the same privacy settings: share only city-level location, hide your location, or sign out of Latitude at any time. Learn more in the privacy tips video.

Though we released Latitude as a web application before the iPhone supported third party background applications, today’s Latitude app was built from the ground up using iOS 4’s new multitasking capability to support background updating. You’ll need iOS 4 and above on an iPhone 3GS or iPhone 4 to use the app.

Download Google Latitude now from the App Store in over 15 languages and 45 countries. It will be appearing in the App Store over the next day, but you can also find it directly now. Learn more in the Help Center or ask questions in the Help Forum.

Update (12/13/2010, 10:20am PST): The Google Latitude app will run on the iPhone 3GS, iPhone 4, iPad, and iPod touch (3rd/4th generation). However, background location updating is only supported on the iPhone 3GS, iPhone 4, and iPad 3G. We're continuing to work on expanding support to more devices.

New Gingerbread API: StrictMode

[This post is by Brad Fitzpatrick, an Android Software Engineer who worries unreasonably about responsiveness. —Tim Bray]

Back Story

One great thing about Google is “20% time”: spending 20% of your time working on projects outside your main focus area. When I joined Google, I bounced all over the place, often joking that I had seven 20% projects. One project I kept coming back to was Android. I loved its open nature, giving me access to do whatever I wanted, including opening my garage door when I approached my house on my motorcycle. I really wanted it to succeed but I worried about one thing: It wasn’t always super smooth. Animations would sometimes stutter and UI elements weren’t always immediately responsive to input. It was pretty obvious that things were sometimes happening on the wrong thread.

As a heavy SMS user, one of my 20% projects during the Cupcake (Android 1.5) release was speeding up the Messaging app and making it feel smoother. I got the app to a happy state and then continued bouncing between other 20% projects. When the Donut (Android 1.6) release came out, I noticed that a few of my Messaging optimizations had been accidentally broken. I was sad for a bit but then I realized what Android really needed was always-on, built-in, pervasive performance monitoring.

I joined the Android team full-time just over a year ago and spent a lot of time investigating Froyo performance issues, in particular debugging ANRs (those annoying dialogs you get when an application stalls its main thread’s Looper). Debugging ANRs with the tools at hand was painful and boring. There wasn’t enough instrumentation to find the causes, especially when multiple processes were involved (doing Binder or ContentResolver operations to Services or ContentProviders in other processes). There had to be a better way to track down latency hiccups and ANRs...

Enter StrictMode

“I see you were doing 120 ms in a 16 ms zone...”



StrictMode is a new API in Gingerbread which primarily lets you set a policy on a thread declaring what you’re not allowed to do on that thread, and what the penalty is if you violate the policy. Implementation-wise, this policy is simply a thread-local integer bitmask.

By default everything is allowed and it won’t get in your way unless you want it to. The flags you can enable in the thread policy include:

  • detect disk writes


  • detect disk reads


  • detect network usage


  • on a violation: log


  • on a violation: crash


  • on a violation: dropbox


  • on a violation: show an annoying dialog


In addition, StrictMode has about a dozen hooks around most of the places that hit the disk (in java.io.*, android.database.sqlite.*, etc) and network (java.net.*) which check the current thread’s policy, reacting as you’ve asked.

StrictMode’s powerful part is that the per-thread policies are propagated whenever Binder IPC calls are made to other Services or Providers, and stack traces are stitched together across any number of processes.

Nobody wants to be slow

You might know all the places where your app does disk I/O, but do you know all the places where the system services and providers do? I don’t. I’m learning, but it’s a lot of code. We’re continually working to clarify performance implications in the SDK docs, but I usually rely on StrictMode to help catch calls that inadvertently hit the disk.

Background on disks on phones

Wait, what’s wrong with hitting the disk? Android devices are all running flash memory, right? That’s like a super-fast SSD with no moving parts? I shouldn’t have to care? Unfortunately, you do.

You can’t depend on the flash components or filesystems used in most Android devices to be consistently fast. The YAFFS filesystem used on many Android devices, for instance, has a global lock around all its operations. Only one disk operation can be in-flight across the entire device. Even a simple “stat” operation can take quite a while if you are unlucky. Other devices with more traditional block device-based filesystems still occasionally suffer when the block rotation layer decides to garbage collect and do some slow internal flash erase operations. (For some good geeky background reading, see lwn.net/Articles/353411)

The take-away is that the “disk” (or filesystem) on mobile devices is usually fast, but the 90th percentile latencies are often quite poor. Also, most filesystems slow down quite a bit as they get more full. (See slides from Google I/O Zippy Android apps talk, linked off code.google.com/p/zippy-android)

The “main” Thread

Android callbacks and lifecycle events all typically happen on the main thread (aka “UI thread”). This makes life easier most of the time, but it’s also something you need to be careful of because all animations, scrolls, and flings process their animations by callbacks on the main thread.

If you want to run an animation at 60 fps and an input event comes in (also on the main thread), you have 16 ms to run your code reacting to that input event. If you take longer than 16 ms, perhaps by writing to disk, you’ve now stuttered your animation. Disk reads are often better, but they can also take longer than 16 ms, especially on YAFFS if you’re waiting for the filesystem lock that’s held by a process in the middle of a write.

The network is especially slow and inconsistent, so you should never do network requests on your main thread. In fact, in the upcoming Honeycomb release we’ve made network requests on the main thread a fatal error, unless your app is targeting an API version before Honeycomb. So if you want to get ready for the Honeycomb SDK, make sure you’re never doing network requests on your UI thread. (see “Tips on being smooth” below.)

Enabling StrictMode

The recommended way to use StrictMode is to turn it on during development, learn from it, and turn it off before you ship your app.

For example, in your application or component’s onCreate():

 public void onCreate() {
if (DEVELOPER_MODE) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork()
.penaltyLog()
.build());
}
super.onCreate();
}

Or, simply:

    public void onCreate() {
if (DEVELOPER_MODE) {
StrictMode.enableDefaults();
}
super.onCreate();
}

That latter form was specifically added so you can target pre-Gingerbread API versions but still easily enable StrictMode using reflection or other techniques. For instance, you could be targeting Donut (Android 1.6) but still use StrictMode if you’re testing on a Gingerbread device or emulator, as long as you use enough Reflection to call StrictMode.enableDefaults().

Watching StrictMode

If you’re using penaltyLog(), the default, just run adb logcat and watch the terminal output. Any violations will be logged to your console, slightly rate-limited for duplicate elimination.

If you want to get fancier, turn on penaltyDropbox() and they’ll be written to the DropBoxManager, where you can extract them later with

adb shell dumpsys dropbox data_app_strictmode --print

Tips on being smooth

In addition to Thread and java.util.concurrent.*, check out some of the Android APIs such as Handler, AsyncTask, AsyncQueryHandler, and IntentService.

Our Experience

During Android development we have a new “dogfood” build each day that the whole team uses. Throughout the development of Gingerbread we set up our daily dogfood builds to enable StrictMode logging and upload all found violations for analysis. Every hour a MapReduce job runs and produces an interactive report of all the event loop stalls, their stack traces (including cross-process ones), their latency percentiles, which processes/packages they appear in, etc.

Using the data from StrictMode we fixed hundreds of responsiveness bugs and animation glitches all across the board. We made performance optimizations in the Android core (e.g. system services and providers) so all apps on the system will benefit, as well as fixing up tons of app-specific issues (in both AOSP apps and Google apps). Even if you’re using Froyo today, the recent updates to GMail, Google Maps, and YouTube all benefited from StrictMode data collection gathered on Gingerbread devices.

Where we couldn’t automatically speed up the system, we instead added APIs to make certain patterns easier to do efficiently. For example, there is a new method SharedPreferences.Editor.apply(), which you should be using instead of commit() if you don’t need commit()’s return value. (It turns out almost nobody ever checks it.) You can even use reflection to conditionally use apply() vs. commit() depending on the user’s platform version.

Googlers who switched from Froyo to Gingerbread without seeing all the baby steps between were shocked at how much more responsive the system became. Our friends on the Chrome team then recently added something similar. Of course, StrictMode can’t take all the credit. The new concurrent garbage collector in Gingerbread also greatly reduces latency hiccups.

The Future

The StrictMode API and its capabilities will continue to expand. We have some good stuff lined up for StrictMode in Honeycomb but let us know what else you’d like to see! I’ll be answering questions on stackoverflow.com for questions tagged “strictmode”. Thanks!

Android Market Client Update

[This post is by Eric Chu, Android Developer Ecosystem. —Dirk Dougherty]

The Android Market engineering team has been hard at work on improving the Android Market experience for users and developers. Today, I’m pleased to announce a significant update to the Android Market client. Over the next two weeks, we’ll be rolling out a new Android Market client to all devices running Android 1.6 or higher.

This new Market client introduces important features that improve merchandising of applications, streamline the browse-to-purchase experience, and make it easier for developers to distribute their applications.

With a focus on improving discoverability and merchandising, we’ve introduced a new carousel on the home and category screens. Users can quickly flip through the carousel to view promoted applications and immediately go to the download page for the application they want. Developers have been very active in creating great Widgets and Live Wallpapers. To make it easier for users to find their favorites, we’re introducing two new categories for Widgets and Live Wallpapers. Applications that include Widgets and Wallpapers will be automatically added to those new categories. We’ll also be adding more categories for popular applications and games in the weeks ahead. In addition, the app details page now includes Related content, which makes it easier for users to quickly find apps of similar interest.




To streamline the browse-to-purchase experience, users can now access all the information about an application on a single page without the need to navigate across different tabs. We’re also introducing application content rating to provide users with more information about applications they are interested in. Since most users who request a refund do so within minutes of purchase, we will reduce the refund window on Market to 15 minutes. This change will be largely transparent to buyers, but will help developers manage their businesses more effectively.



To make it easier for developers to distribute and manage their products, we will introduce support for device targeting based on screen sizes and densities, as well as on GL texture compression formats. We are also increasing the maximum size for .apk files on Market to 50MB, to better support richer games.

With this release, we aimed to deliver features that are most requested by users and developers. However, we’re not done yet. We plan to continue to rapidly enhance Android Market for both users and developers and make it the best content distribution service for the Android ecosystem.

Please stay tuned as we continue to deliver new capabilities in the coming weeks and months.

Trailblazing in Portland

(Cross-posted and excerpted from the Hotpot Community Blog)

When we announced the availability of Hotpot last month, we knew from the beginning we were going to take a different approach to marketing the product and engaging with our users, both businesses and consumers.

To that end, we’re excited today to start testing this new approach by launching our first local marketing campaign in Portland, Oregon. Portland is a tech savvy, forward-thinking city with a history of innovation and some of the best coffee houses, microbreweries and parks in the country. Whether you know it as The City of Roses, Stumptown, P-Town, Rip City or just PDX, Portland’s thriving local business community and strong heritage of being a trailblazer made it a great choice for us to try something new.

So starting today and over the course of the next few months, we’ll be out and about in Portland. Here’s a taste of what’s in store:

Business Kits and Window Decals


Every day millions of people search on Google.com to find local businesses, and we want to make it seamless for standout businesses to get discovered online. To achieve this, we’ll be working directly with some of Portland’s top businesses to educate them about Google Places for business and all its benefits. In addition, to help these businesses spread the word, we’re providing owners with special Google Places Business Kits. These kits are a multi-flavored sampler of marketing materials that can help businesses get even more exposure, get them rated and reviewed online, and get more customers through their door. We’re already distributing these to some of Portland’s top businesses, but any business in Portland who has claimed their Place page can request a box.


A central part of the kit is the bright red “Recommended on Google” window sticker. This is not your ordinary sticker. Unlike others, this is an interactive sticker that has Near Field Communications (NFC) technology built right in, allowing people with cutting edge phones like Nexus S to simply touch their phones to the sticker to find out more information about the business. Suddenly stickers are cool again!

This is just the beginning and we’ll be doing a lot more in the upcoming months. For the latest and greatest of what we’re up to in Portland (and elsewhere), keep an eye out by staying up to date via the Hotpot Blog, and by following us on Twitter and liking us on Facebook.

Gmail for Android: better Priority Inbox support and improved compose

(Cross-posted on the Gmail blog.)

When we first released Gmail in Android Market back in September, we said that you’d be getting new stuff faster, and we meant it. After getting thousands of comments on that release, we made a bunch of updates based on your feedback and today we’re launching Gmail for Android 2.3.2.

Priority Inbox

First of all, you told us that you love Priority Inbox and expect much better support for it on your phone. Now you can see important messages in a new Priority Inbox view.

This view includes all important messages in your inbox, regardless of whether you’ve read them or not. You can archive and delete conversations or mark them unimportant from there. You’ll notice the importance markers you’re used to seeing in the desktop version of Gmail, and you can also change a conversation’s importance using the menu. To switch between inboxes or labels, try tapping on the current label.

Ever wanted to know that you got an important message without taking your phone out of your pocket? Now you can set up your phone to notify, vibrate, or ring on just your new important mail (check out Menu > Settings > Priority Inbox).

While Priority Inbox on your Android phone doesn’t have all the features offered in the desktop version of Gmail, we think this is a good start and plan to add even more functionality moving forward.


Improved Compose


Since our last Market update, we adopted a few features related to composing messages from the desktop version of Gmail. Many of you asked for a better way to switch between replying to the sender to replying to all. Now, you can easily switch between reply, reply all, and forward while composing your response.



If you moved to Gmail from another webmail provider and want to continue to send email from that address, now you can send from any address you’ve configured in the desktop version of Gmail.



In addition, you can now respond to messages in-line.



You won’t need to wait for Gingerbread to get these updates. This version of the Gmail app works for Android 2.2 (Froyo) and newer releases in most countries. (Not sure if your device is running the right version? Check here.) Get the update from Android Market (just scan the QR code below, or click here if you're on a phone) and check out the new Gmail. And don’t forget to send us your feedback from within the new version of the app (from your Inbox: Menu > More > About > Feedback).