See your location history dashboard and more with Google Maps 5.3 for Android

Today, we’re happy to announce Google Maps 5.3 for Android, which lets you see your Google Location History dashboard, check in at “home,” and add your own aspects for places when rating them.

Location History dashboard
If you’ve enabled Location History for Google Latitude, you’ve been able to visualize interesting trends in your location history with a personal dashboard at google.com/latitude on your computer. Now, you can also see your dashboard on your phone by tapping View location history from your Latitude profile. You’ll be able to see right on your phone how far you’ve travelled as well as an estimate of how much time you’ve spent at home, at work, or out.

If you haven’t yet, you can enable Location History from your computer or from Latitude’s Settings menu on your phone. Location History is 100% opt-in and is private to you and nobody else. You can always delete any of your location history from the Manage History tab or correct the estimated work and home locations from the dashboard on your computer.

View your location history dashboard from your Latitude profile on your phone and see estimates of where you’ve spent your time.

Check in at home
Now that you can see how much time you spend at “home”, you might want to let friends know when you’re there. Checking in at places using Latitude is another way to keep a history of places you’ve been and also lets you share when you’re there. I love letting friends and family know when I’m at a cafe or park, but sometimes I want them to know that I’m relaxing at home or made it back safely from a road trip. So now, I can start checking in at “home” in Latitude:

1. Check in from Latitude and tap “Home - Tap to set your location” at the bottom of the nearby places list if you don’t have one yet.
2. Use the estimated current address or enter in your home address yourself.
3. Once you’ve checked in at home once, “Home” will appear at the top of the list when you’re checking in near there.

Like Latitude and other check-ins, checking in at home is entirely opt-in. Your set “home” location is not searchable and only you can check in there. Just like any other check-in, you can choose with whom to share your home check-ins (along with your name and address info).

Add your own aspects for places
When you’re rating places on the go in Maps using Google Places with Hotpot, you could always quickly leave feedback on a specific aspect or characteristic of a place, such as the food or ambiance. Before, we’d automatically include aspects about places that were commonly mentioned in reviews. Now, you can add your own aspects for each place. So if you think a place has a beautiful view or great music, you can add it yourself and quickly share it with the world.

When rating places, you can add your own aspects like “music” for places and leave quick feedback.

To get started, update Google Maps from Android Market on devices with Android OS 1.6+ anywhere Google Maps and Latitude are already available.

Posted by Kenneth Leftin, Software Engineer, Google Maps for mobile team

Meow Me Now

Search using your location is extremely helpful while on the go. Today, we’re excited to announce Meow Me Now, a new feature that lets you find the kittens that are near you. You can find kittens either by searching for [kittens] on google.com on your Android or iOS device, or by using the Near Me Now drop-down feature on the Google homepage.




Voice search to locate nearby kittens will also work on Android devices, and iOS devices with the Google Search App, so try meowing into your phone to find the kittens near you.

Posted by Yusuke Tabata, cat herder

The IO Ticket Contest

When Google I/O sold out so fast, were kicking around ideas for how to get some of our ticket reserve into the hands of our favorite people: Dedicated developers. Someone floated the idea of a contest, so we had to pull one together double-quick. You can read the questions and first-round answers here.

We thought you would enjoy some statistics, mostly rounded-off:

• 2,800 people visited the contest page.

• 360 people tried answering the questions.

• 1 person got all six right.

• 200 people did well enough to get into Round 2.

• 70 people submitted apps.

• 38 of the apps worked well enough to be worth considering.

• 10 apps (exactly) got a “Nice” rating from the first-cut reviewer.

While we’re doing numbers, let’s investigate which of the Round-1 questions were hard. In decreasing order of difficulty, identified by correct answer, we find: Dalvik (97.5% correct), 160 (96%), Looper (58.5%), LLVM (57%), fyiWillBeAdvancedByHostKThx (43%), and PhoneNumberFormattingTextWatcher (19.5%).

So, our thanks to the people who put in the work, and a particular tip of the hat to the deranged hackers er I mean creative developers who built three particularly-outstanding apps:

