Saturday, July 10, 2010

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 6.0.458.1 for Windows, Mac and Linux platforms

  • InfoBar should not be shown when the user first submits a form
. (Issue: 47426)
  • AutoFill should continuously update profile data as the user submits forms with new data
AutoFill: Aggregate profile data. Remove the AutoFill InfoBar. Remove more remnants of shipping address and CVV. (Issue: 47423)
  • When editing a field in a previously auto-filled form, only display unique suggestions
AutoFill: Remove duplicate suggestions when providing suggestions for a field (Issue: 47436)
  • Enabling sync freezes Chromium
Remove NIGORI from the sync routing info. (Issue: 47766)
  • Chrome unable to start if other FFmpeg DLLs are present on the system (Issue: 35857)
Known Issues
  • This crasher still exists in the current release, the fix is completed but not for this dev channel update: Issue 48094
More details about additional changes are available in the log of all revisions.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Karen Grunberg
Google Chrome

[Gd] Orkut App Issues Being Addressed

| More

Google Code Blog: Orkut App Issues Being Addressed

The Orkut engineering team has been hard at work addressing some recent issues and we would like to provide a status update and apologize for the inconvenience our spotty service may have caused you. We’re not done yet, but we wanted to explain to you what happened and what corrective measures we’re taking to ensure it doesn’t happen again:

First, Orkut is based on open source software that is subject to frequent updates, which we then pull and merge into the Orkut code tree. A result is that this can sometimes makes bugs harder to discover and fix. We accidentally began overwriting user app preferences, which resulted in the activity updates not getting posted, but this has now been fixed.

Another unexpected effect was that getting viewer and owner information via data pipelining also became broken, and we’re still working to fix this.

Lastly, we had a problem with our directory listing that led to some featured apps being reported as “being reviewed.” We’ve already identified how to fix this permanently, and the fix should be live in a few days.

Once again, we would like to apologize for these bugs. Thanks to everyone for their patience these past weeks as we’ve focused on fixing these issues, and don’t forget to check this forum thread for status updates.

By Eduardo Thuler, Orkut product manager

[Gd] WebFont Loader updated with Ascender Module

| More

Google Code Blog: WebFont Loader updated with Ascender Module

Two months ago we announced the WebFont Loader, a JavaScript library for improving the web font experience. Today we are pleased to announce the availability of the Ascender Module, so now you can use the WebFont Loader with Ascender’s FontsLive web font service.

The WebFont Loader was designed to make it easy to switch between different providers of web fonts, including Google, Typekit, and others. The Ascender module provides users of the FontsLive service with enhanced controls over how web fonts are handled by various browsers.

The WebFont Loader provides developers with advanced features to manage how web fonts behave, establish better consistency across all browsers and even set the fallback font size to more closely match the web font, so content doesn't reflow after loading.

Google is delighted to work with the Ascender and DevBridge teams on this new module for the WebFont Loader. We look forward to continue to advance typography on the web.

By Jeremie Lenfant-Engelmann, Google Font API team

Friday, July 9, 2010

[Gd] Test Driven Integration

| More

Google Testing Blog: Test Driven Integration

By Philip Zembrod

In an earlier post on trying out TDD I wrote how my mindset while coding changed from fear of bugs in the new code to eager anticipation to see the new code run through and eventually pass the already written tests. Today I want to tell about integrating components by writing integration tests first.

In a new project we decided to follow TDD from the start. We happily created components, “testing feature after feature into existence” (a phrase I love; I picked it up from a colleague), hitting a small test coverage of around 90% from the start. Obviously, when it came to integrating the components into a product, the obvious choice was to do that test-driven, too. So how did that go?

What I would have done traditionally was select a large enough set of components that, once integrated, should make up something I could play with. Since at least a minimum UI would be needed, plus something that does visible or useful things, preferably both, this something would likely have been largish, integrating quite a few components. With the playing around and tryout, I’d enter debugging, because of course it wouldn’t work at first attempt. The not-too-small number of integrated components would make tracking the cause of failures hard, and anticipating all this while coding, I’d have met the well-known fearful mindset again, slowing me down, as I described in my initial TDD post.

