How to supply location with an AdRequest now that AdMob has become part of the Google Play Services?

Question

With the October update of the Google Play Services, AdMob was integrated into the library, which means Android developers no longer have to include the GoogleAdMobAdsSdk-x.x.x.jar in a project's libs folder. There's a nice migration guide that explains how to migrate from com.google.ads.* to com.google.android.gms.ads.*.

So far, so good. Migrating is a piece of cake, but... There's always a "but".

Previously, com.google.ads.AdRequest used to have a setLocation(Location) method that would allow you to augment the targeting information. That option is no longer available in com.google.android.gms.ads.AdRequest, nor in its Builder class.

I suppose my questions are: where and why did it go? The where is probably easily answered, because it simply seems to have been removed. I'd love for someone to prove me wrong here though, so feel free to comment if I'm overlooking something. That leaves the why.

Right now I can only speculate as to why it was removed:

• It was overlooked when AdMob was refactored to become part of the Google Play Services.
• Out of privacy concerns, Google has decided to no longer support this feature.
• Since AdMob is now part of the Google Play Services, perhaps it integrates with its Location API (i.e. the Fused Location Provider) and automatically supplies location information if available?

The first option seems unlikely, whereas the second one would be understandable. Not sure about the third, but considering the privacy implications, not too likely either. Any chance someone can give a conclusive answer on the matter, or perhaps point to a reliable source?

---

Note: Yes, I'm aware of the following remark in the docs:

Out of respect for user privacy, Google asks that you only specify location and demographic data if that information is already used by your app.

The app this issue came up for is already location-aware. In fact, it's a rather important aspect of the app. As the note says, since the user's location is already used by the app, supplying it with the ad request has been a valid use case so far.

---

Update:

With the 9 January blog post on the upcoming Google Play Services 4.1 update, there is a mention of location targetting being re-introduced through a new API:

Google Mobile Ads
With Google Play services 4.1, the Google Mobile Ads SDK now fully supports DoubleClick for Publishers, DoubleClick Ad Exchange, and Search Ads for Mobile Apps. You can also use a new publisher-provided location API to provide Google with the location when requesting ads. Location-based ads can improve your app monetization.

Currently I haven't found any updated documentation on this new API, but would expect it to become available very soon - as soon as rollout of Google Play Services 4.1 has been completed. Until then, I'll keep my initial answer below for reference.

Google has now updated the Android docs on the new features. See accepted answer below.

Answer 1

Final update:

Google has finally updated the Android docs to include the new publisher-provided location API. Not surprisingly, these are glued into the builder pattern and pretty much identical to how things worked previously:

AdRequest.Builder.setLocation(Location)

The answer below is kept for educational purposes; if above answered your question, there's no need to look any further.

---

Update: It appears location targetting will be re-enabled through a new API in Google Play Services 4.1. See update to original question for more details.

---

For a lack of answers, I'm going to put this brief analysis up for the time being. I had a quick look at the old AdMob SDK and the new Google Play Services in an attempt to discover more information.

Here are my findings so far, outlined in a small table. Basically this gives a comparison of the various key-value pairs that are sent with an AdRequest.

 Admob SDK:                     | Google Play Services:
--------------------------------|--------------------------------
 map.put("kw", ...);            | map.put("kw", ...);
 map.put("cust_gender", ...);   | map.put("cust_gender", ...);
 map.put("cust_age", ...);      | map.put("cust_age", ...);
 map.put("uule", ...);          |
 map.put("testing", ...);       |
 map.put("pto", ...);           |
 map.put("cipa", ...);          |
 map.put("adtest", ...);        | map.put("adtest", ...);
 map.put("extras", ...);        | map.put("extras", ...);
                                | map.put("tag_for_child_directed_treatment", ...);
--------------------------------|--------------------------------

Legend:
* kw = keyword
* cust_gender = gender
* cust_age = birthday
* uule = location
* testing = testing
* pto / cipa = plus one opt out
* adtest = is test device
* extras = extras

In the old AdMob SDK, the uule key is used to bind up a location. Unfortunately, that is nowhere to be found in Google Play Services. That suggests that the 3rd speculation in my original question is most likely no the case. In a way, that would make sense, because that's definitely something that would've been documented somewhere, simply because of the change in required permissions.

I'm also inclined to say that the location feature wasn't overlooked. It's not the only missing key, but most of the other mainstream ones are there, like age, gender, keyword etc. In stead, I'm starting to believe that it was left out intentionally, dropping support for it. If I were to venture a guess, then it's most likely because of privacy concerns.

If anyone (in particular someone from Google) could confirm this, that'd be great. Also, if you find anything that contradicts these findings, most definitely leave a comment. I'm happy to be proven wrong.