Find your polling place and follow the US Election on the go

The United States midterm election is on Tuesday, November 2, and we encourage all eligible US citizens to get out and vote. We’ve made it easy to find your polling place and follow election news by visiting our Election Center mobile site at m.google.com/elections on your Android-powered phone or iPhone.

Enter the address where you’re registered to vote, and we’ll show you a Google Map of your polling place. The Election Center site also has information about candidates running for office in your area.

So come Tuesday, let your mobile phone guide you to your polling place, and let sanity guide your vote!

Posted by Ryan Pollock, Product Marketing Manager

New in Google Maps for Android: Updated reviews, search filters, and Latitude real-time updating

Lately, we’ve been working on giving you even better ways to find nearby places with Google Maps for Android, such as the Places icon and rich Place pages. Today, we are launching Google Maps 4.6 with a new design for Place page reviews, more options to filter search results, and a Google Latitude real-time updating option.

Place page reviews
Now, you’ll see that Place pages on Android Maps share the same new design for displaying reviews as used by Place pages on your computer. You can see:

• “Reviews from around the web” for highlighting sites that have high-quality reviews about the place.
• “Reviews from Google users” for reviews posted directly to Google Maps by other users

Filter search results
Of course, you’ll first need to narrow down which Place page reviews to check out. In addition to distance and ratings, you can also filter results for some searches by:

• Open now
• Neighborhood
• Related searches

Find the right place with the updated reviews section (left) or search results filters (right).

Google Latitude real-time updating
In Latitude, you can also choose an experimental “Real-time updating” option from an individual Latitude friend’s profile page to help meet up with them by temporarily seeing faster location updates (friends must have Maps 4.6 and Android 2.2+).

Get Google Maps 4.6 for Android 1.6 and above everywhere Maps is already available. Just search for Google Maps in Android Market (or tap here from your phone).

Visit our Help Center to learn more or tell us your feedback and questions in our Help Forum.

Posted by Michael Siliski, Product Manager, Google Mobile Team

Bring Your Phone to Work Day: Managing Android Devices With Google Apps

(Cross-posted and excerpted from the Official Google Enterprise Blog)

With over 200,000 devices activated each day, Android is seeing rapid adoption, and today we are launching new administrative controls that make it possible to securely manage these devices in the Google Apps environment. With this launch, Google Apps provides a comprehensive mobility solution for all major mobile platforms. You can manage most mobile devices right from the browser, without having to deploy dedicated servers.

Many Android devices feature tight integration with Google Apps, including native applications for Gmail, Google Talk, and Google Calendar, as well as mobile access to Google Docs. Now any employee with an Android device running version 2.2 - personal or company-issued - can access their corporate information while allowing administrators to enforce data security policies such as:

• Remotely wipe all data from lost or stolen mobile devices
• Lock idle devices after a period of inactivity
• Require a device password on each phone
• Set minimum lengths for more secure passwords
• Require passwords to include letters and numbers

When the employee leaves the company, the administrator can withdraw access to corporate info, which allows the employee to continue to use their device if it’s their own

These policies can be enforced on devices that have installed the Google Apps Device Policy application, which will be available from Android Market in the next few days. They will be available free to all Google Apps Premier and Education Edition customers in the next few days, and can be accessed from the 'Mobile' tab under 'Service Settings' in the Google Apps control panel.

To learn more about these updates in mobile device management for Google Apps, join us for a live webcast with Mayur Kamat, Google Apps Product Manager, on November 10, 2010 at 9 a.m. PDT / 12 p.m. EDT / 6 p.m. GMT. Register now

Posted by Amit Singh, Vice President of International Sales, Google Enterprise

Gmail in mobile Safari: now even more like a native app

Go to gmail.com from your iPhone and you’ll notice two improvements we’ve rolled out over the past few weeks. First, scrolling is snappier: the speed of scrolling reflects the speed of your swipe gesture. This is helpful for long conversations where a few quick flicks will get you to the information you need much faster than before. Second, the toolbars stay on screen while you’re scrolling rather than moving down into view after each scroll. Being able to access your toolbars from any point on the page should make it easier to triage your email and move around the app.