First, to Kris Jurgowski, who pulled an all-nighter and wrote a nifty little app... on a Motorola CLIQ running Android 1.5! Next, to Heliodor Jalba, whose app had some gravity-warping extras and was less than 11K in size. And finally, to Charles Vaughn, whose app included a hilarious “Party Mode” that brought a smile to everyone’s face.

Stay connected to the market, wherever you are

Mobile phones are great for keeping in touch with the latest information, but when there’s a lot of data to look at, a small screen can be a drawback. For financial queries, where you might want to see stock quotes, the latest news, a market overview or portfolio details, we’ve just launched a new approach in Google search.

To try it out, go to google.com on your iPhone or Android-powered device (2.1 or later) and search for your favourite stock ticker symbol.

The first thing you’ll see is an interactive graph shown on a card - you can switch views to different date ranges by tapping on the buttons below the graph.

If you swipe the card from right to left, you’ll get the latest financial news for the company.

Swipe again for a market overview, and if you’re logged in to your Google account and have created a Google Finance portfolio, a further swipe will show a summary of your stock portfolio. Give it a try on your mobile device now to see how it works.

This feature is available in English with support for more languages coming soon. We hope you enjoy it and find it useful.

Posted by Yu Chen, Software Engineer and Robert Hamilton, Product Manager

Identifying App Installations

[The contents of this post grew out of an internal discussion featuring many of the usual suspects who’ve been authors in this space. — Tim Bray]

In the Android group, from time to time we hear complaints from developers about problems they’re having coming up with reliable, stable, unique device identifiers. This worries us, because we think that tracking such identifiers isn’t a good idea, and that there are better ways to achieve developers’ goals.

Tracking Installations

It is very common, and perfectly reasonable, for a developer to want to track individual installations of their apps. It sounds plausible just to call TelephonyManager.getDeviceId() and use that value to identify the installation. There are problems with this: First, it doesn’t work reliably (see below). Second, when it does work, that value survives device wipes (“Factory resets”) and thus you could end up making a nasty mistake when one of your customers wipes their device and passes it on to another person.

To track installations, you could for example use a UUID as an identifier, and simply create a new one the first time an app runs after installation. Here is a sketch of a class named “Installation” with one static method Installation.id(Context context). You could imagine writing more installation-specific data into the INSTALLATION file.

public class Installation {
    private static String sID = null;
    private static final String INSTALLATION = "INSTALLATION";

