Four Android advertising software development kits (SDKs) can collect or transmit a device’s location by default once the host app has location permission, according to an August 2026 investigation by the Electronic Frontier Foundation (EFF). The finding leaves app teams responsible for data flows they may not have knowingly enabled.
Because Android treats an app and its embedded code as one permission holder, an ad library can inherit location access granted for another feature. A shipping build can therefore transmit coordinates even when its consent flow and Google Play Data safety listing say nothing about third-party location sharing.
Android permissions extend to embedded ad code
The EFF investigation identified BidMachine, InMobi, Verve’s HyBid, and Huawei’s Petal Ads as libraries whose public documentation describes location collection or sharing by default when the app already has permission.
Researchers also tested two apps containing BidMachine: QR Scanner, with more than 50 million downloads, and GPS Speedometer, with more than 10 million. Network captures showed both sending precise coordinates to a BidMachine domain. Neither app displayed a notice before transmission, and neither Data safety section disclosed third-party location sharing.
For the other three SDKs, findings came from documentation review and, in HyBid’s case, open-source code rather than equivalent live traffic tests. InMobi says its library automatically forwards available location signals and recommends leaving that behavior enabled because location-enriched impressions typically earn more revenue. HyBid describes tracking as enabled by default, while Petal Ads includes location in ad requests unless developers use a separate opt-out method.
Precise Android location can resolve a device to within about 160 feet and sometimes 10 feet. When included in real-time bidding requests, those coordinates may be broadcast to thousands of prospective advertisers and collected by data brokers that join auctions for the information rather than the ad space.
That inherited-permission problem extends beyond advertising. A third-party Android SDK vulnerability recently exposed host-app privileges, while research into SDKs in apps marketed to US military personnel found mismatches between privacy disclosures and observed data practices.
App teams need evidence from the shipping build
Google’s Android SDK safety guidance says developers are responsible for an SDK’s data collection, including functions they do not use. Third-party location sharing must also appear in the Data safety form and comply with prominent disclosure and consent requirements.
In a 2024 order against InMarket, the Federal Trade Commission alleged that the company failed to ensure third-party apps using its location SDK had obtained informed consent before location data supported targeted advertising.
Contracts and developer documentation cannot prove what a production build transmits. Before each release, teams should:
- Inventory every advertising SDK and version.
- Remove precise location permission when it is not essential.
- Confirm each vendor’s location settings and opt-out behavior in code.
- Capture network traffic with location enabled and disabled.
- Inspect ad requests for coordinates, Wi-Fi identifiers, and persistent device IDs.
- Reconcile observed traffic with consent screens, privacy notices, and Data safety disclosures.
Google Play’s expanded app screening does not replace those checks. SDK behavior can change with an update, so traffic capture and disclosure review should remain recurring release controls rather than one-time integration tasks.
Also read: T-Mobile’s expanded T-Life privacy controls require separate checks across app, account, and device settings.