If you use Gmail in your mobile browser a lot, you may have noticed that we recently tried several different variations of these buttons. We‘ve iterated on the design and made improvements based on your feedback. If you have more suggestions, please post them in our forum, or if you use Twitter, mention #gmailmobile and we'll take a look. If you’re a developer and are interested in learning about the Javascript and HTML techniques we used to do this, we’ll post an article to code.google.com/mobile in the coming weeks.

You can see these improvements by visiting gmail.com from the browser of iPhone and iPod touch devices running iOS4 (English-only for now). And if you like Gmail in mobile Safari, make getting to it easier by tapping the “+” at the bottom of the screen and then “Add to Home Screen.” (Don’t see the new changes yet? Try clearing your cache and refreshing the page.)

Update, 12/8/10 9:10am PST: We promised you a code article. Here it is!

Posted by Brett Lider, User Experience Designer

Voice Search in Russian, Polish, Czech and Turkish

Over the past few weeks we have launched Voice Search in four new languages: Russian, Polish, Czech and Turkish. Try speaking queries like “концерты Юлии Савичевой” (tour dates for Yulia Savicheva), “przepis na pierogi” (recipes for pierogi), “obrázky Hradčan” (pictures of the Prague castle), or “istanbul hava durumu” (weather in Istanbul). Note that you can only speak one language into the app at any time and that you’ll need to change your language setting first.

Voice Search is often preloaded on new Android devices. In that case, all you have to do is press and hold the search button and then speak your query. If you have an Android (2.0 or higher) phone but don’t have Voice Search installed, download the “Voice Search” app from Android Market. If you own an iPhone or other smartphone, you can download Google Mobile App with Voice Search from m.google.com

Posted by Amir Mané, Product Manager of Google Speech Technologies

Improving App Quality

[This post is by Roman Nurik, who is passionate about icons. —Tim Bray]

With thousands of new apps being published in Android Market every week, it’s becoming more and more important to proactively work at breaking through the clutter (hooray for marketing jargon!). One way of improving your app’s visibility in the ecosystem is by deploying well-targeted mobile advertising campaigns and cross-app promotions. However, there’s another time-tested method of fueling the impression-install-ranking cycle: improve the product!

A better app can go a very long way: a higher quality app will translate to higher user ratings, generally better rankings, more downloads, and higher retention (longer install periods). High-quality apps also have a much higher likelihood of getting some unanticipated positive publicity such as being featured in Android Market or social media buzz.

The upside to having a higher-quality app is obvious. However, it’s not always clear how to write a so called ‘better app.’ The path to improving app quality isn’t always well-lit. The term ‘quality’, and its close cousins ‘polish’ and ‘fit and finish’ aren’t always well-defined. In this post, we’ll begin to light the path by looking at a couple of key factors in app quality, and furthermore, look at ways of improving your app along these dimensions.

Listen to your users

Given that pretty much any measure of the ‘success’ of an app involves user-related metrics such as number of downloads, daily actives, retention rates, etc., it’s a good idea to start thinking of your app’s quality as it relates back to your users.

The most obvious way to listen to users is by reading and addressing comments on your app in Android Market. Although the comments aren’t always productive or constructive, some will provide valuable insight on aspects of your app that you may not have consciously considered before. It’s important to remember that users have the opportunity to change their ratings and comments about an app as much as they’d like.

Now, since Android Market doesn’t currently provide a bidirectional communication medium for developers and their users, you should set up your own support and discussion destination(s). There are some great support tools out there that can put you in touch with your users directly such as Google Groups, Zoho Discussions, getsatisfaction.com and uservoice.com. Once you get set up with such a tool, make sure to fill in the support link in your Android Market listing -- users do click through to these.

Another way to better listen to your users is by having a public beta or trusted tester program. It’s crucial to have some amount of real user testing before releasing something in Android Market. Fortunately, you can distribute your apps to users outside of Market via a website; this website can require a login or be publicly accessible — it’s entirely up to you. Take advantage of this opportunity by offering your next planned update to some early adopters, before submitting to Market. You’ll be surprised by how many little, yet impactful, improvements can come out of crowd-sourced, real-user testing.

