Dalvik JIT

[This post is by Dan Bornstein, virtual-machine wrangler. � Tim Bray]

As the tech lead for the Dalvik team within the Android project, I spend my time working on the virtual machine (VM) and core class libraries that sit beneath the Android application framework. This layer is mostly invisible to end users, but done right, it helps make Android devices run smoothly and improves developer productivity.

The 2.2 release is particularly pleasing to me, as it is the first release since before 1.0 in which we have been able to deliver significantly new VM technology. And unlike much of what my team and I do, it is something that can be experienced directly by end users.

�Dalvik� isn�t exactly a household word (at least in my country), and most people wouldn�t know a virtual machine if it hit them in the face, but when you tell them you were able to make their existing device work better � run faster, use less battery � they will actually take notice!

What Makes This Possible?

We added a Just In Time (JIT) compiler to the Dalvik VM. The JIT is a software component which takes application code, analyzes it, and actively translates it into a form that runs faster, doing so while the application continues to run. If you want to learn more about the design of the Dalvik JIT, please watch the excellent talk from Google I/O 2010 given by my colleagues Bill Buzbee and Ben Cheng, which should be posted to YouTube very soon.

To be clear, the differences aren�t always dramatic, nor do they apply uniformly to all applications. Code that is written to run the CPU all-out can now do more in the same amount of time (running faster), and code that is written to be rate-limited can get its work done using less time and less of the CPU (using less battery). On the performance front in particular, we have seen realistic improvements of 2x to 5x for CPU-bound code, compared to the previous version of the Dalvik VM. This is equivalent to about 4x to 10x faster than a more traditional interpreter implementation.

The team is proud of our new JIT in general, but we are especially proud of two aspects of it:

Many previous JIT implementations react slowly, delivering performance improvements only after a long warm up period. In the extreme, it can be minutes or even hours before the code is fully up to speed. On the other hand, the Dalvik JIT reacts quickly, so that mere moments after you hit the �Start� button on your favorite game, you are already benefiting from the work of the JIT.

We are also very pleased with how little memory the JIT uses. The code for the JIT itself is well under 100k, and each process that the JIT runs in will typically only use another 100k or so of RAM. On the current generation of Android phones, device users won�t even notice this additional memory usage; on my own phone, I can still have literally dozens of applications warmed up in memory and ready to go.

The Dalvik team isn�t resting on its laurels, either. We are hoping to see the Dalvik JIT deployed on many devices in the coming months. Looking forward, the team has an endless list of ideas for making the VM and library code better, which we are diligently working on.

Android Application Error Reports

[This post, the first in a series about new features in Android 2.2 ("Froyo"), is by Jacek Surazski, a Googler from our Krakow office. � Tim Bray]

The upcoming release of Android will include a new bug reporting feature for Market apps. Developers will receive crash and freeze reports from their users. The reports will be available when they log into their Android Market publisher account. No more blind debugging!

When an app freezes or stops responding, the user can send a bug report to the developer with a click of a button, right from their phone. The new button appears in the application error dialog; if the user chooses to click it, the Google Feedback client running on the device will analyze the offending app and compose a report with information needed to diagnose it. The system is set up with user privacy in mind � the app developer will not receive information which could identify the user in any way. The user can also preview all information that will be sent.

If users choose to do so, they may also send additional system information like device logs. Because there is a chance these may contain private information, they will not be passed on to the developer; they will be used by Google to track down bugs in the Android system itself.

On the receiving end, developers will get tools to diagnose, triage and fix bugs in their apps. A popular app can generate hundreds of thousands of reports. Google Feedback aggregates them into "bugs" - individual programming errors. Bugs are displayed to developers sorted by severity, measured as the rate at which reports for the bug are flowing in.

Clicking on a bug will display information such as stack traces, statistics about which type of hardware the bug occurred on and what versions of the app the user was running. In case of freezes, stack traces for all threads in the app will be displayed. This data should give developers a good idea how well their apps are faring in the wild.

Google is constantly working on improving and extending the feedback feature to provide developers with tools to improve the quality of their apps. The benefits should be felt by both developers and their users.