How did TDI change this game for me? I realized: With my unit test toolbox that can test any single component, I can also test an integration of 2 components regardless of whether they have a UI or do something visible. That was the key to a truly incremental process of small steps.

First, write the test for 2 components, run it and see it fail to make sure the integration code I’m about to write is actually executed by the test. Write that bit of code, run the test and see it succeed. If it still fails, fix what's broken and repeat. Finding what's broken in this mode is usually easy enough because the increments are small. If the test failure doesn’t make obvious what’s wrong, adding some verifications or some logging does the trick. A debugger should never be needed; automated tests are, after all, a bit like recorded debugging sessions that you can replay any time in the future.

Repeating this for the 3rd component added, the 4th, etc., I could watch my product grow, with new passing tests every day. Small steps, low risks in each, no fear of debugging; instead, continuous progress. Every day this roaring thrill: It works, it works! Something’s running that didn’t run yesterday. And tomorrow morning I’ll start another test that will run tomorrow evening, most likely. Or already at lunchtime. Imagine what kind of motivation and acceleration this would give you. Better, try it out for yourself. I hope you’ll be as amazed and excited as I am.

What are the benefits? As with plain TDD, I find this fun-factor, this replacement of dread of debugging by eagerness for writing the next test to be able to write and run the next code the most striking effect of TDI.

The process is also much more systematic. Once you have specified your expectations at each level of integration, you’ll verify them continuously in the future, just by running the tests. Compare that to how reproducible, thorough and lasting your verification of your integration would be if you’d done it manually.

And if you wrote an integration test for every function or feature that you cared about during integration, then you can make sure each of them is in shape any time by just running the tests. I suspect one can’t appreciate the level of confidence in the code that creates until one has experienced it. I find it amazing. I dare you to try it yourself!

P.S. On top of this come all the other usual benefits of well-tested code that would probably be redundant to enumerate here, so I won’t. ;-)

Thursday, July 8, 2010

[Gd] Apps on SD Card: The Details

| More

Android Developers Blog: Apps on SD Card: The Details

[This post is by Suchi Amalapurapu, an engineer who worked on this feature. — Tim Bray]

Android 2.2 supports application installation on external storage devices like the SD card. This should give users room for many more apps, and will also benefit certain categories, like games, that need huge assets.

(Note that not all of the contents of an “SD-card-resident” APK are actually on the card; the dex files, private data directories, and native shared libraries remain in internal storage.)

The “Manage Applications” screen in the Settings app now has an “On SD Card” tab. The sizes listed in Manage Applications only include the space taken by the application on internal storage.

The Application Info screen now has either a “move to SD card” or “move to phone” button, but this is often disabled. Copy-protected apps and updates to system apps can’t be moved to the SD card, nor can those which are don’t specify that they work on the SD card.

Controlling Installation Preference

SD-card installation is an optional feature on Android 2.2, is under the control of the developer not the user, and will not affect any applications built prior to Android 2.2.

Application developers can set the field android:installLocation in the root manifest element to one of these values:

  • internalOnly: Install the application on internal storage only. This will result in storage errors if the device runs low on internal storage.

  • preferExternal: The android system tries to install the application on external storage. If that is full, the application is installed on internal storage.

  • auto: Let the Android system decide the best install location for the application. The default system policy is to install the application on internal storage first. If the system is running low on storage, the application is then installed on external storage.

If the installLocation is not specified (as is the case for all applications prior to Android 2.2), the application is installed on internal storage. Application updates will by default try to retain their install location, but application developers may change the installLocation field in an update. Installing an application with this new attribute on older devices will not break compatibility and these applications will be installed on internal storage only.

Application developers can also explicitly install under-development code on external storage via adb install flags, which override the installLocation field: -f for internal storage, and -s for external storage. They can also override the default install location to verify and test application installation on SD card with an adb shell pm command:

adb shell pm setInstallLocation option

Where option is one of:

  • 0 [auto] Let the system decide.

  • 1 [internal only]

  • 2 [external]

The current install location can be retrieved via
adb shell pm getInstallLocation
Note that changing this default can cause applications to misbehave if they’re not prepared to live on the SD card.

USB Mass Storage interactions

