Friday, November 4, 2011

[Gd] Fridaygram: rock, screech, and roll

| More

The official Google Code blog: Fridaygram: rock, screech, and roll

Author Photo
By Scott Knaster, Google Code Blog Editor

Seems like every few days, Google+ adds a new feature or three. Sometimes the features are small and useful, and sometimes they’re very cool – like the new YouTube playlist feature that automatically finds music from your favorite artists on YouTube and plays it.

Part of the fun of this feature is how easy it is to use. From your Google+ page, mouse over the YouTube button at the top right, click in the box that slides out, and type the name of an artist. Just like that, you have a YouTube playlist from the artist you chose. You can +1 the videos or even share them back to your circles. It’s low friction and very handy.

YouTube in Google+
From left to right: YouTube slider (closed), slider (open), pop-up playlist, slider (while playing)

Not all sounds are pleasant, and one of the worst is that old classic, fingernails on a chalkboard (did you just shudder?). Because science is awesome, scientists have studied exactly what makes this sound so awful. It’s not the high-pitched screech, they found: it’s the mid-range. They think it’s because our ears have evolved to be sensitive to those sounds. And watching it done makes it sound even worse.

Finally, while you’re enjoying your weekend, take a moment to go to and search for do a barrel roll. This one is extra fun for you Star Fox fans.

Fridaygram is not the typical APIs and tools stuff we usually post about here. Instead, we find fun and cool facts and features to tell you about, from Google and other places. And I’m sorry about the screeching thing.

[Gd] Beta Channel Update for Chromebooks

| More

Chrome Releases: Beta Channel Update for Chromebooks

The Beta Channel has been updated to 15.0.874.117 (Platform version: 1011.118) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48)

Release highlights:
  • A number of functionality and stability fixes
  • New trackpad driver
  • Networking fixes
Known issues:
  • Open on the download folder displays an error (21585)
  • Desktop UI:FileBrowser: Click on open downloads folder gives an error "unknown file type" (22375)

If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu.

Josafat Garcia
Google Chrome

[Gd] ACTION REQUIRED: Developer Token Required In Report Downloads Starting 11/23

| More

AdWords API Blog: ACTION REQUIRED: Developer Token Required In Report Downloads Starting 11/23

We would like to announce an important change to the process of downloading reports from the AdWords API that will affect all report downloads for tools built on API versions post v13.  Currently, downloading reports costs no API units and has previously not required a developer token.  To allow us to better monitor usage of reports, we will start requiring a developer token when downloading reports.  Downloading reports will still cost zero API units.

All report downloads - whether they be AdHoc or pre-v201109, using either GET or POST - must provide the developer token as an HTTP header. Example formatting of header:

developerToken: 1a2B3c4D5e_-6v7w8x9y0z

If your application fails to provide the developer token as an HTTP header after November 23rd, it will receive the error message QuotaCheckError.INVALID_TOKEN_HEADER when downloading reports.

We will be publishing updates to the example and utility code in the client libraries to reflect this change.  Please see our report download documentation for more information regarding report downloads.  If you have any questions or would like to discuss this change, please post on the forum or try to attend our Google+ Hangouts with members of the AdWords API Developer Relations Team.

Kevin Winter, AdWords API Team

Thursday, November 3, 2011

[Gd] Dev Channel Update

| More

Chrome Releases: Dev Channel Update

The Dev channel has been updated to 17.0.928.0 for Windows, Mac, Linux, and Chrome Frame.  This build contains the following updates:

  • Updated V8 -
  • Prompt the user if they want to cancel downloads occurring when the last Incognito Window of a profile is closed.
  • Panels are enabled by default (extensions-only, “Tasky” in Web Store is one example)
  • Adjustable margins supported in Print Preview.
  • Mouse Lock “Allow” permission (given via a prompt) is now saved in content settings per domain.
  • Fix the multi-profile selection bubble when using a chrome-theme [r107495]
  • Optimization work to make the GTK+ tabstrip do less redundant painting. Please report any regressions, especially with complex themes. [Issue: 100803]
Known Issues
  • NaCl will not run on Windows
  • Indexed Database: IDBDatabase.transaction() - passing [] as first argument is no longer supported per specification [Issue: 99690]
  • Indexed Database: Databases will fail to load previously created object stores [Issue: 102537].
Full details about what changes are in this build are available in the SVN revision log.  Interested in switching release channels?  Find out how.  If you find a new issue, please let us know by filing a bug.

Dharani Govindan
Google Chrome

[Gd] JNI Local Reference Changes in ICS

| More

Android Developers Blog: JNI Local Reference Changes in ICS

[This post is by Elliott Hughes, a Software Engineer on the Dalvik team. — Tim Bray]

If you don’t write native code that uses JNI, you can stop reading now. If you do write native code that uses JNI, you really need to read this.

What’s changing, and why?

Every developer wants a good garbage collector. The best garbage collectors move objects around. This lets them offer very cheap allocation and bulk deallocation, avoids heap fragmentation, and may improve locality. Moving objects around is a problem if you’ve handed out pointers to them to native code. JNI uses types such as jobject to solve this problem: rather than handing out direct pointers, you’re given an opaque handle that can be traded in for a pointer when necessary. By using handles, when the garbage collector moves an object, it just has to update the handle table to point to the object’s new location. This means that native code won’t be left holding dangling pointers every time the garbage collector runs.

