Android 3.0 Platform Preview and Updated SDK Tools

Android 3.0 (Honeycomb) is a new version of the Android platform that is designed from the ground up for devices with larger screen sizes, particularly tablets. It introduces a new “holographic” UI theme and an interaction model that builds on the things people love about Android — multitasking, notifications, widgets, and others — and adds many new features as well.

Besides the user-facing features it offers, Android 3.0 is also specifically designed to give developers the tools and capabilities they need to create great applications for tablets and similar devices, together with the flexibility to adapt existing apps to the new UI while maintaining compatibility with earlier platform versions and other form-factors.

Today, we are releasing a preview of the Android 3.0 SDK, with non-final APIs and system image, to allow developers to start testing their existing applications on the tablet form-factor and begin getting familiar with the new UI patterns, APIs, and capabilties that will be available in Android 3.0.

Here are some of the highlights:

UI framework for creating great apps for larger screen devices: Developers can use a new UI components, new themes, richer widgets and notifications, drag and drop, and other new features to create rich and engaging apps for users on larger screen devices.

High-performance 2D and 3D graphics: A new property-based animation framework lets developers add great visual effects to their apps. A built-in GL renderer lets developers request hardware-acceleration of common 2D rendering operations in their apps, across the entire app or only in specific activities or views. For adding rich 3D scenes, developers take advantage of a new 3D graphics engine called Renderscript.

Support for multicore processor architectures: Android 3.0 is optimized to run on either single- or dual-core processors, so that applications run with the best possible performance.

Rich multimedia: New multimedia features such as HTTP Live streaming support, a pluggable DRM framework, and easy media file transfer through MTP/PTP, give developers new ways to bring rich content to users.

New types of connectivity: New APIs for Bluetooth A2DP and HSP let applications offer audio streaming and headset control. Support for Bluetooth insecure socket connection lets applications connect to simple devices that may not have a user interface.

Enhancements for enterprise: New administrative policies, such as for encrypted storage and password expiration, help enterprise administrators manage devices more effectively.

For an complete overview of the new user and developer features, see the Android 3.0 Platform Highlights.

Additionally, we are releasing updates to our SDK Tools (r9), NDK (r5b), and ADT Plugin for Eclipse (9.0.0). Key features include:

• UI Builder improvements in the ADT Plugin:
  • Improved drag-and-drop in the editor, with better support for included layouts.
  • In-editor preview of objects animated with the new animation framework.
  • Visualization of UI based on any version of the platform. independent of project target. Improved rendering, with better support for custom views.

To find out how to get started developing or testing applications using the Android 3.0 Preview SDK, see the Preview SDK Introduction. Details about the changes in the latest versions of the tools are available on the SDK Tools, the ADT Plugin, and NDK pages on the site.

Note that applications developed with the Android 3.0 Platform Preview cannot be published on Android Market. We’ll be releasing a final SDK in the weeks ahead that you can use to build and publish applications for Android 3.0.

Port your existing mobile number to Google Voice

(Cross-posted from the Google Voice Blog)

867-5309 could be one of the most iconic phone numbers of all time, but it’s not the only number that a lot of us remember by heart. Many of us have a phone number that we've shared with family, friends, and contacts over the years and are reluctant to let go.

One of the most frequent requests we hear from people who use (or want to use) Google Voice is that they’d like to get all of Google Voice’s features without having to give up their long-time phone numbers.

Today, we’re excited to announce that Number Porting is available for all existing Google Voice users. This means you can make the mobile number you’ve always used your Google Voice number, so it can ring any phone you want—or even your computer.



To get started with Number Porting, log in to your Google Voice account, visit the Settings page and click on “Change / Port” next to your Google Voice number.



Porting your number to Google Voice costs $20 and is usually completed within 24 hours. You may incur additional charges, including early termination fees, from your wireless carrier. Contact your carrier to get more details about the charges applicable to you.

