Android SDK location data sharing: EFF names four ad SDKs

Last updated: 2026-10-02

On August 4, 2026, the Electronic Frontier Foundation published a study by Lena Cohen and Bill Budington on location data sharing by Android ad SDKs. It names four SDKs that collect and share device location for ad targeting by default: InMobi, BidMachine, Verve's HyBid and Huawei's Petal Ads. The default takes effect once the user grants the host app location permission; in EFF's words, "there are no SDK-specific location permissions". The study includes two traffic captures (mitmproxy flows files) that record precise coordinates sent to BidMachine's host api.bidmachine.io by QR Scanner and GPS Speedometer, two Google Play apps with 50M+ and 10M+ downloads.

Which Android ad SDKs share location data by default, according to EFF?

EFF reviewed the public documentation of dozens of advertising SDKs and selected these four because each vendor's own developer guide states that location is collected by default. EFF contacted each SDK company and the app developers; one company updated its documentation in response, and another responded with clarifications.

On 2026-10-02 the four vendors' documentation stated:

• InMobi: "The InMobi SDK automatically forwards location signals when available", and "location-enriched impressions typically yield higher revenue" (InMobi Android integration guide).
• BidMachine: the "SDK can automatically track user device location to serve better ads" (BidMachine Advanced Settings). BidMachine's exchange page lists "user location" among the "first-party signals" its SDK captures (BidMachine Exchange).
• Verve HyBid: "If the user has given location permissions, HyBid SDK will use the available user location to provide better targeted ads. This feature is enabled by default" (HyBid Android configuration).
• Huawei Petal Ads: "the Ads SDK will carry users' location information in ad requests" when the app has the permission (Use of Location Data for Ads).

BidMachine's App Privacy Details page, its guidance for Google Play privacy declarations, said precise location was "not collected" when EFF checked it on 2026-07-31. BidMachine changed the page after EFF's inquiry; on 2026-10-02 it states that precise location is "collected by the BidMachine SDK only if the host app has obtained the ACCESS_FINE_LOCATION permission". BidMachine told EFF that it could not get location information "unless the user has granted the app the relevant permission through the operating system" and that "publishers are responsible for configuring their apps' permission and consent flows" (EFF, BidMachine section).

Verve told EFF that its SDK uses the cached network-provider location and that location "is limited to an accuracy radius of no less than 1,850 feet" (EFF, Verve section). HyBid's open-source OpenRTBAdRequestFactory rounds latitude and longitude to two decimal places with roundToTwoDecimalPlaces.

The vendors publish their own reach figures. InMobi reports "2B+ users across 150+ countries" (inmobi.com); MGI – Media and Games Invest stated in an April 29, 2024 release that HyBid gives "access to over 1.5 billion users across more than 10,000 apps"; Huawei states that "more than 85,000 apps worldwide have integrated Ads Kit" as of September 30, 2025 (Petal Ads introduction).

In June 2016 InMobi agreed to pay $950,000 in civil penalties to settle FTC charges that it "deceptively tracked the locations of hundreds of millions of consumers – including children – without their knowledge or consent".

What did EFF's capture of QR Scanner and GPS Speedometer show?