In previous releases of Android, we didn’t use indirect handles; we used direct pointers. This didn’t seem like a problem as long as we didn’t have a garbage collector that moves objects, but it let you write buggy code that still seemed to work. In Ice Cream Sandwich, even though we haven't yet implemented such a garbage collector, we've moved to indirect references so you can start detecting bugs in your native code.

Ice Cream Sandwich features a JNI bug compatibility mode so that as long as your AndroidManifest.xml’s targetSdkVersion is less than Ice Cream Sandwich, your code is exempt. But as soon as you update your targetSdkVersion, your code needs to be correct.

CheckJNI has been updated to detect and report these errors, and in Ice Cream Sandwich, CheckJNI is on by default if debuggable="true" in your manifest.

A quick primer on JNI references

In JNI, there are several kinds of reference. The two most important kinds are local references and global references. Any given jobject can be either local or global. (There are weak globals too, but they have a separate type, jweak, and aren’t interesting here.)

The global/local distinction affects both lifetime and scope. A global is usable from any thread, using that thread’s JNIEnv*, and is valid until an explicit call to DeleteGlobalRef(). A local is only usable from the thread it was originally handed to, and is valid until either an explicit call to DeleteLocalRef() or, more commonly, until you return from your native method. When a native method returns, all local references are automatically deleted.

In the old system, where local references were direct pointers, local references were never really invalidated. That meant you could use a local reference indefinitely, even if you’d explicitly called DeleteLocalRef() on it, or implicitly deleted it with PopLocalFrame()!

Although any given JNIEnv* is only valid for use on one thread, because Android never had any per-thread state in a JNIEnv*, it used to be possible to get away with using a JNIEnv* on the wrong thread. Now there’s a per-thread local reference table, it’s vital that you only use a JNIEnv* on the right thread.

Those are the bugs that ICS will detect. I’ll go through a few common cases to illustrate these problems, how to spot them, and how to fix them. It’s important that you do fix them, because it’s likely that future Android releases will utilize moving collectors. It will not be possible to offer a bug-compatibility mode indefinitely.

Common JNI reference bugs

Bug: Forgetting to call NewGlobalRef() when stashing a jobject in a native peer

