Patrick McClurePrincipal FDE
Jorgen SwiderskiAI Staff Engineer
Tyler LoechnerVP, Growth & Research
Jason DiasSVP, Engineering
Amin BandealiCTOThis analysis documents the API’s removal and sunset history, the version-usage data, two live-app case studies confirmed by APK teardown, the decompiled code path, and recommended remediation. It draws on Pixalate’s Ad SDK Trust Index 1.0; code snippets are published in the evidence dashboard for independent verification.
“…if the user is under GDPR and hasn’t given consent, whatever is passed into setLocation will still be passed to mediation partners and to the Mobile Ads back end, but it will be ignored by Google.”
Pixalate’s audit of GMA SDK v24.3.0 found location-transmitting code still present in the SDK — but fed only null values. That raised an obvious question: when did real coordinates last flow through this code? Pixalate went back through the version history to find out.
The timeline below reconstructs that history, per the decompiled code and Google’s own documentation:
AdRequest.Builder.setLocation() accepted exact coordinates and serialized them into the ad-request parcel, out of the app process (decompiled chain below).
setLocation() / getLocation() removed per the release notes. Google’s migration guide framed the removal as a targeting change (“The location data is not used by Google to target ads”).
v7–v19 (2023), v20.x (2024), v21.x (2025), v22.x (2026) per Google’s schedule. The Play Console separately blocks new app releases on versions through v21.x (per Google’s Play SDK Index; v22.x is sunset but not yet release-blocked); for live apps, ads are only “at risk” of not serving.
Google’s own Play SDK Index still reports 38% of GMA usage on pre-v21 versions. Separately, Pixalate observes precise consumer geolocation coordinates in the bidstream from apps on these builds, across the USA and Europe.†
The location API removal in 2022 did not retire the SDK versions that carry it. Google’s Play SDK Index — Google’s own published usage data, drawn from apps that share library dependencies with Google Play and have over 1,000 installs — still reports 38% of GMA SDK usage on pre-v21 (location-capable) builds, shown as share of voice (SOV) per version below.‡ Per Google’s release notes, setLocation() was added to AdRequest.Builder in v4.1 (January 16, 2014) and removed in v21.0.0 (May 25, 2022), so every version in the table accepted app-supplied location.
| Version | Usage (SOV) | Version | Usage (SOV) |
|---|---|---|---|
| 20.6.0 | 4% | 19.5.0 | 2% |
| 20.5.0 | 3% | 19.4.0 | 3% |
| 20.4.0 | 3% | 19.3.0 | 2% |
| 20.3.0 | 1% | 19.2.0 | 1% |
| 20.2.0 | 3% | 19.1.0 | 2% |
| 20.1.0 | 2% | 19.0.1 | 1% |
| 20.0.0 | 1% | 18.3.0 | 1% |
| 19.8.0 | 2% | 17.2.1 | 1% |
| 19.7.0 | 2% | 16.0.0 | 1% |
| 19.6.0 | 2% | 15.0.1 | 1% |
| Pre-v21 total · location-capable | Σ 38% | ||
| v21+ · location API removed | 62% | ||
Every version above is flagged “prevents app release” in Google’s Play SDK Index (retrieved August 27, 2026). Versions at 0% usage omitted.
Pixalate’s bidstream observations show apps on sunset, location-capable versions still requesting and serving ads — broadcasting precise consumer geolocation coordinates into the bidstream across the USA and Europe.
Sunsetting an SDK version does not stop it from serving ads. In Google’s own definitions, a “deprecated” version (two major releases old) still serves ads and gets no technical support; a “sunset” version (three or more releases behind) is merely “at risk” of ads not serving. Neither stage disables ad serving by default, and apps that ship these versions remain on the Play Store, according to Pixalate’s observations. The Play Console blocks new releases on sunset versions through v21.x (per Google’s Play SDK Index; v22.x is not yet release-blocked), but apps already installed keep running and keep requesting ads.
For apps still running GMA ≤ v20.6.0, Google’s published policy states:
“Ads at risk of not serving to this version. We will regularly review usage of all sunset versions going forward to consider disabling ad serving.”
According to Pixalate’s observations, ads still served on sunset pre-v21 builds as recently as August 2026, including on apps still available to download from the Google Play Store. Examples, confirmed by APK teardown:
In Pixalate’s bidstream data for these apps, bid requests carry coordinates to four decimal places (≈11-meter precision) — the standard Pixalate uses to distinguish precise geolocation coordinates.† In both apps, the pre-v21 GMA SDK is the only live, location-capable ad SDK, according to Pixalate’s analysis.
Per Google’s Mobile Ads SDK support on its official developer forum, whatever an app passed into setLocation() was passed on to mediation partners and the Mobile Ads back end regardless of GDPR consent status. The five steps below trace that path in decompiled source, from the public API call to the coordinates leaving the app process.
The location pipeline in v20.6.0, the last affected release, is documented below in decompiled source. Snippets are published in Pixalate’s evidence dashboard for independent verification. Pixalate added the // comments in all snippets below.
The SDK handles location coordinates supplied by the host app. Under Google’s Data safety guidance, “Collect” means “transmitting data from your app off a user’s device”, which “includes user data transmitted off device from your app by libraries and/or SDKs used in your app”.*
public Builder setLocation(@RecentlyNonNull Location location) {
this.zza.zzG(location); // stores the app-supplied Location
return this;
}The builder hands the app’s Location to its internal storage class (obfuscated as zzbjf), which keeps it until the request is built.
public final void zzG(Location location) {
this.zzk = location; // zzbjf’s own zzk — same name as, but distinct from, the parcel field in step 4
}When the app builds the request, the stored Location is copied out of the builder into the request object (zzbjg), whose accessor zzd() is what the request factory reads next.
// copied out of the builder ...
location = zzbjfVar.zzk;
this.zzf = location;
// ... and exposed by the accessor the request factory reads:
public final Location zzd() {
return this.zzf;
}The request factory passes the Location into the ad-request parcel’s constructor as argument 11, where it lands in the final field zzk and is serialized at field id 11 (first block below). A second, in-process serializer multiplies latitude and longitude by 107 and packs them into the ad request under the key “uule” (second block).
// constructor stores it in final field zzk (SafeParcelable id 11) ...
this.zzk = location;
// ... and writeToParcel marshals it at field id 11:
SafeParcelWriter.writeParcelable(parcel, 10, this.zzj, i, false);
SafeParcelWriter.writeParcelable(parcel, 11, this.zzk, i, false);
SafeParcelWriter.writeString(parcel, 12, this.zzl, false);Location location = zzbfdVar.zzk;
if (location != null) {
Long valueOf3 = Long.valueOf((long) (location.getLatitude() * 1.0E7d));
Long valueOf4 = Long.valueOf((long) (location.getLongitude() * 1.0E7d));
Bundle bundle3 = new Bundle();
bundle3.putFloat("radius", valueOf.floatValue());
bundle3.putLong("lat", valueOf3.longValue());
bundle3.putLong("long", valueOf4.longValue());
bundle3.putLong("time", valueOf2.longValue());
bundle2.putBundle("uule", bundle3);
}When the app calls loadAd(), the SDK builds the parcel and hands it to the sender in a single expression — and the finished object, coordinates included, is dispatched over Android’s Binder IPC to the Google Play services ad process.
// reached from the public API: BaseAdView.loadAd(AdRequest) → zzbji.zzl(...)
// one expression builds the ad-request parcel and hands it to the sender:
if (zzbhkVar2.zzaa(this.zzc.zza(this.zzm.getContext(), zzbjgVar))) {public final boolean zzaa(zzbfd zzbfdVar) throws RemoteException {
Parcel zza = zza();
zzaol.zzd(zza, zzbfdVar); // marshal the ad-request parcel
Parcel zzbs = zzbs(4, zza); // Binder transaction — leaves the app process
boolean zzg = zzaol.zzg(zzbs);
zzbs.recycle();
return zzg;
}In the Index, both analyzed GMA versions — pre-v21 and v24.3.0, the version rated in the Index — carry Low Risk flags on the FTC and app-store ToS risk dimensions, which measure disclosure alignment. Pre-v21 is flagged Collects & Transmits Off-Device for precise location data on code analysis, and this post examines risks, including GDPR risks, stemming from collection and transmission.
Remove apps still shipping GMA SDK ≤ v20.6.0 from the Play Store, and disable ad serving for those versions. The serving mechanism already exists in the deprecation policy (“consider disabling ad serving” on sunset versions). Suggested implementation:
Upgrade to GMA SDK v21+ (current line: v25.x). v21 removed setLocation(); in v24.3.0, the version Pixalate audited, every code path in the analyzed artifacts that could populate the location field passes null, per Pixalate’s analysis.
The remaining 38% of reported usage migrates to versions without the location API — consistent with the current GMA line and the other most popular ad SDKs by install base, per Pixalate’s Ad SDK Trust Index 1.0.
Full methodology: pixalate.com/sdk-trust-index-methodology.
The Pixalate Ad SDK Trust Index is free to search. Flagged ratings publish the analyzed code snippets behind them — including the pre-v21 GMA chain — and manifest and privacy-policy findings are published alongside the ratings.
* Some rated SDKs do not read device location sensors directly but receive coordinates from the host app through the SDK’s own API and transmit them off-device; consistent with Apple’s and Google’s definitions of data collection, Pixalate treats this as location collection. For the purpose of Pixalate’s analysis, SDKs that collect “flexible” location (i.e., collect precise location if able, coarse if not) are considered to collect precise location.
† Pixalate’s standard for precise location in the bidstream is the presence of an in-bidstream location-source flag together with coordinates of four or more decimal places.
‡ SOV (share of voice) refers to per-version usage percentages as published by Google in its Play SDK Index (retrieved August 27, 2026), based on apps that share library dependencies with Google Play and have over 1,000 installs. The 38% pre-v21 total is Pixalate’s summation of Google’s per-version figures.
Privacy policy snapshots as of May 11, 2026; Index-wide SDK code analysis as of May 21, 2026; the GMA pre-v21/current version comparison was performed August 2026.
The Pixalate Ad SDK Trust Index reflects Pixalate’s opinions on observed privacy and compliance signals across mobile SDKs and does not constitute a legal compliance determination, a finding of liability, or an assertion that any SDK, its provider, or integrating developer has violated GDPR, COPPA, FTC Section 5, app store terms of service, or any other law or regulation. Risk ratings reflect Pixalate’s opinion based on its assessment of each SDK. Nothing in this report asserts that Google or any app developer named herein has violated any law or regulation, or that any current version of the Google Mobile Ads SDK collects location data. All data is grounded in Pixalate’s proprietary technology and analytics, which Pixalate is continuously evaluating and updating. Pixalate’s opinions are just that, opinions — neither facts nor guarantees. Pixalate shares these findings not to impugn the standing or reputation of any entity, person, or app, but to report findings and trends pertaining to programmatic advertising activity in the period studied. Read the full disclaimer here.
