How third-party SDKs in Android apps leak your location to advertisers

A recent investigation by the Electronic Frontier Foundation (EFF), reported by TechCrunch, finds that many Android apps unintentionally share users' location data with advertisers, not because the app's own developers built tracking into their product, but because third-party software development kits (SDKs) bundled inside the app collect and transmit location data for their own purposes once the user has granted the app location permission. Understanding how this happens requires understanding how modern app development works, because very few apps are built entirely from a single team's own code.

A software development kit is a pre-built package of code that a mobile developer drops into their app to add a specific capability without writing that capability from scratch — analytics, crash reporting, in-app advertising, and push notifications are the most common categories. Because integrating an SDK typically means adding a few lines of code and granting it whatever permissions the host app already has, a developer who wires in an ad SDK for revenue may not audit exactly what that SDK does with the location permission the app requests for its own core feature.

Android's permission model asks the user to approve location access at the app level, not at the level of each individual piece of code running inside that app. Once a user taps "allow" for a weather app or a fitness tracker, every SDK bundled inside that app inherits the same location access the user granted to the app as a whole, with no separate prompt disclosing that a specific ad network or analytics vendor will also receive that data.

EFF's research specifically warns app developers, not just users, that some of the third-party code they include may be collecting and forwarding location data they never intended to share, and in some cases never explicitly agreed to share, because the SDK's terms of service are buried in developer documentation most teams do not read line by line before integrating a library that promises easy ad revenue or free analytics.

For advertisers and data brokers, this arrangement is valuable precisely because it aggregates location signals across thousands of unrelated apps. A single ad SDK embedded in a shopping app, a game and a news reader can build a much richer picture of a phone's movement patterns than any one app's location permission alone would suggest to the person who granted it, since the person granted permission to one app, not to the SDK vendor operating quietly across all of them.

Google has tightened Play Store policy over the years to require apps to disclose their data collection practices in a standardized "Data safety" label, and to restrict background location access behind a more prominent, separate permission prompt than foreground access. These changes have made blanket, invisible SDK-level collection harder than it once was, but they still rely heavily on developers accurately declaring what every embedded SDK actually does, which EFF's findings suggest does not always happen.

Regulatory pressure has pushed in the same direction. Europe's GDPR and various US state privacy laws increasingly treat granular location data as sensitive information requiring clear consent and defined retention limits, and regulators have fined companies specifically over location data collected through embedded SDKs rather than through an app's own first-party features, putting SDK vendors as well as the apps that embed them within the same legal exposure.

For users concerned about this, the most direct control remains the operating system's own permission settings: reviewing which apps hold "always" or "while using the app" location access, switching non-essential apps to "ask every time" or denying location outright, and periodically auditing which apps request location at all relative to what the app is actually meant to do, since a note-taking app or a simple game rarely has a legitimate reason to know a phone's precise location.

For app developers, EFF's message amounts to a call for due diligence rather than blame: reading an SDK's actual data-handling documentation before integrating it, using network traffic analysis tools to verify what data the SDK sends and where, and disclosing embedded third-party data flows to users as transparently as the developer discloses their own, since app store policy and regulators increasingly hold developers responsible for what their bundled code does, regardless of whether they wrote it themselves.

The broader pattern EFF's research points to is a mismatch between how the app permission system is designed — one grant per app — and how modern apps are actually built, as a patchwork of first-party code and third-party components with their own business incentives to collect data. Closing that gap will likely require both better platform-level transparency tools and continued outside research holding both developers and SDK vendors accountable for what happens after a user taps "allow."