Improve stability and eliminate bugs

I won’t go into detail about why this is important, because hopefully it’s obvious. And hopefully you’ve been reading this blog and following the best practices outlined in previous posts, so you have a solid idea on how to improve in this arena.

One noteworthy and yet relatively underused tool for catching stability issues like crashes, is the UI/Application Exerciser Monkey (aka Monkey). Monkey will send random UI events to your app’s activitie, allowing you to trigger user flows that can uncover stability problems.

Also, with the new error reporting features in Android 2.2, users now have the ability to report application crashes to developers. These show up in aggregate in the Android Market developer console. Make sure to read these reports and act on them appropriately.

Lastly, keep an external bug and feature request tracker. This will enable your users to engage with the app at a closer level, by following features and bugs that affect them. User frustration with app problems can be effectively managed with diligent issue tracking and communication. Some of the community support tools listed above offer issue tracking features, and if your project is open source, most popular repository hosting sites such as Google Code and GitHub will offer this as well.

Improve UI Responsiveness

One sure-fire way to tick off your users is to have a slow UI. Research has shown that speed matters... for any interface, be it desktop, web, or mobile. In fact, the importance of speed is amplified on mobile devices since users often need their information on the go and in a hurry.

As Brad Fitzpatrick mentioned in his Google I/O 2010 talk, Writing Zippy Android Apps, you can improve your apps’s UI responsiveness by moving long-running operations off the application’s main thread. See the talk for detailed recommendations and debugging tips.

One way to improve UI performance is to minimize the complexity of your layouts. If you open up hierarchyviewer and see that your layouts are more than 5 levels deep, it may be time to simplify your layout. Consider refactoring those deeply nested LinearLayouts into RelativeLayout. As Romain Guy pointed out in his World of ListView talk at Google I/O, View objects cost around 1 to 2 KB of memory, so large view hierarchies can be a recipe for disaster, causing frequent VM garbage collection passes which block the main (UI) thread.

Lastly, as Tim pointed out in Traceview War Story, tools like traceview and ddms can be your best frends for improving performance by profiling method calls and monitoring VM memory allocations, respectively.

More resources:

• Designing for Performance




• Designing for Responsiveness

Improve usability

I’ll say it again here, listen to your users! Ask a handful of real Android device users (friends, family, etc.) to try out your application and observe them as they interact with it. Look for cases where they get confused, are unsure how to proceed, or are surprised by certain behaviors. Minimize these cases by rethinking some of the interactions in your app, perhaps working in some of the user interface patterns the Android UI team discussed at Google I/O.

In the same vein, two problems that currently plague Android user interfaces are small tap targets and overly small font sizes. These are generally easy to fix and can make a big impact. As a general rule, optimize for ease of use and legibility, while minimizing, or at least carefully balancing, information density.

Another way to incrementally improve usability, based on real-world data, is to implement Analytics throughout your app to log usage of particular sections. Consider demoting infrequently used sections to the options menu, or removing them altogether. For oftenly-used sections and UI elements, make sure they’re immediately obvious and easily accessible in your app’s UI so that users can get to them quickly.

Lastly, usability is an extensive and well-documented subject, with close ties to interface design, cognitive science, and other disciplines. If you’re looking for a crash-course, start with Donald Norman’s The Design of Everyday Things.

Improve appearance and aesthetics

There’s no substitute for a real user interface designer — ideally one who’s well-versed in mobile and Android, and ideally handy with both interaction and visual design. One popular venue to post openings for designers is jobs.smashingmagazine.com, and leveraging social connections on Twitter and LinkedIn can surface great talent.

If you don’t have the luxury of working with a UI designer, there are some ways in which you can improve your app’s appearance yourself. First, get familiar with Adobe Photoshop, Adobe Fireworks, or some other raster image editing tool. Mastering the art of the pixel in these apps takes time, but honing this skill can help build polish across your interface designs. Also, master the resources framework by studying the framework UI assets and layouts and reading through the new resources documentation. Techniques such as 9-patches and resource directory qualifiers are somewhat unique to Android, and are crucial in building flexible yet aesthetic UIs.