[I recommend watching the video of this feature's announcement in Vic Gundotra's Google I/O keynote on May 20th, mostly for the audience reaction. I hear that a high proportion of developers are making use of the Market's new "Bugs" tab. � Tim Bray]

Android 2.2 and developers goodies.

Today at Google I/O we announced that Android 2.2 is right around the corner. This is our seventh platform release since we launched Android 1.0 in September 2008. We wanted to highlight five areas in particular:

Performance & speed: The new Dalvik JIT compiler in Android 2.2 delivers between a 2-5X performance improvement in CPU-bound code vs. Android 2.1 according to various benchmarks.

New enterprise capabilities: We�ve added Exchange capabilities such as account auto-discovery and calendar sync. Device policy management APIs allow developers to write applications that can control security features of the device such as the remote wipe, minimum password, lockscreen timeout etc.

Faster, more powerful browser: We have brought the V8 JavaScript engine to the Android browser as part of 2.2. This has resulted in a 2-3X improvement in JavaScript performance vs. 2.1.

Rich set of new APIs and services: New data backup APIs enable apps to participate in data backup and restore, allowing an application's last data to be restored when installed on a new or a reset device. Apps can utilize Android Cloud to Device Messaging to enable mobile alert, send to phone, and two-way push sync functionality. Developers can now declare whether their app should be installed on internal memory or an SD card. They can also let the system automatically determine the install location. On the native side, a new API now gives access to Skia bitmaps.

Additions to Android Market: Android Market provides Android Application Error Reports, a new bug reporting feature, giving developers access to crash and freeze reports from users. Developers will be able to access these reports via their account on the Android Market publisher website.

For a complete list of everything we�ve included in Android 2.2, please see the platform highlights.

Developers can now download the Android 2.2 SDK and Android NDK, Revision 4 from the Android developer site.

Tools update

We are releasing new version of the Android SDK Tools, Revision 6, Eclipse plug-in ADT 0.9.7 and Android NDK, Revision 4.

Android SDK Tools, Revision 6, Eclipse plug-in 0.9.7

These new versions include support for library projects that will help you share code and resources across several Android projects.

Android NDK, Revision 4

Workflow improvements
The new NDK brings a host of workflow improvement, from compilation, to debugging. Starting with 2.2, the NDK enables debugging native code on production devices.

ARMv7 instruction set support
This release enables the generation of machine code for the ARMv7-A instruction set. Benefits include higher performance, as well as full use of the hardware FPU for devices that support it.

ARM Advanced SIMD (a.k.a. NEON) instruction support
The NEON instruction set extension can be used to perform scalar computations on integers and floating points. However, it is an optional CPU feature and will not be supported by all Android ARMv7-A based devices. The NDK includes a tiny library named "cpufeatures" that can be used by native code to test at runtime the features supported by the device's target CPU.

For more information, please see the releases notes for the SDK Tools, ADT, and NDK.

As I said at the beginning, Android 2.2 will be here soon, and some devices will get the update in the coming weeks. I invite application developers to download the new SDK and tools and test your applications today.

Check out the video below to learn more about Android 2.2.

The Google TV Story

Vincent Dureau, who�s in charge of Google TV, is a lean, bony-faced man with a strong French accent; not too far off my own age, I�d say. With the announcement imminent, he�s been too busy to write; I'm reporting on my talk with him to give a feel for the thinking behind the project. You�ll notice an absence of quotation marks; Vincent�s half of the conversation is reconstructed from the combination of my memory and notes. I think it�s accurate in essence, but certainly not in detail; among other things I can�t write with a French accent.

On why Google TV is needed:

Even two years ago you would have said that telephones are mostly for making calls, maybe for email and texting. Today, we know that phones can actually do a whole lot more. In the same way, people say that TV is just for watching TV. But, like the phone can be used for more than making calls, we believe that TV can be used for more than just video. Also, there�s not enough shelf space for the stuff on TV; not even with online channel guides and your PVR access and your racks full of disks. The shelf space should be as big as the web.

On why developers should care:

They�ve always had access to the desktop. With mobile devices, they managed to get into your pocket. Google TV brings them into the living room, which is where people live.

On what�s going to be in the SDK:

First, we have to make sure that most mobile apps work on your TV, too. Second, we should offer TV-specific features, like being smart about screen sizes, changing channels, embedding video streams, mashing up live TV and what�s on the PVR and what�s on the Web.

On the Google TV project:

The project started 2� years ago, with a vision of a walled garden of TV-optimized web services. But the landscape keeps shifting, particularly in the capabilities of mobile devices. The only solution big enough for the problem is to bring the whole web to your TV.

On which apps will come with the initial release of Google TV:

First of all, we run Chrome so we can ship both Android and web apps. Some will be pre-loaded; this is a moving target but we expect that Listen, Netflix, and Amazon Video On Demand will be on board.

On what truly great Google-TV apps he imagines:

That�s irrelevant; the reason we�re building the SDK is to enable all those smart people out there that don�t work for Google to do cool stuff with TV.

On how it works if there isn�t a partnership between Google TV and your TV provider:

It should be pretty good; the device comes with an IR blaster and knows the IR interfaces for the popular satellite and cable boxes. You really should be able to get an integrated experience.

On himself:

He�s the guy who pitched the project to Google�s executive team. He has been at Google for four years, and was hired to work on TV, originally ads. Working on TV is pretty much the only thing he�s ever done. Prior to Google, he worked on compression and DIRECTV.

On which TV he watches:

He doesn�t watch TV, he tests it. His popular test materials are Battlestar Galactica, Life on Discovery, Democracynow.org, Al-Jazeera�s newscasts (they have reporters more places than any other network); and, these days, the NBA playoffs. He does a lot more on his TV than watch TV; he uses it to run Pandora and Last.fm to hear the music through the nice speakers. Whenever he hears a tune he likes, he buys it right there & then from Amazon, which can get a little expensive.

On how to get involved:

You can begin building optimized web apps today. If you�re interested in building Android apps, visit our Google TV homepage to sign up for updates on when the SDK add-on will be available. And if you�re interested in helping out in a broader scope, check out our Google jobs site and apply for an engineering position.

Latitude API Launch

Over at the Google Code Blog, there's a pretty significant announcement, about the release of APIs for Latitude. the idea, as you might expect, is that the best way to get good location-based applications is to put the tools for building them into everyone's hands.

A glance at the online documentation reveals an essentially-RESTFul API with JSON payloads, which should be easy to use from an Android app. It seems likely that a device which knows its location is a really good platform for building location-sensitive apps.

Stand By...

I'm posting this from Moscone West, the site of Google I/O 2010. Some things that it may be useful to know:

• The official hash tag is #io2010

• The keynotes will be live-blogged all over the place (thus, not here) and also live-streamed on YouTube.

• If you're mad because you couldn't get a ticket, we're sorry, but you're not alone. We have filled Moscone West to the very absolute splitting-at-the-seams max. There are a ton of Googlers who couldn't get in.

Things have already started; above is our own Roman Nurik giving the first Android session at the pre-IO Bootcamp.

Above are the signs over the Android part of the main gathering area. There are many tantalizing display cases and tabletops; gleaming and empty now, but not for long.

Meta-Blogging

Thursday is the big Android day at Google I/O. There will be announcements. We're going to try to use this blog to deliver more depth and perspective than you can expect from an executive on a stage in a keynote. So we've lined up a whole lot of blog posts; more than any human could be expected to read in a day.

The plan is to have a couple of posts on Thursday summarizing and highlighting what we think are probably the big-news stories. Then we'll have more detailed technical pieces every other day or so for the next couple of weeks, filling in the details behind the announcements. It's heart-warming how eager the engineers are to tell the world about what they've been building, and it makes me happy to facilitate the process.

There are other Google blogs that are going to be working hard too, telling the other stories coming out of this gathering. We'll post some links to things that seem particularly newsworthy, either to the world in general or to the Android comunity in particular.

Stay tuned!

Twitter for Android: A closer look at Android�s evolving UI patterns

[This post is by Chris Nesladek, Interaction Designer, Richard Fulcher, Interaction Designer, and Virgil Dobjanschi, Software Engineer � Tim Bray]



Along with our regular updates of the Android platform, we like to build example applications that showcase best practices for UI features and behavior patterns, to help our 3rd party developers create even richer applications.



For example, the Twitter for Android application that we worked with Twitter to design gives you, the 3rd party developer, a working example of how you can customize and build an application that�s both fun and highly functional. This blog post is meant to showcase these patterns along with some recommended implementations as you start to develop your applications around them.

Let�s get started and explore these patterns in more detail now.

Pattern 1: Contacts Sync with Address book at Sign in

One of the most important intents we added to Twitter for Android was the ability to sync your Twitter contacts into the phone. This integration also allowed us to give Twitter users with an Android phone the use of the QuickContact widget, which gives users a choice of ways to contact their followers.

We recommend:

• Using this activity upon first signing into an application.


• If your app has no sign-in, showing this screen at first launch to improve discoverability of contact sync.

Pattern 2: Twitter account integration with QuickContact for Android

The good news for developers is you get this highly functional contacts feature for free if users choose to sync contact information into your app. QuickContact for Android provides instant access to a contact's information and communication modes. For example, a user can tap a contact photo and with one more tap launch a call, SMS, or email to that person. Other applications such as Email, Messaging, and Calendar can also reveal the QuickContact widget when you touch a contact photo or status icon.

Pattern 3: Dashboard

The dashboard pattern serves as a home orientation activity for your users. It is meant to include the categories or features of your application. We recommend including an Action bar on this screen as well.

The dashboard can be static or dynamic. For example, in the case of our dashboard for Twitter, we used the goodness of Live Wallpapers introduced in 2.1 to create an animated dashboard complete with real-time trend bubbles and the Twitter bird silhouette.

We recommend:

• Using this pattern to showcase the most prominent features of your app.


• Adding some unexpected delight to this screen, making it engaging without overwhelming the user.


• Exercising caution - for some apps, the user will want to jump directly into the meat of the application. For others, this sort of welcoming dashboard will be the right starting place.

Pattern 4: Action Bar

The Action bar gives your users onscreen access to the most frequently used actions in your application. We recommend you use this pattern if you want to dedicate screen real estate for common actions. Using this pattern replaces the title bar. It works with the Dashboard, as the upper left portion of the Action bar is where we recommend you place a quick link back to the dashboard or other app home screen.

We recommend:

• Placing an Action bar at the top of the screen to house the most common actions for your application that work across all activities.


• Using no more than 3 onscreen actions for the Action bar. Use the main menu as overflow for actions that are less important. The balance between Action bar and main menu will ensure the richness of interaction that is Android.


• Making the left-hand region actionable, offering one-touch return to your dashboard or other app home.

Pattern 5: Search Bar

The Search bar pattern gives you a fast way to switch between resources that are searchable by your application. For example, with Twitter for Android, we used the pattern to support searching within Tweets as well as People. When triggered, this pattern sits on top of the Action bar.

We recommend:

• You support suggestions.


• You keep a search history so users upon returning to the search activity can have quick one-button access to previous searches.

Additionally, you can feel free to use the Search bar selection mechanism as a replacement for tabs since it�s really just a fast pivot on a data set. If you have more than 3 data sets, tabs become problematic since no more than 3 can be onscreen at once. For example, look at how we implemented the Profile switching mechanism below:

Pattern 6: QuickActions

QuickActions is our newest UI pattern. Currently, it has been implemented as a fast, engaging, popup triggered by an onscreen UI element that identifies it in as minimally disruptive way as possible. We recommend you use this pattern for list views that are data intensive where items inside the list have contextual actions associated with them. QuickActions can be used as a replacement for our traditional dialog invoked by long press.



By choosing to use this pattern as part of a list, we made it easier for Twitter users to take action on the information in the list view by keeping the item and associated actions in context. We also took the extra step of making it easier to target links in list views by turning off the list view button element as a secondary component to making this pattern even more usable. This way users of Twitter for Android can view links with one tap and/or see the posted tweet on a map by tapping the tweet meta data directly.

We recommend:

• Creating a UI element that is minimal and recognizable as an action popup; either a frame around an image or an icon in a list item.


• Only using this pattern in applications where the data is intensive.


• Placing the action popup below or above the information you wish to allow users to take relevant contextual actions on. This will make it easier to associate the actions with the content in view.


• Turning off the entire list view button element so that regions can be easily targeted for the user.

Pattern 7: Companion Widget

The companion widget pattern is something we recommend all developers think about deeply. The widget you create should be more than a big button link into your app. Used correctly, it can provide a place on a home screen that personalizes, albeit in a small window, your application.



In the case of Twitter for Android, we designed and built small and large-sized widgets to support different types of functionality. Both widgets let a user view his/her tweetstream. However, the smaller widget hands off to the application to create a reply to a tweet from the stream, whereas the larger one gives direct access to the Tweet compose activity.

We recommend:

• Identify your application in the widget with a brand icon


• Make this more than a button into your app. Give your user an action or view into the app itself.


• Keep the activity stateful so that on exiting the application and re-entering a user is returned to the same context in the activity, minimizing the impact of using the dashboard if it is used.

Don�t think we quite got something right? As many of you know, we�ll soon be open sourcing this application code under the Android Open Source Project. We look forward to seeing what you can build starting from this code these UI patterns. In the meantime, Happy Tweeting!



Twitter for Android is available in Android Market for immediate download. It is compatible with Android 2.1/2.0 devices, with support coming soon for more.



Come check out the Android UI patterns session at Google I/O next week to learn more about how this applies across our framework and not just in the Twitter app.