After porting your number to Google Voice your mobile service plan will be cancelled, and there are a couple of steps that you’ll have to take to continue making and receiving calls on your mobile device. For more detailed instructions on how Number Porting works and to find tips for making the process as smooth as possible, visit the Google Voice Help Center.

Number Porting is currently available for existing Google Voice users and will become available to new users within the next few weeks, and at this time, Google Voice is available in the U.S. only

Posted by Robert Dong, Software Engineer

Update (1:15PM): Included more details about the porting process.

Weather on your mobile phone, now with added fun

We’d been wanting to build a fun, useful, app-like way to display weather information on our search results pages in the mobile browser. So we pulled together a user experience designer and team of engineers and built a new weather search results snippet that lets you actually play with the results. To try it out, just go to google.com on your iPhone or Android-powered device and search for ‘weather’.

At first glance, you’ll see content that we’d previously shown you before: current conditions and a forecast for the next few days. But by moving the slider over the next 12 hours, you can now see a detailed hour-by-hour breakdown of the changing weather conditions. As you do this, keep an eye on the temperature, wind speed and humidity and see how all these conditions are expected to trend across the day. You may also notice that the background color changes throughout the day. Of course, as you scroll further down you’ll see our regular web search results for your query.

This new weather search experience is available only in English, but we have more updates on the way. We hope you’ll enjoy using it!

Posted by Nick Fey, User Experience Designer and Michael van Ouwerkerk, Software Engineer

Cloud printing on the go

(Cross-posted on the Docs Blog and Gmail Blog.)

Back in April 2010 we announced Google Cloud Print, a service that in Beta allows printing from any app on any device, OS or browser without the need to install any software. Just last month we opened Google Cloud Print to users in the Chrome notebook pilot program. Today we are very pleased to announce the beta launch of Google Cloud Print for mobile documents and Gmail for mobile, which we will be rolling out to users throughout the next few days.

Imagine printing an important document from your smartphone on the way to work and finding the printout waiting for you when you walk in the door. Just open a document in Google Docs or an email in Gmail in your mobile browser and choose “Print” from the dropdown menu in the top right corner. You can also print certain kinds of email attachments (such as .pdf or .doc) by clicking the “Print” link that appears next to them.

This feature will be rolling out today and tomorrow for English speaking users in the US and will work on most phones that support HTML5, such as devices running Android 2.1+ and iOS 3+. To get started, you’ll need to connect your printer to Google Cloud Print. This step requires a Windows PC for now, but Linux and Mac support are coming soon. You can learn more at the Google Cloud Print help center.


Happy printing!

Posted by Tyler Odean, Google Cloud Print Team

Processing Ordered Broadcasts

[This post is by Bruno Albuquerque, an engineer who works in Google’s office in Belo Horizonte, Brazil. —Tim Bray]

One of the things that I find most interesting and powerful about Android is the concept of broadcasts and their use through the BroadcastReceiver class (from now on, we will call implementations of this class “receivers”). As this document is about a very specific usage scenario for broadcasts, I will not go into detail about how they work in general, so I recommend reading the documentation about them in the Android developer site. For the purpose of this document, it is enough to know that broadcasts are generated whenever something interesting happens in the system (connectivity changes, for example) and you can register to be notified whenever one (or more) of those broadcasts are generated.

While developing Right Number, I noticed that some developers who create receivers for ordered broadcasts do not seem to be fully aware of what is the correct way to do it. This suggests that the documentation could be improved; in any case, things often still work(although it is mostly by chance than anything else).

Non-ordered vs. Ordered Broadcasts

In non-ordered mode, broadcasts are sent to all interested receivers “at the same time”. This basically means that one receiver can not interfere in any way with what other receivers will do neither can it prevent other receivers from being executed. One example of such broadcast is the ACTION_BATTERY_LOW one.

In ordered mode, broadcasts are sent to each receiver in order (controlled by the android:priority attribute for the intent-filter element in the manifest file that is related to your receiver) and one receiver is able to abort the broadcast so that receivers with a lower priority would not receive it (thus never execute). An example of this type of broadcast (and one that will be discussing in this document) is the ACTION_NEW_OUTGOING_CALL one.