The recently-published Android UI Design Tips slide deck contains a few more best practices for your consideration.

Deliver the right set of features

Having the right set of features in your app is important. It’s often easy to fall into the trap of feature-creep, building as much functionality into your app as possible. Providing instant gratification by immediately showing the most important or relevant information is crucial on mobile devices. Providing too much information can be as frustrating (or even more so) than not providing enough of it.

And again, listen to your users by collecting and responding to feature requests. Be careful, though, to take feature requests with grains of salt. Requests can be very useful in aggregate, to get a sense of what kinds of functionality you should be working on, but not every feature request needs to be implemented.

Integrate with the system and third-party apps

A great way to deliver a delight user experience is to integrate tightly with the operating system. Features like app widgets, live folders, global search integration, and Quick Contacts badges are fairly low-hanging fruit in this regard. For some app categories, basic features like app widgets are par for the course. Not including them is a sure-fire way to tarnish an otherwise positive user experience. Some apps can achieve even tighter OS integration with the new contacts, accounts and sync APIs available in Android 2.0 and later. A few sample apps that show how to use these APIs are SampleSyncAdapter (bundled with the SDK samples) and JumpNote.

Third-party integrations can provide even more user delight and give the user a feeling of device cohesiveness. It’s also a really nice way of adding functionality to your app without writing any extra code (by leveraging other apps’ functionalities). For example, if you’re creating a camera app, you can allow users to edit their photos in Photoshop Express before saving them to their collection, if they have that third-party application installed. More information on this subject is available in the Can I Use this Intent? article.

More resources:

• Designing for seamlessness

Pay attention to details...

One particular detail I’ll call out is in icon quality and consistency. Make sure your app icons (especially your launcher icon) are crisp and pixel-perfect at all resolutions, and follow the icon guidelines, at least in spirit if not in letter. If you’re having trouble or don’t have the resources to design the icons yourself, consider using the new Android Asset Studio tool (a project I’ve recently open-sourced) to generate a set.

...and more...

Along with this blog, make sure to follow @AndroidDev on Twitter — we’re constantly collecting and sharing tips and tricks on Android application development that you won’t always find anywhere else. And of course, don’t be afraid to ask questions in our support forums on Stack Overflow and Google Groups.

Thanks for reading!

Traceview War Story

I recently took my first serious look at Traceview, and it occurred to me, first, that there are probably a few other Android developers who haven’t used it and, second, that this is an opportunity to lecture sternly on one of my favorite subjects: performance improvement and profiling. This is perhaps a little bit Android-101; If you already know all about Traceview, you can stop here and go back to coding.

Making Apps Fast

Here’s a belief that I think I share with most experienced developers: For any app that is even moderately complex, you’re not smart enough to predict what the slow parts are going to be, because nobody is smart enough to predict where software bottlenecks will turn up.

So the smart way to write a fast app is to build it in the simplest way that could possibly work, avoiding egregiously-stupid thing like order-N-squared algorithms and doing I/O on the Android UI thread. Who knows, it might be fast enough, and then you’re done!

If it isn’t fast enough, don’t guess why. Measure it and find out, using a profiler. Actually I’ve been known to do this, when backed into a corner, using things like System.err.println("Entered at" + System.currentTimeMillis()); Fortunately, Android comes with a reasonably decent profiler, so you don’t have to get ugly like that.

Case Study: LifeSaver 2

I have this little utility in Android Market called LifeSaver 2, the details are on my personal blog. At one point, it reads the SMS and phone-call logs out of the system and persists them in a JSON text file on the SD card. Since this is kind of slow, it shows a nice dynamic progress bar. It occurred to me to wonder why it was kind of slow to write a few hundred records into a text file on a device that, after all, has a gigahertz processor.

Somebody who foolishly disregarded my advice above might assume that the slowdown had to be due to the ContentProvider Cursor machinery reading the system logs, or failing that, the overhead of writing to the SD card. A wiser person would instrument the code and find out. Let’s do that.

Turning On Tracing

I went into Saver.java and bracketed the code in its run() method like so:

       public void run() {

            android.os.Debug.startMethodTracing("lsd");

            // ... method body elided

            android.os.Debug.stopMethodTracing();
        }

