Make the Location is Allowed link take the Geo Header into account.

chrome/browser/search_engines/template_url_service_android.cc

Index: chrome/browser/search_engines/template_url_service_android.cc
diff --git a/chrome/browser/search_engines/template_url_service_android.cc b/chrome/browser/search_engines/template_url_service_android.cc
index 7b64168fc9f6388e58c970dfd6ac0fb85efb5cb4..ec59259746309745e1505452e2196b8b54a8d36d 100644
--- a/chrome/browser/search_engines/template_url_service_android.cc
+++ b/chrome/browser/search_engines/template_url_service_android.cc
@@ -253,7 +253,7 @@ TemplateUrlServiceAndroid::GetSearchEngineUrlFromTemplateUrl(
   TemplateURL* template_url = template_url_service_->GetTemplateURLs()[index];
   std::string url(template_url->url_ref().ReplaceSearchTerms(
       TemplateURLRef::SearchTermsArgs(
-          base::string16()), SearchTermsData(), nullptr));
+          base::ASCIIToUTF16("query")), SearchTermsData(), nullptr));

[Finnur, 2015/04/22 11:12:59]

This might seem counter-intuitive, but is needed because the functions that
verify if a string is a Google search query don't work unless there's an actual
query in there. None of the callers care about the precise value returned, so
this should have no other effect.

[Maria, 2015/04/22 19:26:30]

I do think that this behaviour is unexpected. There seems to be a mismatch
between what the GeoHeader function is expecting (a fully formed Google search
URL) and what we were providing to preferences (a "canonical" form of the URL). 

It's also not clear to me that the change won't have any effect. It seems like
the native code in website_preference_bridge::SetSettingForOrigin may be
affected (it's a bit difficult for me to determine).

IMO, we should instead fix the check in geo settings to accept this format
rather than make this change here.

[Finnur, 2015/04/24 15:49:19]

Hmm... Here's how I see it...

I created this function and my code is the only consumer of it. Side note: I
don't see how website_preference_bridge::SetSettingForOrigin is related, but if
I'm mistaken I'd be interested in your findings there.

Anway, the whole purpose of this function was to supply an example search URL
for a given template URL but today it provides an *invalid* search URL (because
the query part is missing). I am fixing it to provide a valid example URL. Keep
in mind that neither version would be used for actual queries.
I don't see why/how the geo settings code should change to accommodate an
invalid search URL. One could make the argument that the check itself
(IsGoogleSearchURL) would have to change. Two problems there:

1) We'd be changing it to say that a malformed search url is valid.
2) this check is implemented in google_util.cc, and that function is used
throughout both C++ and Java code, including:

voice_search_tab_helper.cc
google_search_counter.cc
safe_search_util.cc
rlz.cc
TemplateUrlServiceAndroid::GetUrlForVoiceSearchQuery
TemplateUrlServiceAndroid::GetUrlForContextualSearchQuery

... to name a few (probably not an exhaustive list). I don't know if any of
these functions *rely* on the check returning false for invalid search urls
(that are missing the query part).

But given the fact that I'm the only consumer of this function, I'd rather
change it and live with breaking my code than change the google_util check and
create a much worse problem in some other people's code.

[Finnur, 2015/04/29 14:54:09]

I've changed it so that the only time we use the full URL is when we pass it to
the x-geo check. This should eliminate some of the concerns and demonstrate that
the change in query string isn't material except when dealing with x-geo.

   return base::android::ConvertUTF8ToJavaString(env, url);
 }