New EFF research shows Android app developers may unintentionally share users' location data via ad SDKs. Learn how to audit SDKs and protect privacy.
New research from the Electronic Frontier Foundation (EFF) reveals a serious privacy blind spot: Android app developers may leak user location data to advertisers without even knowing it. The problem lies in third-party advertising SDKs, which can collect location data whenever the host app has location permission. Even when developers never intended to share that data, the SDK’s behavior creates an unintentional data-sharing pipeline. For anyone building Android apps, understanding this risk is no longer optional—it is essential.
Most Android apps rely on third-party SDKs for ads, analytics, and crash reporting. These libraries speed up development, but they also carry hidden privacy costs. EFF’s research shows that advertising SDKs can collect location data when users grant location permission to the host app—even if the developer did not intend that sharing. According to EFF, the SDK’s location-data behavior is often buried in documentation or entirely missing from the app’s privacy policy.
The scale of this issue is enormous. A 2017 analysis by Yale Privacy Lab and AppCensus found that 75% of free Android apps contain at least one third-party tracker. With more than 3 billion active Android devices worldwide, according to Google in 2024, that means billions of users may be affected.
The core problem is not necessarily that SDKs are malicious. It is that developers often don’t know what the SDKs in their own apps are doing. In many cases, the data collection is a default feature buried in a package the developer added to make money. The outcome is the same: sensitive location data leaves the app and goes to advertisers, data brokers, or other third parties.
Android’s permission model makes this situation even more difficult to address. Permissions are granted to the entire app process, not to individual components. When a user grants location permission to your app, every library running inside that process effectively inherits that permission. That includes embedded SDKs.
This means developers have limited ability to control data access on a per-component basis. You can’t easily tell an ad SDK, “Use the internet and view ads, but don’t access location.” Once the permission exists in the process, the SDK’s code can call the same location APIs your app uses.
Consider a simple weather app. A user grants location access to get a local forecast. The developer added a popular ad SDK to generate revenue. That SDK now has the same location access as the weather app itself. The developer may never see a line of code saying, “share location,” because the SDK is a closed-source binary. The location data can flow to ad networks without any explicit signal to the developer.
Many developers think of location data as just a set of coordinates. In practice, it reveals far more. Location data can expose home addresses, work locations, healthcare visits, political activities, and social networks. It is, in effect, a map of a person’s life. For data brokers and potential adversaries, this information is extremely valuable.
This is exactly why EFF is concerned. “Location data is a window into some of the most sensitive details of people’s lives. App developers should know that when they add an SDK, they aren’t just adding a library — they may be handing over the keys to their users’ private data,” said an EFF spokesperson in the research announcement.
The sensitivity of location data has not gone unnoticed. Regulators have increased their scrutiny of location data brokers over the last five years. At the same time, SDK-based data collection on Android has continued to rise over the last three years. This combination of growing data flows and growing attention has created real legal and reputational risk for app developers.
The good news is that this risk is manageable. EFF is urging developers to take practical steps before integrating any SDK into an Android app. These actions can reduce the chance of unintentional location data sharing.
Before adding a third-party SDK, read its documentation and privacy policy. Look for any mention of location collection, data retention, or sharing with sub-processors. If the documentation is vague, treat that as a red flag. Ask the vendor direct questions: Do you collect precise location? Do you share it? How long is it retained? Do you sell or license the data?
Developers should also demand written answers from SDK vendors. If a vendor can’t explain its data practices, that SDK may not be safe to include. Make sure the app’s own privacy policy reflects what the SDK actually does. Many privacy policies describe the host app’s behavior but ignore embedded SDKs. That gap can be a legal liability.
Where possible, switch to local-first or privacy-preserving alternatives. Consider on-device analytics, open-source libraries with clear code, or self-hosted telemetry. If you must use an ad SDK, look for one that lets you disable location collection or only use coarse location. Some vendors now offer privacy-friendly modes; others still hide location access behind a default setting.
The momentum behind privacy-friendly app development is growing. Over the last 12 months, developer awareness and demand for privacy-preserving SDKs have increased. This is a response to pressure from regulators, app-store policies, and users. The conversation has shifted from “Is this allowed?” to “Is this responsible?”
For developers, the best approach is to act before regulators or app stores force the issue. If an SDK in your app is collecting location data, you need to know. If you can’t control it, you need to remove it or replace it. Ignorance won’t protect you or your users.
The EFF’s research is a reminder that third-party code is part of your product. Every SDK you add carries responsibilities. Location data is especially sensitive, and the Android permission model makes it easy for SDKs to access it. But developers still have a choice: audit your dependencies, demand transparency, and prioritize privacy-preserving options.
Android app developers may be unknowingly sharing users’ location data through third-party advertising SDKs. The EFF’s research shows that this is not a niche problem—75% of free Android apps contain a third-party tracker, and more than 3 billion devices are in play. Location data reveals the most private aspects of people’s lives, making this a serious privacy and compliance issue.
The solution starts with simple but meaningful actions: audit every SDK, ask vendors for specific data practices, and choose local-first or privacy-preserving alternatives when possible. By taking control of the code you integrate, you can protect your users’ privacy and reduce your own risk. The keys to your users’ data should never be handed over accidentally.
Start by reviewing the SDK's documentation and privacy policy to see if it mentions location access. You should also inspect the SDK's code or use a permission monitoring tool to see which permissions the SDK actually requests. Running a network traffic analysis while testing the app can help reveal whether location data is being sent to advertisers.
Android grants permissions to the entire app process, not to individual components. So when a user gives your app location permission, every SDK integrated into that app can inherit the same access, even if you didn't intend for the SDK to use it. This makes it hard to restrict an ad SDK from reading location data while still letting your core features use it.
Developers can use privacy-focused ad SDKs that do not collect location data, or serve ads through server-side ad mediation where location data is not shared with the ad network. Another option is to use contextual advertising, which targets ads based on app content instead of user location. The EFF also recommends using open-source SDKs that have been audited for privacy.
It depends on the SDK. Some SDKs collect location data by default whenever the host app has location permission, without requiring an explicit enabling flag. In many cases, the developer may not even be aware that this data sharing is happening because the SDK's behavior is buried in documentation or not clearly stated. Always audit the SDK's actual code and behavior to know for sure.
First, minimize the number of SDKs and only choose ones with clear privacy policies. Use Android's permission controls to revoke location access from specific SDKs if possible, and consider using a privacy layer that strips location data before it reaches the SDK. Finally, document all SDK permissions and data collection in your app's privacy policy to maintain transparency.