The first call turns tracing on, the argument "lsd" (stands for Life Saver Debug, of course) tells the system to put the trace log in /sdcard/lsd.trace. Remember that doing this means you have to add the WRITE_EXTERNAL_STORAGE permission so you can save the trace info; don‘t forget to remove that before you ship.

[Update:] Android engineer Xavier Ducrohet writes to remind me: “DDMS has a start/stop profiling button in the ‘device view’. Upon clicking stop it launches TraceView with the trace file. This is not as fine grained as putting start/stopMethodTracing in your code but can be quite useful. For VMs earlier than froyo, the permission is required as well (DDMS basically automate getting the trace from the sd card and saving it locally before calling traceview). For Froyo+ VMs, the VM is able to send the trace file through the JDWP connection and the permission is not needed anymore (which is really useful).” Thanks, Xav!

Then you run your app, then you copy the output over to your computer, and fire up Traceview.

540> adb pull /sdcard/lsd.trace
541> traceview lsd

At this point, you will have noticed three things. First, turning tracing on really slows down your app. Second, the tracefile is big; in this case, 8.6M for a run that took like four seconds. Third, that traceview looks pretty cool.

The bars across the top show the app’s threads and how they dealt out the time; since the Nexus One is single-threaded CPU, they have to take turns. Let’s zero in on one 100-msec segment.

The top line is where my app code is running (the red segment is GC happening), the middle line is the UI thread and the bursts of activity are the ProgressBar updating, and I have no idea what the third thread, named HeapWorker, does, but it doesn’t seem a major contributor to the app’s runtime, so let’s ignore it.

The bottom of the screen is where the really interesting data is; it shows which of your methods burned the time, and can be sorted in a bunch of different ways. Let’s zero in on the first two lines.

Translated into English, this tells us that the top-level routine consumed 100% of the time if you include everything it called (well, yeah), but only 0.9% of the time itself. The next line suddenly starts to get real interesting: java.io.PrintStream.println(Object) and whatever it calls are using 65.2% of the app’s time. This is the code that writes the JSON out to the SD card. Right away, we know that apparently the task of pulling the data out of the phone’s ContentProviders doesn’t seem to be very expensive; it’s the output that’s hurting.

Can we conclude that the app is limited by the sluggish write performance of the SD card? Let’s drill down, which is done in the most obvious point-and-click way imaginable.

Ooh, there’s a nasty surprise. Of course, println calls (in effect) toString() on all its arguments. It looks like turning the arguments to strings is taking over half the time, before it even dispatches from println(Object) to println(String).

I’ll skip the step of drilling down into println(String) but it does suggest that yes, there is some slow I/O happening there, to the SD card. But let’s look inside that String.valueOf() call.

There’s your smoking pistol. It turns out that org.json.JSONObject.toString() is what we professional programmers call a, well, this is a family-friendly operation so I won’t go there. You can poke around inside it, but it’s just depressing.

What you can do, however, is sort all the routines by their “Exclusive” times, as in the number of CPU circles burned right there in the routine. Here are all of them that use 1% or more of the total execution time.

There’s a little bit of GC and Android framework View-wrangling stuff in there, but the display is dominated by org.jason and java.lang.StringBuilder code.

The Conclusion

The real conclusion is that in the case of this app, I actually don’t care about the performance. A user runs it a grand total of two times, once on the old phone and once on the new phone, and it’s got lots of eye candy, so I just don’t think there’s a problem.

If I did want to speed this up, it’s obvious what to do. First, either stop using JSON, or find a cheaper way to serialize it. Second, do fewer println() calls; glom the data together in one big buffer and just blast it out with a single I/O call. But, and here’s the key point, if I’d guessed where the bottlenecks were, I’d have been wrong, mostly.

Traceview is a nice tool, and if you don’t already know it, you owe it to yourself to learn it.

The Five Steps to Future Hardware Happiness

[This post is by Reto Meier AKA @retomeier, who wrote the book on Android App development. —Tim Bray]