Ordered Broadcast Usage

As mentioned earlier in this document, the ACTION_NEW_OUTGOING_CALL broadcast is an ordered one. This broadcast is sent whenever the user tries to initiate a phone call. There are several reasons that one would want to be notified about this, but we will focus on only 2:

• To be able to reject an outgoing call;

• To be able to rewrite the number before it is dialed.

In the first case, an app may want to control what numbers can be dialed or what time of the day numbers can be dialed. Right Number does what is described in the second case so it can be sure that a number is always dialed correctly no matter where in the world you are.

A naive BroadcastReceiver implementation would be something like this (note that you should associate this receiver with the ACTION_NEW_OUTGOING_CALL broadcast in the manifest file for your application):

public class CallReceiver extends BroadcastReceiver {
  @Override
  public void onReceive(Context context, Intent intent) {
    // Original phone number is in the EXTRA_PHONE_NUMBER Intent extra.
    String phoneNumber = intent.getStringExtra(Intent.EXTRA_PHONE_NUMBER);

    if (shouldCancel(phoneNumber)) {
      // Cancel our call.
      setResultData(null);
    } else {
      // Use rewritten number as the result data.
      setResultData(reformatNumber(phoneNumber));
  }
}

The receiver either cancels the broadcast (and the call) or reformats the number to be dialed. If this is the only receiver that is active for the ACTION_NEW_OUTGOING_CALL broadcast, this will work exactly as expected. The problem arrises when you have, for example, a receiver that runs before the one above (has a higher priority) and that also changes the number as instead of looking at previous results of other receivers, we are just using the original (unmodified) number!

Doing It Right

With the above in mind, here is how the code should have been written in the first place:

public class CallReceiver extends BroadcastReceiver {
  @Override
  public void onReceive(Context context, Intent intent) {
    // Try to read the phone number from previous receivers.
    String phoneNumber = getResultData();

    if (phoneNumber == null) {
      // We could not find any previous data. Use the original phone number in this case.
      phoneNumber = intent.getStringExtra(Intent.EXTRA_PHONE_NUMBER);
    }

    if (shouldCancel(phoneNumber)) {
      // Cancel our call.
      setResultData(null);
    } else {
      // Use rewritten number as the result data.
      setResultData(reformatNumber(phoneNumber));
  }
}

We first check if we have any previous result data (which would be generated by a receiver with a higher priority) and only if we can not find it we use the phone number in the EXTRA_PHONE_NUMBER intent extra.

How Big Is The Problem?

We have actually observed phones with a priority 0 receiver for the NEW_OUTGOING_CALL intent installed out of the box (this will be the last one that is called after all others) that completely ignores previous result data which means that, in effect, they disable any useful processing of ACTION_NEW_OUTGOING_CALL (other than canceling the call, which would still work). The only workaround for this is to also run your receiver at priority 0, which works due to particularities of running 2 receivers at the same priority but, by doing that, you break one of the few explicit rules for processing outgoing calls:

“For consistency, any receiver whose purpose is to prohibit phone calls should have a priority of 0, to ensure it will see the final phone number to be dialed. Any receiver whose purpose is to rewrite phone numbers to be called should have a positive priority. Negative priorities are reserved for the system for this broadcast; using them may cause problems.”

Conclusion

There are programs out there that do not play well with others. Urge any developers of such programs to read this post and fix their code. This will make Android better for both developers and users.

Notes About Priorities

• For the NEW_OUTGOING_CALL intent, priority 0 should only be used by receivers that want to reject calls. This is so it can see changes from other receivers before deciding to reject the call or not.

• Receivers that have the same priority will also be executed in order, but the order in this case is undefined.

• Use non-negative priorities only. Negative ones are valid but will result in weird behavior most of the time.

Have Androids. Will Travel.

[The first part of this post is by Reto Meier. —Tim Bray]

From c-base in Berlin to the Ice Bar in Stockholm, from four courses of pasta in Florence to beer and pretzels in Munich, and from balalikas in Moscow to metal cage mind puzzles in Prague - one common theme was the enthusiasm and quality of the Android developers in attendance. You guys are epic.

For those of you who couldn't join us, we're in the middle of posting all the sessions we presented during this most recent world tour. Stand by for links.

Droidcon UK

We kicked off our conference season at Droidcon UK, an Android extravaganza consisting of a bar camp on day 1 and formal sessions on day 2. It was the perfect place for the Android developer relations team to get together and kick off three straight weeks of Google Developer Days, GTUG Hackathons, and Android Developer Labs.

Android Developer Labs

The first of our Android Developer Labs was a return to Berlin: home to c-base (a place we never got tired of) and the Beuth Hochschule für Technik Berlin. This all day event cost me my voice, but attracted nearly 300 developers (including six teams who battled it out to win a Lego Mindstorm for best app built on the day.)

Next stop was Florence which played host to our first Italian ADL after some fierce campaigning by local Android developers. 160 developers from all over Italy joined us in beautiful Florence where the Firenze GTUG could not have been more welcoming. An afternoon spent with eager developers followed up by an evening of real Italian pasta - what's not to love?

From the warmth of Florence to the snow of Stockholm where we joined the Stockholm GTUG for a special Android themed event at Bwin Games. After a brief introduction we split into six breakout sessions before the attendees got down to some serious hacking to decide who got to bring home the Mindstorm kit.

Google Developer Days

The Google Developer Days are always a highlight on my conference schedule, and this year's events were no exception. It's a unique opportunity for us to meet with a huge number of talented developers - over 3,000 in Europe alone. Each event featured a dedicated Android track with six sessions designed to help Android developers improve their skills.

It was our first time in Munich where we played host to 1200 developers from all over Germany. If there was any doubt we'd come to the right place, the hosting of the Blinkendroid Guinness World Record during the after-party soon dispelled it.

Moscow and Prague are always incredible places to visit. The enthusiasm of the nearly 2,500 people who attended is the reason we do events like these. You can watch the video for every Android session from the Prague event and check out the slides for each of the Russian sessions too.

GTUG Hackathons

With everyone in town for the GDDs we wanted to make the most it. Working closely with the local GTUGs, the Android and Chrome teams held all-day hackathon bootcamps in each city the day before the big event.

It was a smaller crowd in Moscow, but that just made the competition all the more fierce. So much so that we had to create a new Android app just for the purpose of measuring the relative volume of applause in order to choose a winner.

If a picture is a thousand words, this video of the Prague Hackathon in 85 seconds will describe the event far better than I ever could. What the video doesn't show is that the winners of "best app of the day" in Prague had never developed for Android before.

In each city we were blown away by the enthusiasm and skill on display. With so many talented, passionate developers working on Android it's hard not to be excited by what we'll find on the Android Market next. In the mean time, keep coding; we hope to be in your part of the world soon.

On To South America

[Thanks, Reto. This is Tim again. The South American leg actually happened before the Eurotour, but Reto got his writing done first, so I'll follow up here.]

We did more or less the same set of things in South America immediately before Reto’s posse fanned out across Europe. Our events were in São Paulo, Buenos Aires, and Santiago; we were trying to teach people about Android and I hope we succeeded. On the other hand, I know that we learned lots of things. Here are a few of them:

• Wherever we went, we saw strange (to us) new Android devices. Here’s a picture of a Brazilian flavor of the Samsung Galaxy S, which comes with a fold-out antenna and can get digital TV off the air. If you’re inside you might need to be near a window, but the picture quality is fantastic.

• There’s a conventional wisdom about putting on free events: Of the people who register, only a certain percentage will show up. When it comes to Android events in South America, the certain-percentage part is wrong. As a result, we dealt with overcrowded rooms and overflow arrangements all over the place. I suppose this is a nice problem to have, but we still feel sorry about some of the people who ended up being overcrowded and overflowed.

• Brazilians laugh at themselves, saying they’re always late. (Mind you, I’ve heard Indians and Jews and Irish people poke the same fun at themselves, so I suspect lateness may be part of the human condition). Anyhow, Brazilians are not late for Android events; when we showed up at the venue in the grey light of dawn to start setting up, they were already waiting outside.

• I enjoyed doing the hands-on Android-101 workshops (I’ve included a picture of one), but I’m not sure Googlers need to be doing any more of those. Wherever you go, there’s now a community of savvy developers who can teach each other through the finer points of getting the SDK installed and working and “Hello World” running.

• Brazil and Argentina and Chile aren’t really like each other. But each has its own scruffy-open-source-geek contingent that likes to get together, and Android events are a good opportunity. I felt totally at home drinking coffee with these people and talking about programming languages and screen densities and so on, even when we had to struggle our way across language barriers.

The people were so, so, warm-hearted and welcoming and not shy in the slightest and I can’t think about our tour without smiling. A big thank-you to all the South-American geeks and hackers and startup cowboys; we owe you a return visit.

A new look for Google Translate for Android

(Cross-posted on the Official Google Blog and Translate Blog.)

When we launched the first version of Google Translate for Android in January 2010, we were excited about the year ahead. For the first time, we were bringing the capabilities supported on Google Translate—like machine translation, romanization of non-Roman scripts and spoken translations—to the Android platform. We also offered voice input to let you speak the word or phrase you wanted to translate instead of typing it in, and SMS translation so you could translate SMS messages sent to you in foreign languages.

Today, we’re refreshing Translate for Android with several updates to make the app easier to interact with. Among other improvements, we’ve created better dropdown boxes to help select the languages you want to translate from and into, an improved input box, and cleaner icons and layout.

We also want to let you in on an experimental feature that’s still in its earliest stages—Conversation Mode. This is a new interface within Google Translate that’s optimized to allow you to communicate fluidly with a nearby person in another language. You may have seen an early demo a few months ago, and today you can try it yourself on your Android device.

Currently, you can only use Conversation Mode when translating between English and Spanish. In conversation mode, simply press the microphone for your language and start speaking. Google Translate will translate your speech and read the translation out loud. Your conversation partner can then respond in their language, and you’ll hear the translation spoken back to you. Because this technology is still in alpha, factors like regional accents, background noise or rapid speech may make it difficult to understand what you’re saying. Even with these caveats, we’re excited about the future promise of this technology to be able to help people connect across languages.

As Android devices have spread across the globe, we’ve seen Translate for Android used all over. The majority of our usage now comes from outside the United States, and we’ve seen daily usage from more than 150 countries, from Malaysia to Mexico to Mozambique. It’s really rewarding for us to see how this new platform is helping us break down language barriers the world over.

Translate supports 53 languages, from Afrikaans to Yiddish, and voice input for 15 languages. You can download the application, available for devices running Android 2.1 and above, by searching for “Google Translate” in Android Market or by scanning the QR Code below.


Posted by Awaneesh Verma, Product Manager

Now available: Google Places with Hotpot for iPhone

We recently released Google Places with Hotpot in Google Maps for Android, and starting now, you can have that same great experience as an iPhone app. We realize the importance of finding places you’ll love while you’re out and about, no matter what mobile device you use. And Places with Hotpot not only helps you find places near where you are, it gives you the best places to go for you by personalizing your search results.

In case you aren’t familiar with Google Places, it lets you quickly search for places nearby and personalizes the results based on places you’ve rated. We get you started with a few popular search categories, but you can also tailor the list by adding your own favorite searches. This makes it fast and easy to find the best places for you with little fuss.

Use a default search category, save your own, or rate the nearest place quickly.

It can be pretty rewarding to discover a new place you love, but we also realize that there are some experiences you just can’t wait to share. So Places makes it super simple to rate a place with your iPhone while you’re there. Just fire up the app and hit “Rate now.” It will use your location to guess your current place and let you post a Hotpot review right from your phone. But it’s not just about getting to say what you think—the more you rate places, the more you’re sharing about your tastes and the more we can give you personally tailored recommendations.

Give your star rating and add optional details or a review so Hotpot knows your taste.

If you want to make things even tastier, just visit google.com/hotpot from your desktop computer. Here you can add friends to the mix and quickly rate all the places you already know. Once you’ve added friends, you’ll find your results seasoned not just with reviews from around the web and recommendations based on your own personal taste, but also with your friends’ opinions too.

Once you start rating and add friends, Places can give you personalized recommendations.

Get the Places app on your iPhone now by searching for Google Places in the App Store or going here.

This first version of Places is available for all iOS devices in English only. However, expect more features and improvements to roll out soon, including localization in many new languages. We’re hard at work to make Places with Hotpot more and more delicious.

Posted by Greg Blevins, Software Engineer, Google Hotpot team

Gingerbread NDK Awesomeness

[This post is by Chris Pruett, an outward-facing Androider who focuses on the world of games. —Tim Bray]

We released the first version of the Native Development Kit, a development toolchain for building shared libraries in C or C++ that can be used in conjunction with Android applications written in the Java programming language, way back in July of 2009. Since that initial release we’ve steadily improved support for native code; key features such as OpenGL ES support, debugging capabilities, multiple ABI support, and access to bitmaps in native code have arrived with each NDK revision. The result has been pretty awesome: we’ve seen huge growth in certain categories of performance-critical applications, particularly 3D games.

These types of applications are often impractical via Dalvik due to execution speed requirements or, more commonly, because they are based on engines already developed in C or C++. Early on we noted a strong relationship between the awesomeness of the NDK and the awesomeness of the applications that it made possible; at the limit of this function is obviously infinite awesomeness (see graph, right).

With the latest version of the NDK we intend to further increase the awesomeness of your applications, this time by a pretty big margin. With NDK r5, we’re introducing new APIs that will allow you to do more from native code. In fact, with these new tools, applications targeted at Gingerbread or later can be implemented entirely in C++; you can now build an entire Android application without writing a single line of Java.

Of course, access to the regular Android API still requires Dalvik, and the VM is still present in native applications, operating behind the scenes. Should you need to do more than the NDK interfaces provide, you can always invoke Dalvik methods via JNI. But if you prefer to work exclusively in C++, the NDK r5 will let you build a main loop like this:

void android_main(struct android_app* state) {
    // Make sure glue isn't stripped.
    app_dummy();

    // loop waiting for stuff to do.
    while (1) {
        // Read all pending events.
        int ident;
        int events;
        struct android_poll_source* source;

        // Read events and draw a frame of animation.
        if ((ident = ALooper_pollAll(0, NULL, &events,
                (void**)&source)) >= 0) {
            // Process this event.
            if (source != NULL) {
                source->process(state, source);
            }
        }
        // draw a frame of animation
        bringTheAwesome();
    }
}

(For a fully working example, see the native-activity sample in NDK/samples/native-activity and the NativeActivity documentation.)

In addition to fully native applications, the latest NDK lets you play sound from native code (via the OpenSL ES API, an open standard managed by Khronos, which also oversees OpenGL ES), handle common application events (life cycle, touch and key events, as well as sensors), control windows directly (including direct access to the window’s pixel buffer), manage EGL contexts, and read assets directly out of APK files. The latest NDK also comes with a prebuilt version of STLport, making it easier to bring STL-reliant applications to Android. Finally, r5 adds backwards-compatible support for RTTI, C++ exceptions, wchar_t, and includes improved debugging tools. Clearly, this release represents a large positive ∆awesome.

We worked hard to increase the utility of the NDK for this release because you guys, the developers who are actually out there making the awesome applications, told us you needed it. This release is specifically designed to help game developers continue to rock; with Gingerbread and the NDK r5, it should now be very easy to bring games written entirely in C and C++ to Android with minimal modification. We expect the APIs exposed by r5 to also benefit a wide range of media applications; access to a native sound buffer and the ability to write directly to window surfaces makes it much easier for applications implementing their own audio and video codecs to achieve maximum performance. In short, this release addresses many of the requests we’ve received over the last year since the first version of the NDK was announced.

We think this is pretty awesome and hope you do too.

Google Goggles gets faster, smarter and solves Sudoku

Today we’re launching a new version of Google Goggles that’s faster and smarter than ever before. The new Goggles 1.3 client for Android can scan barcodes almost instantly. All versions of Goggles can now recognize print ads in popular magazines and newspapers. Finally, Goggles has also learned a fun new trick for Sudoku fans.

Barcodes

When shopping offline, it’s helpful to be able to learn more about a product by scanning its barcode. With the new Android version of Google Goggles, scanning barcodes is much faster. Open Goggles and hover over the barcode or QR code. Within a second the phone gently vibrates and presents results, without requiring a button press. Simply tap on the result to read product reviews, check in-store availability and compare prices.

Print ads in magazines and newspapers

We’re excited to take another step in our vision of connecting offline media to online media. The next time you're flipping through the pages of your favorite magazine, try taking a picture of an ad with Goggles. Goggles will recognize print ad and return web search results about the product or brand. This new feature of Goggles is enabled for print ads appearing in major U.S. magazines and newspapers from August 2010 onwards.

This feature is different from the marketing experiment that we announced in November. We're now recognizing a much broader range of ads than we initially included in our marketing experiment. And when we recognize a print ad, we return web search results. While in the experiment, we return a specific link to an external website.

Sudoku

Our favorite weekend distraction is a quiet 15 minutes spent solving a Sudoku puzzle. But even that can be an frustrating experience if (like us) you make a mistake and are unable to solve the puzzle. Now, Goggles on Android and iPhone can recognize puzzles and provide answers to help make you faster than a Sudoku champ. So if you ever get stuck, take a clear picture of the entire puzzle with Goggles and we’ll tell you the correct solution. Check out this video to see how it works.

Google Goggles 1.3 with improved barcode scanning is available for download in Android Market. Recognition of print ads and Sudoku solver is now enabled for the Google Goggles app on Android, as well as the Goggles component of the Google Mobile App on iPhone.

Posted by Leon Palm and Jiayong Zhang, Software Engineers

A Sneak Peek of Android 3.0, Honeycomb

The past few weeks have been exciting ones for the Android team: we recently released Nexus S and Android 2.3, Gingerbread, and we’ve even had some of our most popular team members take a trip to space. But we haven’t stopped buzzing with excitement: today at the Consumer Electronic Show (CES) in Las Vegas, we previewed Android 3.0, Honeycomb.

Honeycomb is the next version of the Android platform, designed from the ground up for devices with larger screen sizes, particularly tablets. We’ve spent a lot of time refining the user experience in Honeycomb, and we’ve developed a brand new, truly virtual and holographic user interface. Many of Android’s existing features will really shine on Honeycomb: refined multi-tasking, elegant notifications, access to over 100,000 apps on Android Market, home screen customization with a new 3D experience and redesigned widgets that are richer and more interactive. We’ve also made some powerful upgrades to the web browser, including tabbed browsing, form auto-fill, syncing with your Google Chrome bookmarks, and incognito mode for private browsing.

Honeycomb also features the latest Google Mobile innovations including Google Maps 5 with 3D interactions and offline reliability, access to over 3 million Google eBooks, and Google Talk, which now allows you to video and voice chat with any other Google Talk enabled device (PC, tablet, etc).

Please stay tuned for more Honeycomb news from the Android team. For now, you can get a taste of Honeycomb by checking out this video.

Posted by Andy Rubin, VP of Engineering