EFF published both files (QR Scanner flows, GPS Speedometer flows). Each records one request and its response. I opened them in mitmdump 12.2.3 (mitmproxy's command-line tool).

• Host and path: api.bidmachine.io, POST /auction/init, Content-Type: application/x-protobuf, gzip body. The server's Date header is 2026-07-23 22:42:33 GMT for QR Scanner and 2026-07-23 11:41:17 GMT for GPS Speedometer.
• Test device: Pixel 8 on Android 16, per the User-Agent header.
• SDK and app versions in the body: BidMachine 3.6.1 in QR Scanner 3.4.4, BidMachine 3.7.1 in GPS Speedometer 17.3.
• Coordinates: the protobuf has no published schema, so mitmproxy shows field numbers and no field names. A latitude and longitude pair, encoded as 32-bit floats, appears twice in the QR Scanner request (top-level field 5 and field 19.2.26, inside the message that also contains BidMachine's sdk.context.Device extension) and once in the GPS Speedometer request (field 19.2.26). Both files contain the same pair, at five decimal places, a resolution of about 1.1 metres (decimal degrees).
• Advertising ID: the same request contains a UUID that BidMachine's response labels "ifa" (identifier for advertising); both files contain the same UUID.
• Next hop: the response names https://api-us.bidmachine.io/auction/rtb/v3 as the auction endpoint. Which bidders receive the coordinates after this init request is outside the capture.

EFF's finding covers the coordinates in the two requests. I also decoded the QR Scanner response; this decoding is mine, and EFF's study does not report it. A base64 token in that response decodes to JSON with a geo object whose lat and lon values equal the coordinates in the request, next to ifa, bundle, sdkver and installTime, so the coordinates sent by the app are present in the reply from BidMachine's server. The field names lat and lon appear only in this token. BidMachine does not document this token, so what each field means is my reading of its name. The geo object in the GPS Speedometer response token contains a different pair from its request, so the match is established for the QR Scanner file only.

EFF's methodology note states that it used mitmproxy and, "where needed", Frida, a runtime instrumentation toolkit, on a test device. Because BidMachine's documentation conditions collection on the app's location permission, the coordinates indicate that the permission had been granted on the test device, or that the app passed a location through TargetingParams.setDeviceLocation, a targeting parameter listed on the same Advanced Settings page. The flows files record network traffic only, so the order of screens comes from EFF's text: "Neither app that EFF observed sharing precise location data with BidMachine ... showed a notice or requested consent before doing so" (EFF).

EFF published captures for BidMachine only; hosts and payload fields for InMobi, HyBid and Petal Ads are absent from the study, and a fresh capture would establish them.

What do the two apps' Google Play Data safety sections say?

Neither section lists location, as fetched on 2026-10-02. The labels and the captures cover different builds: EFF captured QR Scanner 3.4.4 and GPS Speedometer 17.3 in July 2026, and Play shows QR Scanner updated on August 27, 2026 and GPS Speedometer on September 25, 2026. A new capture of the current builds would establish what they send.

QR Scanner's Data safety page (developer shown as Red Sky Labs) reads: "The developer says that this app doesn't collect or share any user data." GPS Speedometer's Data safety page (KTW Apps) lists crash logs, diagnostics, other app performance data, purchase history and device or other IDs as shared, and states "No data collected". GPS Speedometer's own listing states that it "relies on your device's GPS sensor", so location permission is part of normal use of that app.

Google's Data safety help page sets the rule for SDK data: "You must reflect data collection or sharing carried out by such third-party code in the Data safety form for your app."

Which package names identify the four SDKs in an Android APK?

Each SDK uses its own Java package prefix (table below). Exodus Privacy's automated tracker reports, which list the tracker code signatures found in an APK, list BidMachine, InMobi and PubNative (the net.pubnative namespace HyBid uses) in both apps: QR Scanner 3.4.5 (39 trackers, report of August 15, 2026, plus a broader "Huawei Mobile Services (HMS) Core" signature) and GPS Speedometer 18.1 (27 trackers, report of October 2, 2026).

Source: vendor documentation and sample repositories linked in each cell, fetched 2026-10-02.

The APK contains two more static signals. The app's merged manifest declares ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION; InMobi's guide states that including ACCESS_FINE_LOCATION "will enable accurate ad targeting". A call to setLocationTrackingEnabled(false) or setRequestLocation(false) in the app's own code shows that the developer changed the default. R8, the Android build tool that shrinks and renames code, keeps the package names when the build contains keep rules for them; HyBid's guide lists -keep class net.pubnative.** { *; }. These package names establish that the code is in the build; only a capture establishes transmission.

What does a traffic capture need to show?

A capture establishes that an SDK sent precise location when it records four things in one session. EFF's BidMachine flows meet the first three.

1. The host and path in full, and the TLS server name: in EFF's files the connection is to a Cloudflare IP with Host: api.bidmachine.io.
2. The coordinate fields and their precision; for protobuf bodies, the field path.
3. Identifiers in the same request (advertising ID, app bundle, SDK version), which tie the coordinates to a device and a build.
4. Timing against the UI: the timestamp of the location request relative to the permission grant, any notice or consent screen, and first launch, with screenshots tied to request times. EFF states the screen order in its text.

Our post on Connecticut's precise geolocation sale ban covers the law on selling precise location data.

EFF also notes that the vendors document separate settings for COPPA (the US children's online privacy law) and GDPR users and that those modes are off by default; HyBid's guide states COPPA mode "is disabled by default". Our post on app store age-signal laws covers the age-signal rules that apply to apps and SDKs.

How does a CanITrustThat scan test an app for this?

A CanITrustThat scan records the same evidence in two tiers. The static tier lists the SDKs found in the binary, with file and line for each finding, and the declared location permissions. The network tier records traffic on test devices: what was sent, to which host, and whether before or after consent. The methodology page sets out what a scan checks and the scan's limits.

I treat static findings as leads; a captured request that contains the coordinates is the evidence that stands public scrutiny. The scanned apps are listed in the app index. I can scan a list of apps in bulk, Android and iOS builds, and flag the ones that contain any of these four SDKs. Sign up for a CanITrustThat account to run your own research, or let us run an investigation for you.