Two questions I regularly get asked are “Why isn’t my app visible on the Market on the (insert device name here)?” and “How can I prepare for GoogleTV and Android tablets?” If you care about how broadly your app is available, pay attention now. Seriously. I don’t want to hear anyone telling me they weren’t told. [Seems a little combative? -Ed. Take it up a notch! -RM]

By now you’ve probably heard of Google TV, the Samsung Galaxy Tab, and the Dell Streak. These are only the vanguard — Android is quickly moving to hardware that is increasingly different from the smartphone devices we’re used to. The variations in hardware — including lack of features like GPS, accelerometers, and video cameras — means it’s time for you to think about what hardware your app needs, and what it can function without.

To make life easier every API includes a FEATURE_* constant. To control your app’s availability on the Android Market, you specify the features required for your app to work. I’d like to encourage you to add manifest Feature nodes for every API you use, specifying them as optional, or not, as appropriate using a manifest uses-feature nodes as shown below:

<uses-feature android:name="android.hardware.microphone"
              android:required="true"/>

Market won’t be inferring any future API features

My earlier post on future proofing your apps describes a process of feature inferring that used your app’s permissions to help us ensure apps were only visible on the appropriate hardware.

This process has evolved over time. From now on Market won’t be inferring future API features and we have no way to infer some previously available APIs (eg. sensors). As a result you’ll need to specify your mandatory and optional feature requirements — or risk your app either breaking or not being available for some users.

The 5 steps to future hardware happiness

1. Specify a uses-feature node for every API feature used by your app. This forces you to think about what your app uses, allowing you to:

2. Decide which features are necessary for your app to be useful and mark those featured with the attribute required=true. This lets Market hide your app from any device that doesn’t support the hardware features your app requires.

   <uses-feature android:name="android.hardware.telephony"
              android:required="true"/>

3. For features that aren’t strictly required, set required=false.

   <uses-feature android:name="android.hardware.bluetooth"
              android:required="false"/>

4. Then go in to your code and find where you have used the optional features. Use the hasSystemFeature method from the PackageManager to determine if the hardware is available and provide alternative paths for your code as appropriate.

   PackageManager pm = getPackageManager();
boolean hasCompass = pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS);

5. Now you can sleep soundly in the knowledge that no matter what variation in Android compatible hardware comes to market, your app will always (and only) be available on those it supports.

You can find more details on how the Android Market uses filters to determine whether to show your application to a user who is browsing or searching for applications on a given device at the Market Filters page on the Android Developer Site.

Android Market New Country Roll-out Details

[This post is by the Android Market team. — Tim Bray]

Last week, we announced that over the next two weeks, users in 18 additional countries would gain the ability to purchase paid apps from Android Market. Effective today, users can now see paid apps in Argentina, Belgium, Brazil, Czech Republic, Denmark, Finland, Hong Kong, India, Ireland, Israel, Mexico, Norway, Poland, Portugal, Russia, Singapore, Sweden, and Taiwan.

For users to make a purchase of paid apps in these countries, they must have the latest Android Market client, which we have started to make available as a self-update and should reach all users within the next few days. This is a silent update; users will not see a notification and will not be prompted to do anything. If you want to accelerate the self-update process, launch Android Market, navigate back to the Home screen, and after 5-10 minutes, relaunch it. For more details, please refer to the Help Center.

No action is necessary if you have targeted your paid apps to be available to “All Locations” and would like to launch in these additional countries. If you have not selected “All Locations” and would like to target these additional countries, or if you have selected “All Locations” and do not want to launch your apps in these additional buyer countries, please visit the Android Market publisher site to make the necessary adjustments.

An easier way to use Google Latitude on your computer

We’re happy to introduce an easier way to use Google Latitude from your computer at google.com/latitude. You can now see where your friends are, start using Latitude apps, and share your location all from one place when you’re at your computer.

Find your friends
We launched Latitude with a desktop iGoogle gadget to help you stay in touch with friends and family that may not have a smartphone. We’ve since learned that a desktop experience is important to you even if you’re already using Latitude on your phone. Today, you can now visit a dedicated site that makes it easier than ever to use Latitude when you’re already on your computer. From the Friends tab, you can:

• See where your friends are on Google Maps
• Add friends and accept sharing requests
• Control your privacy settings