The Android system stores the SD-card-resident applications’ APKs in a secure application-specific container. A new flag FLAG_EXTERNAL_STORAGE in ApplicationInfo object indicates that an application is currently installed on the SD card. This storage is removed when an SD-card-resident app is uninstalled.

When an Android device’s SD card is unmounted, applications installed on it are no longer available. Their internal storage is still there and such apps can be uninstalled without replacing the SD card.

The Android framework provides several broadcast intents to support the (small) class of applications, such as launchers, that access other applications’ resources:

  • When the SD card is unmounted, ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE with a list of the disabled applications and a list of corresponding application uid’s via extra attributes in the broadcast intent.

  • When the SD card is mounted, ACTION_EXTERNAL_APPLICATIONS_AVAILABLE with a list of enabled applications and a list of corresponding application uid’s via extra attributes in the broadcast intent.

Applications that handle broadcast intents like ACTION_PACKAGE_ADDED, ACTION_PACKAGE_REMOVED may also want to handle these additional notifications.

When an application gets moved between internal to external storage and vice versa, the application is disabled first (which includes broadcasting intent ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE), the asset resources are copied, and then the application is enabled (which includes broadcasting intent ACTION_EXTERNAL_APPLICATIONS_AVAILABLE).

Security and Performance Implications

Applications on SD card are mounted via Linux’s loopback interface and encrypted via a device-specific key, so they cannot be decrypted on any other device. Note that this is security measure and does not provide copy protection; the apps are world readable just like the resources of normal applications installed on the device’s internal storage. Copy-protected applications cannot be installed on external media. In the interests of stability, updates to system applications also cannot be installed on the external media. The application resources stored on external storage are read-only and hence there are no performance issues with loading or launching applications on SD card.

Swapping or Transferring SD Card Contents

It has always been the case that when you swap SD cards on an Android device, if you physically copy the contents of the old card to the new one, the system will use the data on the new card as if nothing had changed. This is also true of apps which have been installed on the SD card.

When not to install on SD card?

The advantage of installing on SD card is easy to understand: contention for storage space is reduced. There are costs, the most obvious being that your app is disabled when the SD card is either removed or in USB Mass Storage mode; this includes running Services, not just interactive Activities. Aside from this, device removal disables an application’s Widgets, Input methods, Account Managers, Device administrators, Live wallpapers, and Live folders, and may require explicit user action to re-enable them.


[Gd] Android 2.2 SDK refresh

| More

Android Developers Blog: Android 2.2 SDK refresh

As you may have noticed, the source code for Android 2.2, which we call Froyo, has been released.

The Android 2.2 SDK that was released at Google I/O contained a preview of the Froyo system image and today, we are releasing an update to bring it into sync with the system image pushed to Nexus One devices.

I encourage all developers to use the SDK manager to update to this version.


[Gd] Upcoming App Engine conference appearances

| More

Google App Engine Blog: Upcoming App Engine conference appearances

Fresh from our exciting news from Google I/O last quarter (launch of Google App Engine for Business and new product developments), we now look ahead to the mid-summer months. Since I/O, we've already appeared at a number of events including the Google DevFest Australia and Philippines, PyCon AU, and the Malaysia Open Source Conference, with many more coming this month. There are several well-known large conferences (and many smaller ones too) that our team members will be attending and/or speaking at, so hopefully we'll get to meet you at one of them!

In addition to the ones listed above, Google will be hosting additional DevFests in Asia and South America later this year. Keep an eye out for specific dates and locations on the Google DevFest home page. There are also 5 larger global Google Developer Day events in the fall. We would love to meet with App Engine developers at a DevFest, Developer Day, or any of the other conferences above!

See you around the world!

Posted by Wesley Chun, Google App Engine Team


Wednesday, July 7, 2010

[Gd] Android Love at OSCON

| More

Android Developers Blog: Android Love at OSCON

Android developers who aren't already going should take a moment to check out the OSCON 2010 schedule, and give serious thought to a trip to Portland in a couple of weeks. OSCON is one of the world's premiere events for those who care about Open Source, and one of my personal favorite conferences, with a powerful community vibe. And this year, the Android drums are sounding.