If you have a native peer (a long-lived native object corresponding to a Java object, usually created when the Java object is created and destroyed when the Java object’s finalizer runs), you must not stash a jobject in that native object, because it won’t be valid next time you try to use it. (Similar is true of JNIEnv*s. They might be valid if the next native call happens on the same thread, but they won’t be valid otherwise.)

 class MyPeer {
MyPeer(jstring s) {
str_ = s; // Error: stashing a reference without ensuring it’s global.
jstring str_;

static jlong MyClass_newPeer(JNIEnv* env, jclass) {
jstring local_ref = env->NewStringUTF("hello, world!");
MyPeer* peer = new MyPeer(local_ref);
return static_cast<jlong>(reinterpret_cast<uintptr_t>(peer));
// Error: local_ref is no longer valid when we return, but we've stored it in 'peer'.

static void MyClass_printString(JNIEnv* env, jclass, jlong peerAddress) {
MyPeer* peer = reinterpret_cast<MyPeer*>(static_cast<uintptr_t>(peerAddress));
// Error: peer->str_ is invalid!
ScopedUtfChars s(env, peer->str_);
std::cout << s.c_str() << std::endl;

The fix for this is to only store JNI global references. Because there’s never any automatic cleanup of JNI global references, it’s critically important that you clean them up yourself. This is made slightly awkward by the fact that your destructor won’t have a JNIEnv*. The easiest fix is usually to have an explicit ‘destroy‘ function for your native peer, called from the Java peer’s finalizer:

 class MyPeer {
MyPeer(JNIEnv* env, jstring s) {
this->s = env->NewGlobalRef(s);
~MyPeer() {
assert(s == NULL);
void destroy(JNIEnv* env) {
s = NULL;
jstring s;

You should always have matching calls to NewGlobalRef()/DeleteGlobalRef(). CheckJNI will catch global reference leaks, but the limit is quite high (2000 by default), so watch out.

If you do have this class of error in your code, the crash will look something like this:

    JNI ERROR (app bug): accessed stale local reference 0x5900021 (index 8 in a table of size 8)
JNI WARNING: jstring is an invalid local reference (0x5900021)
in LMyClass;.printString:(J)V (GetStringUTFChars)
"main" prio=5 tid=1 RUNNABLE
| group="main" sCount=0 dsCount=0 obj=0xf5e96410 self=0x8215888
| sysTid=11044 nice=0 sched=0/0 cgrp=[n/a] handle=-152574256
| schedstat=( 156038824 600810 47 ) utm=14 stm=2 core=0
at MyClass.printString(Native Method)
at MyClass.main(

If you’re using another thread’s JNIEnv*, the crash will look something like this:

 JNI WARNING: threadid=8 using env from threadid=1
in LMyClass;.printString:(J)V (GetStringUTFChars)
"Thread-10" prio=5 tid=8 NATIVE
| group="main" sCount=0 dsCount=0 obj=0xf5f77d60 self=0x9f8f248
| sysTid=22299 nice=0 sched=0/0 cgrp=[n/a] handle=-256476304
| schedstat=( 153358572 709218 48 ) utm=12 stm=4 core=8
at MyClass.printString(Native Method)
at MyClass$

Bug: Mistakenly assuming FindClass() returns global references

FindClass() returns local references. Many people assume otherwise. In a system without class unloading (like Android), you can treat jfieldID and jmethodID as if they were global. (They’re not actually references, but in a system with class unloading there are similar lifetime issues.) But jclass is a reference, and FindClass() returns local references. A common bug pattern is “static jclass”. Unless you’re manually turning your local references into global references, your code is broken. Here’s what correct code should look like:

 static jclass gMyClass;
static jclass gSomeClass;

static void MyClass_nativeInit(JNIEnv* env, jclass myClass) {
// ‘myClass’ (and any other non-primitive arguments) are only local references.
gMyClass = env->NewGlobalRef(myClass);

// FindClass only returns local references.
jclass someClass = env->FindClass("SomeClass");
if (someClass == NULL) {
return; // FindClass already threw an exception such as NoClassDefFoundError.
gSomeClass = env->NewGlobalRef(someClass);

If you do have this class of error in your code, the crash will look something like this:

    JNI ERROR (app bug): attempt to use stale local reference 0x4200001d (should be 0x4210001d)
JNI WARNING: 0x4200001d is not a valid JNI reference
in LMyClass;.useStashedClass:()V (IsSameObject)

Bug: Calling DeleteLocalRef() and continuing to use the deleted reference

It shouldn’t need to be said that it’s illegal to continue to use a reference after calling DeleteLocalRef() on it, but because it used to work, so you may have made this mistake and not realized. The usual pattern seems to be where native code has a long-running loop, and developers try to clean up every single local reference as they go to avoid hitting the local reference limit, but they accidentally also delete the reference they want to use as a return value!

The fix is trivial: don’t call DeleteLocalRef() on a reference you’re going to use (where “use” includes “return”).

Bug: Calling PopLocalFrame() and continuing to use a popped reference

This is a more subtle variant of the previous bug. The PushLocalFrame() and PopLocalFrame() calls let you bulk-delete local references. When you call PopLocalFrame(), you pass in the one reference from the frame that you’d like to keep (typically for use as a return value), or NULL. In the past, you’d get away with incorrect code like the following:

 static jobjectArray MyClass_returnArray(JNIEnv* env, jclass) {
jobjectArray array = env->NewObjectArray(128, gMyClass, NULL);
for (int i = 0; i < 128; ++i) {
env->SetObjectArrayElement(array, i, newMyClass(i));
env->PopLocalFrame(NULL); // Error: should pass 'array'.
return array; // Error: array is no longer valid.

The fix is generally to pass the reference to PopLocalFrame(). Note in the above example that you don’t need to keep references to the individual array elements; as long as the GC knows about the array itself, it’ll take care of the elements (and any objects they point to in turn) itself.

If you do have this class of error in your code, the crash will look something like this:

  JNI ERROR (app bug): accessed stale local reference 0x2d00025 (index 9 in a table of size 8)
JNI WARNING: invalid reference returned from native code
in LMyClass;.returnArray:()[Ljava/lang/Object;

Wrapping up

Yes, we asking for a bit more attention to detail in your JNI coding, which is extra work. But we think that you’ll come out ahead on the deal as we roll in better and more sophisticated memory management code.


[Gd] Build great font tools and services with sfntly

| More

The official Google Code blog: Build great font tools and services with sfntly

Author Photo
By Stuart Gill, sfntly Architect

Today we’re releasing the sfntly font programming library as open source. Created by the Google Internationalization Engineering team, the sfntly Java and C++ library makes it easy for programmers to build high performance font manipulation applications and services. sfntly is really, really fast: Raph Levien, Google Web Fonts Engineer, says, "Using sfntly we can subset a large font in a millisecond. It’s faster than gzip'ing the result."

Starting today, both Java and C++ programmers can use sfntly to quickly and easily develop code to read, edit, and subset OpenType and TrueType fonts. The Google Web Fonts team uses the Java version to dynamically subset fonts, and the Chrome/Chromium browser uses the C++ version to subset fonts for PDF printing.

sfntly (\s-’font-lē\) was built from the ground up to provide high performance, an easy to use API, and both high-level and low-level access to font data. Font objects are both thread safe and high performance while still providing access for editing. After about a year of internal development sfntly is stable enough to move it into open source and share with others.

Currently, sfntly has editing support for most core TrueType and OpenType tables, with support for more tables being added. Using sfntly’s basic sfnt table read and write capability, programmers can do basic manipulation of any of the many font formats that use the sfnt container, including TrueType, OpenType, AAT/GX, and Graphite. Tables that aren’t specifically supported can still be handled and round-tripped by the library without risk of corruption.

sfntly is already capable of allowing many really exciting things to be done with fonts, but there is much more planned: expanding support for the rest of the OpenType spec and other sfnt-container font formats, other serialization forms, better higher level abstractions, and more.

I encourage you to you join us on our journey as a user or a contributor.

Stuart Gill is a Software Engineer in the Internationalization Engineering team at Google where he focuses on fonts and text. When not doing that he is playing the blues on his guitar, studying Japanese, or puttering about the house and garage.

Posted by Scott Knaster, Editor

[Gd] Beta Channel Update

| More

Chrome Releases: Beta Channel Update

The Beta channel has been updated to 16.0.912.21 for Windows, Mac, Linux, and Chrome Frame. 

For an overview of key features in this release check out the Google Chrome Blog.  Interested in switching to the Beta or Stable channels?  Find out how.  If you find a new issue, please let us know by filing a bug.

Anthony Laforge
Google Chrome

[Gd] GET, POST, and safely surfacing more of the web

| More

Official Google Webmaster Central Blog: GET, POST, and safely surfacing more of the web

Webmaster Level: Intermediate to Advanced

As the web evolves, Google’s crawling and indexing capabilities also need to progress. We improved our indexing of Flash, built a more robust infrastructure called Caffeine, and we even started crawling forms where it makes sense. Now, especially with the growing popularity of JavaScript and, with it, AJAX, we’re finding more web pages requiring POST requests -- either for the entire content of the page or because the pages are missing information and/or look completely broken without the resources returned from POST. For Google Search this is less than ideal, because when we’re not properly discovering and indexing content, searchers may not have access to the most comprehensive and relevant results.

We generally advise to use GET for fetching resources a page needs, and this is by far our preferred method of crawling. We’ve started experiments to rewrite POST requests to GET, and while this remains a valid strategy in some cases, often the contents returned by a web server for GET vs. POST are completely different. Additionally, there are legitimate reasons to use POST (e.g., you can attach more data to a POST request than a GET). So, while GET requests remain far more common, to surface more content on the web, Googlebot may now perform POST requests when we believe it’s safe and appropriate.

We take precautions to avoid performing any task on a site that could result in executing an unintended user action. Our POSTs are primarily for crawling resources that a page requests automatically, mimicking what a typical user would see when they open the URL in their browser. This will evolve over time as we find better heuristics, but that’s our current approach.

Let’s run through a few POSTs request scenarios that demonstrate how we’re improving our crawling and indexing to evolve with the web.

Examples of Googlebot’s POST requests
  • Crawling a page via a POST redirect
  • <html>
      <body onload=";">
        <form name="foo" action="request.php" method="post">
          <input type="hidden" name="bar" value="234"/>

  • Crawling a resource via a POST XMLHttpRequest
    In this step-by-step example, we improve both the indexing of a page and its Instant Preview by following the automatic XMLHttpRequest generated as the page renders.

    1. Google crawls the URL, yummy-sundae.html.
    2. Google begins indexing yummy-sundae.html and, as a part of this process, decides to attempt to render the page to better understand its content and/or generate the Instant Preview.
    3. During the render, yummy-sundae.html automatically sends an XMLHttpRequest for a resource, hot-fudge-info.html, using the POST method.
          <title>Yummy Sundae</title>
          <script src="jquery.js"></script>
          This page is about a yummy sundae.
          <div id="content"></div>
          <script type="text/javascript">
            $(document).ready(function() {
              $.post('hot-fudge-info.html', function(data)
    4. The URL requested through POST, hot-fudge-info.html, along with its data payload, is added to Googlebot’s crawl queue.
    5. Googlebot performs a POST request to crawl hot-fudge-info.html.
    6. Google now has an accurate representation of yummy-sundae.html for Instant Previews. In certain cases, we may also incorporate the contents of hot-fudge-info.html into yummy-sundae.html.
    7. Google completes the indexing of yummy-sundae.html.
    8. User searches for [hot fudge sundae].
    9. Google’s algorithms can now better determine how yummy-sundae.html is relevant for this query, and we can properly display a snapshot of the page for Instant Previews.
Improving your site’s crawlability and indexability
General advice for creating crawlable sites is found in our Help Center. For webmasters who want to help Google crawl and index their content and/or generate the Instant Preview, here are a few simple reminders:
  • Prefer GET for fetching resources, unless there’s a specific reason to use POST.

  • Verify that we're allowed to crawl the resources needed to render your page. In the example above, if hot-fudge-info.html is disallowed by robots.txt, Googlebot won't fetch it. More subtly, if the JavaScript code that issues the XMLHttpRequest is located in an external .js file disallowed by robots.txt, we won't see the connection between yummy-sundae.html and hot-fudge-info.html, so even if the latter is not disallowed itself, that may not help us much. We've seen even more complicated chains of dependencies in the wild. To help Google better understand your site it's almost always better to allow Googlebot to crawl all resources.

    You can test whether resources are blocked through Webmaster Tools “Labs -> Instant Previews.”

  • Make sure to return the same content to Googlebot as is returned to users’ web browsers. Cloaking (sending different content to Googlebot than to users) is a violation of our Webmaster Guidelines because, among other things, it may cause us to provide a searcher with an irrelevant result -- the content the user views in their browser may be a complete mismatch from what we crawled and indexed. We’ve seen numerous POST-request examples where a webmaster non-maliciously cloaked (which is still a violation), and their cloaking -- on even the smallest of changes -- then caused JavaScript errors that prevented accurate indexing and completely defeated their reason for cloaking in the first place. Summarizing, if you want your site to be search-friendly, cloaking is an all-around sticky situation that’s best to avoid.

    To verify that you're not accidentally cloaking, you can use Instant Previews within Webmaster Tools, or try setting the User-Agent string in your browser to something like:

    Mozilla/5.0 (compatible; Googlebot/2.1;

    Your site shouldn't look any different after such a change. If you see a blank page, a JavaScript error, or if parts of the page are missing or different, that means that something's wrong.

  • Remember to include important content (i.e., the content you’d like indexed) as text, visible directly on the page and without requiring user-action to display. Most search engines are text-based and generally work best with text-based content. We’re always improving our ability to crawl and index content published in a variety of ways, but it remains a good practice to use text for important information.
Controlling your content
If you’d like to prevent content from being crawled or indexed for Google Web Search, traditional robots.txt directives remain the best method. To prevent the Instant Preview for your page(s), please see our Instant Previews FAQ which describes the “Google Web Preview” User-Agent and the nosnippet meta tag.

Moving forward
We’ll continue striving to increase the comprehensiveness of our index so searchers can find more relevant information. And we expect our crawling and indexing capability to improve and evolve over time, just like the web itself. Please let us know if you have questions or concerns.

Written by , Software Engineer, Indexing Team, and , Developer Programs Tech Lead

[Gd] Raising awareness of cross-domain URL selections

| More

Official Google Webmaster Central Blog: Raising awareness of cross-domain URL selections

Webmaster level: Advanced

A piece of content can often be reached via several URLs, not all of which may be on the same domain. A common example we’ve talked about over the years is having the same content available on more than one URL, an issue known as duplicate content. When we discover a group of pages with duplicate content, Google uses algorithms to select one representative URL for that content. A group of pages may contain URLs from the same site or from different sites. When the representative URL is selected from a group with different sites the selection is called a cross-domain URL selection. To take a simple example, if the group of URLs contains one URL from and one URL from and our algorithms select the URL from, the URL may no longer be shown in our search results and may see a drop in search-referred traffic.

Webmasters can greatly influence our algorithms’ selections using one of the currently supported mechanisms to indicate the preferred URL, for example using rel="canonical" elements or 301 redirects. In most cases, the decisions our algorithms make in this regard correctly reflect the webmaster’s intent. However, in some rare cases we’ve also found many webmasters are confused as to why it has happened and what they can do if they believe the selection is incorrect.

To be transparent about cross-domain URL selection decisions, we’re launching new Webmaster Tools messages that will attempt to notify webmasters when our algorithms select an external URL instead of one from their website. The details about how these messages work are in our Help Center article about the topic, and in this blog post we’ll discuss the different scenarios in which you may see a cross-domain URL selection and what you can do to fix any selections you believe are incorrect.

Common causes of cross-domain URL selection

There are many scenarios that can lead our algorithms to select URLs across domains.

In most cases, our algorithms select a URL based on signals that the webmaster implemented to influence the decision. For example, a webmaster following our guidelines and best practices for moving websites is effectively signalling that the URLs on their new website are the ones they prefer for Google to select. If you’re moving your website and see these new messages in Webmaster Tools, you can take that as confirmation that our algorithms have noticed.

However, we regularly see webmasters ask questions when our algorithms select a URL they did not want selected. When your website is involved in a cross-domain selection, and you believe the selection is incorrect (i.e. not your intention), there are several strategies to improve the situation. Here are some of the common causes of unexpected cross-domain URL selections that we’ve seen, and how to fix them:

  1. Duplicate content, including multi-regional websites: We regularly see webmasters use substantially the same content in the same language on multiple domains, sometimes inadvertently and sometimes to geotarget the content. For example, it’s common to see a webmaster set up the same English language website on both and, or a German language website hosted on,, and

    Depending on your website and your users, you can use one of the currently-supported canonicalization techniques to signal to our algorithms which URLs you wish selected. Please see the following articles about this topic:

  2. Configuration mistakes: Certain types of misconfigurations can lead our algorithms to make an incorrect decision. Examples of misconfiguration scenarios include:
    1. Incorrect canonicalization: Incorrect usage of canonicalization techniques pointing to URLs on an external website can lead our algorithms to select the external URLs to show in our search results. We’ve seen this happen with misconfigured content management systems (CMS) or CMS plugins installed by the webmaster.

      To fix this kind of situation, find how your website is incorrectly indicating the canonical URL preference (e.g. through incorrect usage of a rel="canonical" element or a 301 redirect) and fix that.

    2. Misconfigured servers: Sometimes we see hosting misconfigurations where content from site is returned for URLs on A similar case occurs when two unrelated web servers return identical soft 404 pages that we may fail to detect as error pages. In both situations we may assume the same content is being returned from two different sites and our algorithms may incorrectly select the URL as the canonical of the URL.

      You will need to investigate which part of your website’s serving infrastructure is misconfigured. For example, your server may be returning HTTP 200 (success) status codes for error pages, or your server might be confusing requests across different domains hosted on it. Once you find the root cause of the issue, work with your server admins to correct the configuration.

  3. Malicious website attacks: Some attacks on websites introduce code that can cause undesired canonicalization. For example, the malicious code might cause the website to return an HTTP 301 redirect or insert a cross-domain rel="canonical" link element into the HTML <head> or HTTP header, usually pointing to an external URL hosting malicious content. In these cases our algorithms may select the malicious or spammy URL instead of the URL on the compromised website.

    In this situation, please follow our guidance on cleaning your site and submit a reconsideration request when done. To identify cloaked attacks, you can use the Fetch as Googlebot function in Webmaster Tools to see your page’s content as Googlebot sees it.

In rare situations, our algorithms may select a URL from an external site that is hosting your content without your permission. If you believe that another site is duplicating your content in violation of copyright law, you may contact the site’s host to request removal. In addition, you can request that Google remove the infringing page from our search results by filing a request under the Digital Millennium Copyright Act.

And as always, if you need help in identifying the cause of an incorrect decision or how to fix it, you can see our Help Center article about this topic and ask in our Webmaster Help Forum.

Posted by , Webmaster Trends Analyst


[Gd] Upcoming change in the “Slot” field for reports

| More

AdWords API Blog: Upcoming change in the “Slot” field for reports

As part of our updates to the design and experience of Google Search and all of our other products, we are introducing new ad placements on Google Search. This will result in a visible change on the “Display Name” and “XML Attribute” values of the “Slot” field in the following reports:
  • Account Performance
  • Ad Performance
  • Ad Extension Performance
  • Ad Group Performance
  • Campaign Performance
  • Criteria
  • Destination URL
  • Keywords Performance
  • Managed Placements Performance
After this change, “Display Name” will change from “Top vs. side” to “Top vs. other” and “XML Attribute” from “topVsSide” to “topVsOther”. Also all current statistics reported as “SearchRhs / Google search: Side” will get merged into “SearchOther / Google search: Other” numbers.If your reporting code relies on the “Slot” field, plan accordingly to support this change, which is scheduled to happen on November 8th.If you have any questions regarding this change please post them on the forum.

 David Torres, AdWords API Team

[Gd] Client Library Updates

| More

AdWords API Blog: Client Library Updates

We have recently released new versions of the AdWords API client libraries to support v201109 and AdHoc reports.  Please see below for a summary of changes for each library.

  • Support for v201109 was added along with utility code for AdHoc reports in v8.4.0.
  • Released reference implementation to download reports for lots of client accounts.
  • Support for v201109 was added along with utility code for AdHoc reports in v13.0.0.
  • Project hosting has moved here.
  • Support for v201109 was added along with utility code for AdHoc reports in v15.0.3.
  • Updated common module from version 2.1.0 to version 3.0.0, which may impact your code.  See the ChangeLog for more details.
  • Support for v201109 was added along with utility code for AdHoc reports in v0.4.1.
  • Now properly handles xsi:type in XML responses.
  • Support for v201109 was added along with utility code for AdHoc reports in v2.5.0.
  • Support for v201109 was added along with utility code for AdHoc reports in v2.7.0.
  • Bug fixes and minor improvements.
  • Support for v201109 was added along with an example for AdHoc reports in v1.1.0.
You can download updated versions of the AdWords API client libraries from their respective sites, or see a list of all the client libraries.
If you have any questions or would like to discuss these changes, please post on the forum.

Kevin Winter, AdWords API Team

[Gd] 120 days until deprecation deadline

| More

AdWords API Blog: 120 days until deprecation deadline

As we announced last month, with the release of AdWords API v201109, we will be deprecating the following versions and services:
  • API versions v13, v200909, v201003, v201008, v201101*
  • API version v13 AccountService will only be available on a whitelist basis.
*Note: We are not supporting cross-client reports in this release, but we have released some sample code for single account reporting across many clients.

We will be sunsetting these versions and services on February 29, 2012.

To help with the migration, we’ll be running a “Discover v201109” blog series, as well as hosting Google+ Hangouts with members of the AdWords API Developer Relations Team.

In addition, as with every new version of the AdWords API, we encourage you to review the resources in the AdWords API client libraries. If you have any questions please post them on the AdWords API forum.
Posted by Katie Miller, AdWords API Team

Wednesday, November 2, 2011

[Gd] Interview with Polish Type Designer Ania Kruk

| More

Google Web Fonts: Interview with Polish Type Designer Ania Kruk

Ania Kruk is a type designer from Poznan, Poland. She currently lives and works in Barcelona and Google Web Fonts is proud to include her first published typeface, Cookie.

Q: What is your background as a designer, and how did you become interested in type design?

Actually, I'm still a beginner in the world of type design: I have drawn letters for only 2 years. I've recently graduated from the University of Arts in Poznan, Poland. Originally, I studied product design, but after 3 years I found myself more interested in graphics than in furniture.

So I took a one year break and moved to Barcelona, Spain, where I worked as an intern in Estudio Mariscal (which was quite an experience, as they were working on the 'Chico y Rita' movie at that time), and did a one-year Masters in Typography and Editorial Design at Eina, Escola de Disseny i Art.

When I came back to Poland for my last year of studies, I was 100% sure that I wanted to focus on type design.
And here I am now, 3 months after my graduation, with my first typeface to be published: Cookie :)

Q: What is your favourite part of the type design process, and why?

Generally, I'm interested in complex, narrative projects that require creating a whole from various elements (meaning: editorial design, information design, typography). Type Design is not about designing one letter, it's about creating a system: the alphabet.

I like the moment when you can start writing words and sentences with your letters, because then you can actually work on the flow and on the balance between the characters. For example, to make some of them more 'normal', transparent, in order to make others more distinctive or decorative.

Q: Designing a new typeface is a long journey. What inspires you to keep motivated throughout all the different stages?

For sure, Type Design is all about details, that an average user won't even notice, so you need to be patient to do this kind of work. I'd say I'm quite competitive, so when I see other peoples projects and I think 'Wow, that's so cool!', it get's me motivated ;) I spend an awful amount of time digging through the internet, checking out blogs, personal websites, etc.

Q: Can you recommend how other type designers can learn the skills involved in making type?

It's hard to say, because I'm still learning myself. But I'd say that calligraphy and drawing are essential to understanding the construction of the letters.

Q: What do you think could be improved about the type design process?

For me the hard part is hinting ;)

Q: What inspired you to create Cookie?

Cookie is a script typeface, based on brush calligraphy. It has a little bit of the 1950s look, that makes you think about all the beautiful ads and pin-ups from this time. It's sweet and friendly - but not too decorative. I tried to keep it simple and legible.

Q: Did you try to accomplish something specific with this typeface design, and did you succeed?

It's my first script typeface, so the whole design process was like discovering a new way of working. I wanted to create a typeface with a nice flow between the letters, and I wanted the letters to join in a natural way - that's the tough part, if you think about all the possible combinations between 26 lowercase characters. I hope it works ok...!

Q: What kinds of uses are most appropriate for this font?

Its clearly a display typeface, suitable more for titles than main texts. But it can be used for short texts, if you're aiming for a hand-written look. It will look good on an invitation, menu, recipe... poster, flyer or as a header of your blog :)

Q: What are your favourite fonts, and why?

Well, I don't really have any favourites. It all depends on the context and what you want to communicate: a typeface can be perfect for one kind of a job, but look horrible when misused.

There are some surprises: I've always considered Mistral by Roger Excoffon as very kitsch and ugly, until I've seen it in on the opening credits for the movie 'Drive'. It looked just great, combined with the music and pictures.

Posted by Dave Crossland, Font Consultant, Google Web Fonts

[Gd] Hangout with us: AdWords API Office Hours

| More

AdWords API Blog: Hangout with us: AdWords API Office Hours

Google+ Hangouts have proven to be a great way to connect people and engage with an audience, something the Google Developer Relations team is very passionate about. In that spirit we’re going to start holding office hours for the AdWords API using Hangouts, the first of which will be on November 16th from 1-2PM EST (10-11AM PST). Unlike our workshop events which have agendas prepared beforehand, these office hours will be entirely focused on your questions and feedback, so please come prepared with any technical or implementation topics you’d like to discuss. With the v201109 release and the reports migration we’re confident there will be plenty to talk about.

To join the hangout you’ll need to have a Google+ account (sign up here) and the Google voice and video plugin installed (download available for Windows, Mac, and Linux). Hangouts are currently limited to ten people at a time, so if you aren’t able to join right away please try again later in the hour as a slot may have opened up. Additional information about Hangouts is available in the Google+ Help Center.

Let us know you’re planning to attend by clicking the “I’ll be there” button on the page for this event. We’re still deciding how often to hold office hours, so if you’d like to see more of them make sure you show your support by registering and attending. Plans for sessions in Europe and Asia-friendly timezones are also in the works, so stay tuned for more details. We look forward to talking with you face-to-face, but until then you can reach us on the AdWords API forum with any comments or questions.

- , AdWords API Team


Tuesday, November 1, 2011

[Gd] Dev Channel Update

| More

Chrome Releases: Dev Channel Update

The Dev channel has been updated to 16.0.912.21 for Windows, Mac, Linux, and Chrome Frame. This release contains stability fixes. Full details about what changes are in this build are available in the SVN revision log. Interested in switching to the Beta or Stable channels?  Find out how.  If you find a new issue, please let us know by filing a bug.

Dharani Govindan
Google Chrome

[Gd] Android 4.0 Graphics and Animations

| More

Android Developers Blog: Android 4.0 Graphics and Animations

[This post is by Romain Guy and Chet Haase, Android engineers who have been known to collaborate on the subject of graphics, UIs, and animation. You can read more from them on their blogs at and — Tim Bray]

Earlier this year, Android 3.0 launched with a new 2D rendering pipeline designed to support hardware acceleration on tablets. With this new pipeline, all drawing operations performed by the UI toolkit are carried out using the GPU.

You’ll be happy to hear that Android 4.0, Ice Cream Sandwich, brings an improved version of the hardware-accelerated 2D rendering pipeline to phones, starting with Galaxy Nexus.

Enabling hardware acceleration

In Android 4.0 (API level 14), hardware acceleration, for the first time, is on by default for all applications. For applications at lower API levels, you can turn it on by adding android:hardwareAccelerated="true" to the <application> tag in your AndroidManifest.xml.

To learn more about the hardware accelerated 2D rendering pipeline visit the official Android developer guide. This guide explains how to control hardware acceleration at various levels, offers several performance tips and tricks and describes in details the new drawing model.

I also encourage you to watch the Android Hardware Accelerated Rendering talk that we gave at Google I/O 2010.

Introducing TextureView

Applications that need to display OpenGL or video content rely today on a special type of UI element called SurfaceView. This widget works by creating a new window placed behind your application’s window. It then punches a hole through your application’s window to reveal the new window. While this approach is very efficient, since the content of the new window can be refreshed without redrawing the application’s window, it suffers from several important limitations.

Because a SurfaceView’s content does not live in the application’s window, it cannot be transformed (moved, scaled, rotated) efficiently. This makes it difficult to use a SurfaceView inside a ListView or a ScrollView. SurfaceView also cannot interact properly with some features of the UI toolkit such as fading edges or View.setAlpha().

To solve these problems, Android 4.0 introduces a new widget called TextureView that relies on the hardware accelerated 2D rendering pipeline and SurfaceTexture. TextureView offers the same capabilities as SurfaceView but, unlike SurfaceView, behaves as a regular view. You can for instance use a TextureView to display an OpenGL scene or a video stream. The TextureView itself can be animated, scrolled, etc.

The following piece of code creates a TextureView to display the video preview from the default camera. The TextureView itself is rotated 45 degrees and semi-transparent.

public class TextureViewActivity extends Activity implements TextureView.SurfaceTextureListener {
private Camera mCamera;
private TextureView mTextureView;

protected void onCreate(Bundle savedInstanceState) {

mTextureView = new TextureView(this);


public void onSurfaceTextureAvailable(SurfaceTexture surface, int width, int height) {
mCamera =;

Camera.Size previewSize = mCamera.getParameters().getPreviewSize();
mTextureView.setLayoutParams(new FrameLayout.LayoutParams(
previewSize.width, previewSize.height, Gravity.CENTER));

try {
} catch (IOException t) {



public void onSurfaceTextureSizeChanged(SurfaceTexture surface, int width, int height) {
// Ignored, the Camera does all the work for us

public boolean onSurfaceTextureDestroyed(SurfaceTexture surface) {
return true;

public void onSurfaceTextureUpdated(SurfaceTexture surface) {
// Called whenever a new frame is available and displayed in the TextureView

A TextureView can just as easily be used to embed an OpenGL scene in your application. As of Android 4.0, eglCreateWindowSurface() can be used to render into a SurfaceTexture object.


There were minor improvements in Android 4.0 to some of the new animation facilities that were added in the 3.x releases.

First, if you're new to the new android.animation package and classes added in 3.0 and 3.1, you might want to read Animation in Honeycomb and Introducing ViewPropertyAnimator. These articles discuss the new APIs added in 3.0 that make animation in Android easier, more powerful, and more flexible. The Android 4.0 improvements discussed below are small additions to these core facilities.


One of the constraints of the Java programming language is the lack of “properties”. There is no way to refer generically to a field or a setter/getter of an object. As long as you know what kind of object you have, this is not a problem, because you then know the set of fields and methods that you can call. But if someone passes you some subclass of Object and you'd like to get or set some value “foo” on it, you're out of luck. You can use reflection or JNI to get access to the foo field/methods, but there is no way to refer directly to a field or a method unless you know the instance type of the object that has that field/method on it.

This is a constraint that the new animation system works within. Its whole job, you might say, is to get and set values on generic objects that it's been told about. If someone wants to animate the alpha property on a View, they tell the system the target object and the name of that field (“alpha”), and the animation system uses JNI to figure out which method(s) act on a field of that name. Basically, it looks for setAlpha() and, sometimes, getAlpha() methods. Then when an animation frame occurs, it calculates the new value and passes it into the setter method that it found.

This seems like a lot of work for what it does, but there's really no way around it. Unless the animation system were specific to View objects, there's no way that it could know that the target object has appropriate setter/getter methods. And even if it did, there's still no way for callers that construct the animations to tell the animator about the property named “alpha”; there are no function handles like there are in other languages, and there's no way to reference a public field either. (I'm ignoring Reflection here, which has Method and Field objects, because this approach requires much more overhead and processing than the simple function/field references of other languages).

If only there were a way to refer to these properties and to get/set them on generic objects...

Now there is. There is a new Property object in the android.util package that does exactly this. This class offers a set() and a get() method. So if someone hands you a Property object, you can safely call the set() and get() methods without knowing anything about the target object and it will do the job. Moreover, it will do it much more efficiently than the current JNI or reflection approaches because it can, depending on the implementation of it, set a field or call a method on the target object directly. For example, the new ALPHA property on View calls setAlpha() on the View object.

The Property class is a generic utility that can be used anywhere, not just in animations. But it's animations that benefit enormously from it, in their ability to handle properties in a type-safe and efficient manner.

For example prior to Android 4.0, you might construct a fade-out animation on some object myView like this:

ObjectAnimator anim = ObjectAnimator.ofFloat(myView, "alpha", 0);

In Android 4.0, you can use the new ALPHA object on View to construct a Property-based animator instead:

ObjectAnimator anim = ObjectAnimator.ofFloat(myView, View.ALPHA, 0);

ViewPropertyAnimator Additions

There were minor API additions to the ViewPropertyAnimator class (introduced in Android 3.1) which make this class more flexible and powerful:

  • cancel(): You can now cancel() a running ViewPropertyAnimator.

  • setStartDelay(): You can now set a startDelay on the ViewPropertyAnimator, just like the startDelay of the other Animator classes.

  • start(): ViewPropertyAnimators start automatically, but they do so on the next animation frame handled. This allows them to collect several requests and bundle them together, which is much more efficient and makes it easier to synchronize multiple animations together. However, if you just want to run a single animation, or want to make sure it starts immediately, at the time of construction, you can call start() to avoid that intervening delay.


LayoutTransition (introduced in Android 3.0) continues to provide functionality that makes some kinds of animations easier, specifically when adding, removing, hiding, and showing views. For example, either this snippet in a layout file:


Or this code added at runtime:

 container.setLayoutTransition(new LayoutTransition());

will result in a container that animates the visibility of its children views. So when a view is added to the container, the other children will animate out of the way and then the new one will fade in. Similarly, removing a child from the container will fade it out and then animate the other children around to their final places and sizes.

You can customize the animations and timing behavior of a LayoutTransition object, but the code above allows a very easy way to get reasonable default animation behavior.

One of the constraints in the pre-4.0 version of the class was that it did not account for changes in the bounds of the parent hierarchy. So, for example, if a LinearLayout with horizontal orientation has a layout_width of wrap_content and you want to run a transition that removes an item from that layout, then you might notice the parent snapping to the end size and clipping its children instead of animating all of them into their new positions. The new approach (enabled by default, but disabled by a call to setAnimateParentHierarchy(false)) also animates the layout bounds and scrolling values of the parent layout and its parents, all the way up the view hierarchy. This allows LayoutTransition to account for all layout-related changes due to that view being added or removed from its transitioning container.


The Android 3.0 release saw huge improvements in the visual capabilities of the platform, as we started enabling hardware acceleration and providing new, more flexible animation capabilities. Android 4.0 continues this trend as we continue to work hard on improving the performance, features, and usability of the Android APIs. We’re not done yet, but the enhancements in this release should help you create more exciting Android experiences and applications.