Do more with Latitude
You’ll also now find Latitude and Latitude apps together in one place. After browsing your friends list, go to the History or Apps tabs to turn on optional Latitude apps such as:

• Google Location History (Beta) to see your personal history dashboard
• Google Location Alerts to get nearby friend alerts
• Google Talk Location Status to post your location in your chat status
• Google Public Location Badge to publish your location on your blog or site

Share your location
Just like on your phone, you can choose to share your location with friends and family from your WiFi-enabled computer. Before you can share your location, you’ll need to first give Latitude permission to access your location when prompted by your supported browser. You can always change your browser or Latitude privacy settings later. Learn more in the Help Center.

To get started, go to google.com/latitude on your computer. If you’re new to Latitude, you can then start on your phone by sending yourself a text message or choose to start on your computer.

Posted by Kenneth Leftin, Software Engineer, Google Mobile Team

Open your eyes: Google Goggles now available on iPhone in Google Mobile App

Searching with Google on your mobile phone can be an eye-opening experience. Now your phone’s camera can even help to find out more about the world around you.

Back in December we introduced Google Goggles on Android: it lets you search by taking pictures. Today, we’re excited to announce that Goggles is now a feature of Google Mobile App for iPhone. Google Mobile App already lets you speak your queries, and it can also use your phone’s location to give you more relevant search results.

In the new version of Google Mobile App just tap on the camera button to search using Goggles. Goggles will analyze the image and highlight the objects it recognizes -- just click on them to find out more. You can see how this works in this short video:



Computer vision is a hard problem and Google Goggles is still a Labs product. It works well for things such as landmarks, logos and the covers of books, DVDs and games. However, it doesn’t yet work for some things you might want to try like animals, plants or food.

Google Mobile App with Google Goggles is now available in the Apple App Store. Just search for “Google Mobile App” and download the latest version - it’s free. It will gradually be appearing in all App Stores around the world starting from today.

Goggles is enabled only for English-speaking users, and since it requires an auto-focusing camera it is supported only on iPhone 3GS and iPhone 4 running iOS 4 or above. Visit our Help Center to learn more or send us your feedback and questions in our Help Forum.

So step away from your computer, get your Goggles on, and search the world around you.

Posted by Milan Broum, Software Engineer, Google Mobile Team

Car Home for Android Gets Personal

Car Home for Android turns your Android phone into a better driving companion by providing you with quick access to key applications on the go: GPS navigation, voice-activated commands, contacts, and more. Today, we’re releasing a new version of Car Home for Android (Update: currently for Nexus One and Motorola Droid, only) which makes it easier to customize Car Home to get the information you need faster.

Now, you can also quickly customize the shortcuts to personalize Car Home with one-touch access to apps and information on your phone. Just select one of the icons marked “Add shortcut” to start creating your own shortcuts. You can also drag-and-drop or remove shortcuts by long pressing any of them.

You can launch Car Home by opening the app directly from your phone or docking your phone in a car dock, and now you can automatically switch to Car Home when your phone pairs with any Bluetooth™ device. Simply select “Settings” from the Car Home screen and select which of your paired Bluetooth™ devices you want to automatically trigger Car Home.

Want to customize Car Home even more? You can now set your own wallpaper for Car Home. Just select “Settings” in Car Home and choose a wallpaper that fits your tastes. You can also customize the color of the shortcut icons to really make the Car Home experience your own.

We’ve also made it simpler for Android developers to modify their existing applications to be compatible with Car Mode. Apps which support Car Mode will show up in a “Car applications” category so they can easily be identified by you and added as a shortcut.

The new version of Car Home for Android is available for Android 2.2. You can get the update from Android Market by searching for “Car Home” in Android Market or tap here on your Android device.

Don’t forget, while your Android-powered companion can assist you while you drive, please keep your eyes on the road and drive safely at all times!

Update 10/1/10 10:28 PST: The new Car Home is available for Nexus One and Motorola Droid. Visit our Help Center to learn more or send us your feedback and questions in our Help Forum.

Posted by Markus Mühlbauer, Manager Engineering & Product, Google Automotive