Your Location Is Being Sold From Inside “Normal” Android Apps
Android location tracking via advertising SDKs happens when embedded ad libraries inherit an app’s approved location permission and then collect or transmit precise coordinates to advertising and data broker systems by default, often without clear user notice or accurate store disclosure, turning routine app usage into ongoing location data sharing with third parties. That’s the core problem: once you tap “Allow location,” you’re not only helping the app show you a map or the weather—you may also be feeding a quiet pipeline of location data into the ad industry. An investigation by a digital rights group found four Android ad SDKs that, by design, collect or share location whenever the host app already has permission, creating a privacy risk hidden behind ordinary app features. This is not a hypothetical flaw; it is working as shipped in real apps on real phones.
How Ad SDKs Turn One Permission Into a Broadcast Signal
The uncomfortable truth is that Android’s permission model treats your app and its embedded ad SDKs as a single unit: if the app can access location, the ad code can too. Four Android advertising SDKs—BidMachine, InMobi, Verve’s HyBid, and Huawei’s Petal Ads—describe location collection or sharing as the default whenever the app already has permission. Tests of two BidMachine-hosting apps, QR Scanner and GPS Speedometer, showed precise coordinates being sent straight to a BidMachine domain, with no extra notice and no third-party location sharing disclosed in the store listing. Precise Android location can pinpoint a device within about 160 feet and sometimes 10 feet. When those coordinates appear inside real-time bidding requests, they can be broadcast to thousands of advertisers and data brokers who may be more interested in your movements than in showing you an ad. That’s not a minor configuration quirk—it is a systemic location data sharing pipeline.
Why Defaults and Disclosures Are Failing Users
Advertising SDKs are often configured to collect precise location data by default; when you grant an app location access, the embedded kit gains access automatically. According to the investigation, “contracts and developer documentation cannot prove what a production build transmits,” so even diligent developers can end up shipping code that leaks location. The consent flows and Google Play Data safety listings for tested apps did not mention third-party location sharing, yet live traffic showed precise coordinates being sent out. This gap between what users think they approved and what SDKs actually do is the heart of the ad SDK privacy problem. Defaults matter: if developers do not scrutinize location-sharing behavior and Android treats SDKs as part of the app, then users’ expectations are routinely violated. Location patterns, even without names attached, can reveal sensitive information about where people live, work, shop, or worship, making re-identification easy. That is surveillance, not mere personalization.
What Developers Must Do: Treat SDKs Like Untrusted Code
If you ship an Android app, you are responsible for the data collection of every SDK you include, even features you never explicitly use. Google’s guidance is clear: third-party location sharing must appear in the Data safety form and follow disclosure and consent rules. The investigation shows that this is not happening consistently, and regulators have already taken notice—one enforcement order targeted a company for failing to ensure that apps using its location SDK obtained informed consent before using the data for targeted ads. App teams cannot rely on sales decks and documentation; they need evidence from the shipping build. Before each release, they 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, and reconcile observed traffic with consent screens, privacy notices, and Data safety disclosures. Anything less is negligence.
- List all ad SDKs and upgrade or remove ones with risky defaults.
- Drop precise location permission unless the app truly cannot function without it.
- Test real network traffic for hidden location data sharing before every release.
What Users Can Do Now: Audit Permissions and Cut Off Tracking
You should not have to fight your own phone to stay off ad trackers’ maps, but today you do. The report advises users to review their phone’s permissions and be selective about which tools receive precise location access. You don’t need to uninstall everything, but you should perform an app permissions audit: open Android settings, check location access app by app, revoke permission from anything that doesn’t need real-time coordinates, and switch to “approximate” location where possible. This reduces how much location data any ad SDK can inherit. Because SDK behavior can change with updates, these checks should be recurring, not one-off. Advertising-derived location data has already been used in serious surveillance contexts, so treating location access like a high-risk permission is common sense, not paranoia. Until platforms stop treating ad SDKs as invisible extensions of your apps, your best defense is to say “no” more often.
- In Android settings, review every app with location access and revoke any non-essential ones.
- Prefer apps that work with approximate location and avoid granting “always-on” access.
- Repeat this permissions review regularly, especially after installing or updating apps.