There are a bunch of mobile and Android-related sessions, both pure and extremely impure; for example, I bet both Steve Jobs and I are dubious about Cross-Compiling Android Applications to the iPhone. There's a full-dress Android for Java Developers tutorial. And (the one I helped cook up) there's the Android Hands-On; last I heard, registration for that is approaching 200 and, since O'Reilly found us a big room, it's not full up; but it will be.

On top of which, there are going to be a herd of Googlers at OSCON, and a sub-herd of Androiders, including Dan Morrill and Justin Mattson and me. This isn't surprising; what does surprise me is that OSCON hasn't previously been an Android love-fest. Because if you're interested in mobile devices and have a hankering for Open Source, Android is for you.


[Gd] Upcoming Datastore Downtime

| More

Google App Engine Blog: Upcoming Datastore Downtime

We have two scheduled upcoming maintenance periods for the Datastore:

  • July 7th, 2010 - 5pm-6pm Pacific Time (July 8th, 0:00 GMT) - Later today

  • July 14th, 2010 - 5pm-6pm Pacific Time (July 15th, 0:00 GMT)

As part of our on going Datastore reliability work, we'd like to inform developers that during the period between the two maintenance events listed above, we are expecting that Datastore performance will be impacted and applications will see higher read/write latencies. This maintenance and the higher latency in between are an unfortunate, but necessary step in our long-term plan towards completing the work to address the datastore latency issues (as described in our recent blog post). We recognize the inconvenience to applications and their users caused by this. For this reason, we continue to offer free datastore CPU usage until we are confident we have cleared these issues.

You can read more about the currently scheduled maintenance periods on the notification to the Downtime Notify list. As a reminder, be sure to sign up with the Downtime Notify list for alerts and updates on scheduled (or unplanned) maintenance, and follow @app_engine on Twitter for ongoing announcements.


Tuesday, July 6, 2010

[Gd] Developers Wanted: Help create an open source Wave-based forum

| More

Google Wave Developer Blog: Developers Wanted: Help create an open source Wave-based forum

David Crane is an external Wave developer, involved in the development of the Debatewise extension. We've invited him to post on this blog to share his vision for an open source project.

A few months ago, the Google Wave team open-sourced the code underlying Forum Botty, the robot that is powering the Wave API forum. We want to continue developing this code base into a powerful and generic extension for running forums in wave, and we're hoping that other developers like you will join us in this project.

Google Wave offers a number of benefits over traditional forum software, with just its native functionality. However, by incorporating some of the tried-and-tested features from forums into a robot, we could turn Google Wave into the ultimate platform for forum-based discussion.

A forum could be a killer app for Wave. It’s a tool that people already use in huge numbers for specific purposes, are used to keeping separate to their email, and will dip in and out of as required. Wave is similar enough for them to jump in quickly and different enough for them to get, and be hooked by, the benefits. A forum removes the need for people to find things to use Wave for and means they could use it even if none of their friends did. Wave could enhance and improve upon some of the most important features of a forum and through acclimatisation, will encourage them to use it for a world of other purposes.

There are three specific areas we believe need developing

Goal: Allow people to coalesce around a subject of their choosing and help them find Waves of interest

Tasks: Group waves around subject areas. List the following alongside each Wave title: the total number of blips in the wave (including read/unread), total number of views, date/time of last post and who made the post. Later add ways of rating, sorting and categorising the Wave.

Goal: Encourage and reward participation in the conversations

Tasks: Add karma mechanisms, applause and trophies so Waves, blips and users can be rated. Incorporate tiered participation levels and privileges (eg StackOverflow).

Goal: Develop trust mechanisms so people can determine who to rely upon or ignore

Tasks: Link waves with Google Profiles (or other profiles), display the user’s trophy cabinet, list all posts by user and their ranking in the community

We’re looking for Python, Java and Javascript developers, QA testers and anyone with an interest in forum software, community building and online discussion. All software will be licensed under Apache 2.0, the same open source licence that Google Wave uses.

This project is organised by, a non-profit debating web site whose goal is to be the Wikipedia of debate. Anyone can create a debate on any subject they like and anyone can edit and strengthen that debate. In this way and over time the debates become stronger, more definitive and an ever-greater resource for anyone looking to make up their mind.

If you're interested in joining the project, please wave me at

Posted by David Crane, Debatewise