    public synchronized static String id(Context context) {
        if (sID == null) {  
            File installation = new File(context.getFilesDir(), INSTALLATION);
            try {
                if (!installation.exists())
                    writeInstallationFile(installation);
                sID = readInstallationFile(installation);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        }
        return sID;
    }

    private static String readInstallationFile(File installation) throws IOException {
        RandomAccessFile f = new RandomAccessFile(installation, "r");
        byte[] bytes = new byte[(int) f.length()];
        f.readFully(bytes);
        f.close();
        return new String(bytes);
    }

    private static void writeInstallationFile(File installation) throws IOException {
        FileOutputStream out = new FileOutputStream(installation);
        String id = UUID.randomUUID().toString();
        out.write(id.getBytes());
        out.close();
    }
}

Identifying Devices

Suppose you feel that for the needs of your application, you need an actual hardware device identifier. This turns out to be a tricky problem.

In the past, when every Android device was a phone, things were simpler: TelephonyManager.getDeviceId() is required to return (depending on the network technology) the IMEI, MEID, or ESN of the phone, which is unique to that piece of hardware.

However, there are problems with this approach:

• Non-phones: Wifi-only devices or music players that don’t have telephony hardware just don’t have this kind of unique identifier.

• Persistence: On devices which do have this, it persists across device data wipes and factory resets. It’s not clear at all if, in this situation, your app should regard this as the same device.

• Privilege:It requires READ_PHONE_STATE permission, which is irritating if you don’t otherwise use or need telephony.

• Bugs: We have seen a few instances of production phones for which the implementation is buggy and returns garbage, for example zeros or asterisks.

Mac Address

It may be possible to retrieve a Mac address from a device’s WiFi or Bluetooth hardware. We do not recommend using this as a unique identifier. To start with, not all devices have WiFi. Also, if the WiFi is not turned on, the hardware may not report the Mac address.

Serial Number

Since Android 2.3 (“Gingerbread”) this is available via android.os.Build.SERIAL. Devices without telephony are required to report a unique device ID here; some phones may do so also.

ANDROID_ID

More specifically, Settings.Secure.ANDROID_ID. This is a 64-bit quantity that is generated and stored when the device first boots. It is reset when the device is wiped.

ANDROID_ID seems a good choice for a unique device identifier. There are downsides: First, it is not 100% reliable on releases of Android prior to 2.2 (“Froyo”). Also, there has been at least one widely-observed bug in a popular handset from a major manufacturer, where every instance has the same ANDROID_ID.

Conclusion

For the vast majority of applications, the requirement is to identify a particular installation, not a physical device. Fortunately, doing so is straightforward.

There are many good reasons for avoiding the attempt to identify a particular device. For those who want to try, the best approach is probably the use of ANDROID_ID on anything reasonably modern, with some fallback heuristics for legacy devices.

Word of Mouth: Introducing Voice Search for Indonesian, Malaysian and Latin American Spanish

(Read more about the launch of Voice Search in Latin American Spanish on the Google América Latina blog)

Today we are excited to announce the launch of Voice Search in Indonesian, Malaysian, and Latin American Spanish, making Voice Search available in over two dozen languages and accents since our first launch in November 2008. This accomplishment could not have been possible without the help of local users in the region - really, we couldn’t have done it without them. Let me explain:

In 2010 we launched Voice Search in Dutch, the first language where we used the “word of mouth” project, a crowd-sourcing effort to collect the most accurate voice data possible.The traditional method of acquiring voice samples is to license the data from companies who specialize in the distribution of speech and text databases. However, from day one we knew that to build the most accurate Voice Search acoustic models possible, the best data would come from the people who would use Voice Search once it launched - our users.

Since then, in each country, we found small groups of people who were avid fans of Google products and were part of a large social network, either in local communities or on online. We gave them phones and asked them to get voice samples from their friends and family. Everyone was required to sign a consent form and all voice samples were anonymized. When possible, they also helped to test early versions of Voice Search as the product got closer to launch.

Building a speech recognizer is not just limited to localizing the user interface. We require thousands of hours of raw data to capture regional accents and idiomatic speech in all sorts of recording environments to mimic daily life use cases. For instance, when developing Voice Search for Latin American Spanish, we paid particular attention to Mexican and Argentinean Spanish. These two accents are more different from one another than any other pair of widely-used accents in all of South and Central America. Samples collected in these countries were very important bookends for building a version of Voice Search that would work across the whole of Latin America. We also chose key countries such as Peru, Chile, Costa Rica, Panama and Colombia to bridge the divergent accent varieties.

As an International Program Manager at Google, I have been fortunate enough to travel around the world and meet many of our local Google users. They often have great suggestions for the products that they love, and word of mouth was created with the vision that our users could participate in developing the product. These Voice Search launches would not have been possible without the help of our users, and we’re excited to be able to work together on the product development with the people who will ultimately use our products.

Posted by Linne Ha, International Program Manager, Google Voice Search

In-app Billing Launched on Android Market

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

Today, we're pleased to announce the launch of Android Market In-app Billing to developers and users. As an Android developer, you will now be able to publish apps that use In-app Billing and your users can make purchases from within your apps.

In-app Billing gives you more ways to monetize your apps with try-and-buy, virtual goods, upgrades, and other billing models. If you aren’t yet familiar with In-app Billing, we encourage you to learn more about it.

Several apps launching today are already using the service, including Tap Tap Revenge by Disney Mobile; Comics by ComiXology; Gun Bros, Deer Hunter Challenge HD, and WSOP3 by Glu Mobile; and Dungeon Defenders: FW Deluxe by Trendy Entertainment.

To try In-app Billing in your apps, start with the detailed documentation and complete sample app provided, which show how to implement the service in your app, set up in-app product lists in Android Market, and test your implementation. Also, it’s absolutely essential that you review the security guidelines to make sure your billing implementation is secure.

We look forward to seeing how you’ll use this new service in your apps!