Your Signal, Their Data: An Empirical Privacy Analysis of

Wireless-scanning SDKs in Android

Aniketh Girish Joel Reardon Juan Tapiador
IMDEA Networks Institute / University of Calgary / AppCensus Universidad Carlos III de Madrid
Universidad Carlos III de Madrid

Srdjan Matic Narseo Vallina-Rodriguez

IMDEA Software Institute IMDEA Networks Institute / AppCensus

Abstract
arXiv:2503.15238v1 [cs.CR] 19 Mar 2025

the use of these technologies raise significant privacy concerns

Mobile apps frequently use Bluetooth Low Energy (BLE) and WiFi because geolocation data is inherently sensitive: either coarse- or
scanning permissions to discover nearby devices like peripherals fine-grained geolocation data can reveal individuals’ daily habits,
and connect to WiFi Access Points (APs). However, wireless inter- work-home pairs [30], social structures [61, 133], and visits to sen-
faces also serve as a covert proxy for geolocation data, enabling sitive sites like places of worship [22]. Unfortunately, the demand
continuous user tracking and profiling. This includes technologies for location data by marketing, banking, and insurance firms has
like BLE beacons, which are BLE devices broadcasting unique iden- fueled a complex supply chain of actors specializing in location data
tifiers to determine devices’ indoor physical locations; such beacons collection, aggregation, and resale [76]. Companies like Azira [15]
are easily found in shopping centres. Despite the widespread use of and Venntel [72] have been reported selling location data, including
wireless scanning APIs and their potential for privacy abuse, the in- visits to sensitive locations such as abortion clinics [131] and even
terplay between commercial mobile SDKs with wireless sensing and private sites like Jeffrey Epstein’s island [129].
beaconing technologies remains largely unexplored. In this work, Despite the permission mechanisms implemented in Android
we conduct the first systematic analysis of 52 wireless-scanning and iOS to protect access to precise GPS data [40, 64], app devel-
SDKs, revealing their data collection practices and privacy risks. We opers and third-party SDKs exploit alternative channels to bypass
develop a comprehensive analysis pipeline that enables us to detect these controls and obtain (or infer) users’ location, often in the
beacon scanning capabilities, inject wireless events to trigger app background without user awareness. One such mechanism is based
behaviors, and monitor runtime execution on instrumented devices. on scanning wireless devices and beacon signals, including classic
Our findings show that 86% of apps integrating these SDKs collect Bluetooth, Bluetooth Low Energy (BLE) beacons, and WiFi access
at least one sensitive data type, including device and user identi- points.1 Such wireless scans can reveal users’ geolocation as Blue-
fiers such as AAID, email, along with GPS coordinates, WiFi and tooth or WiFi beacons are tied to specific physical locations like
Bluetooth scan results. We uncover widespread SDK-to-SDK data stores, hotels, workplaces, or transit hubs [27]. Linking such geo-
sharing and evidence of ID bridging, where persistent and resettable location data with user or device IDs like the Android Advertising
identifiers are shared and synchronized within SDKs embedded ID (AAID) and MAC addresses make reversing users’ identity and
in applications to potentially construct detailed mobility profiles, movement patterns straightforward [45].
compromising user anonymity and enabling long-term tracking. The threats posed by the collection of wireless beacons as geo-
We provide evidence of key actors engaging in these practices and location data proxies are real and severe, as several high-profile
conclude by proposing mitigation strategies such as stronger SDK incidents and legal actions show. In 2014, the Snowden revela-
sandboxing, stricter enforcement of platform policies, and improved tions exposed how devices could be tracked via MAC addresses
transparency mechanisms to limit unauthorized tracking. through WiFi hotspots [93]. More recently, the Wall Street Journal
reported that the FBI and ICE acquired location data through SDKs
Keywords embedded in mobile apps [72, 119]. The Federal Trade Commis-
sion (FTC) has taken action against companies like X-Mode (now
Privacy, BLE, WiFi, Location, Beacons, Android SDKs
Outlogic) [32], inMobi, and Kochava for harvesting and reselling
1 Introduction extensive location data without user consent, leading to serious
concerns about constitutional rights in the U.S. [21–24]. A recent
Imagine walking through a shopping mall and, as you pass by stores, report by the German data protection authority reveals that apps
your phone buzzes with personalized ads and notifications. This collecting location data, including military personnel movements,
seamless integration of the digital and physical worlds is powered was sold in data marketplaces, exposing intelligence agency sites,
by technologies like GPS, Bluetooth, and WiFi, as their sensing ca- military bases, secret facilities and their personnel’s habits [3, 128].
pabilities facilitate detecting device proximity or location. However, In the academic sphere, researchers demonstrated that wireless
This work is licensed under the Creative Commons Attribu-
signal can be exploited to infer geographical locations and social
tion 4.0 International License. To view a copy of this license structures [27, 54, 60, 87, 109]. Reyes et al. [108] found evidence of
visit https://creativecommons.org/licenses/by/4.0/ or send a
letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
Proceedings on Privacy Enhancing Technologies YYYY(X), 1–21 1 Inthis paper, we collectively refer to SDKs with BLE and WiFi scanning capabilities
© YYYY Copyright held by the owner/author(s). as “beacon SDKs”. Equally, for simplicity, we refer to BLE and WiFi broadcast messages
https://doi.org/XXXXXXX.XXXXXXX as “beacons.”
1
Proceedings on Privacy Enhancing Technologies YYYY(X) Girish et al.

children-directed apps using WiFi APs as a proxy to GPS locations, rationales and explicit disclosures of SDK data access practices.
violating the COPPA Rule. Similarly, Girish et al. [56] identified Additionally, we advocate for stronger regulatory oversight, plat-
apps and SDKs leveraging local network scans to infer user location forms’ permission re-designs and stricter vetting processes (i.e.,
without user consent in smart home networks. Google Play Protect) to proactively conduct large-scale audits and
Despite these efforts, SDKs exploiting wireless scans for covert enforcement actions against non-compliant tracking practices.
location tracking remain poorly understood. Consequently, exist- Responsible disclosure. We shared a preprint of this paper with
ing app auditing mechanisms and privacy controls (including data Google as operator of the Android platform, and with the European
randomization) have been proven insufficient to detect and pro- Data Protection Supervisor (EDPS), the Spanish Data Protection
tect users against such invasive practices, respectively [56, 122]. To Agency (AEPD), and the French National Commission on Informat-
fill this gap, we empirically analyze how 52 mobile beacon SDKs ics and Liberty (CNIL).
leverage GPS, BLE, and WiFi as side channels to covertly track Research artifacts. To promote transparency, reproducibility, and
individuals’ proximity and locations, covering 9,976 Android apps. future research, we will release the final dataset, beacon detection
To uncover their scanning capabilities, data-sharing, and privacy scripts, static analysis pipeline, and analysis code used in this study,
risks, we develop a hybrid analysis pipeline that combines (i) static excluding proprietary components. These artifacts will be publicly
analysis, including API usage detection and control-flow analysis to available at: https://github.com/wireless-scanning-SDKs/.
study cross-library interactions and (ii) dynamic analysis, using an
instrumented device that injects wireless events and signals at the 2 Background
OS-level to trigger SDK behaviors and observe app runtime behav-
This section provides an overview of BLE (§2.1) and WiFi (§2.2)
iors. To the best of our knowledge, this study is the first large-scale
beacon technologies as location proxies, and an overview of the
empirical analysis of BLE and WiFi scanning SDKs in Android apps
existing Android permissions for restricting apps’ access to BLE
to systematically uncover their characteristics, interrelationships,
and WiFi scanning capabilities (§2.3).
and privacy implications. The key contributions of this work are:
2.1 BLE Beacons
• We identify 52 SDKs with WiFi and BLE scanning features in-
tegrated into at least 9,976 apps with an estimated cumulative A BLE beacon is a non-pairing device broadcasting unique IDs like
install count of 55B devices. We find that beacon SDKs often UUIDs or MAC addresses to infer proximity or location. Unlike
offer a dual purpose, functioning both as beacon enablers and as GPS-based positioning systems, BLE beacons are deployed in fixed
analytics or advertising libraries. Specifically, 43 SDKs support locations—e.g., stores, metro stations or offices—so that they pro-
analytics, 40 SDKs provide location services, and 9 SDKs inte- vide fine-grained indoor location for like retail [70], healthcare,
grate advertising or user profiling features (§5.1). Among them, logistics, or crowd management at events [91]. These fixed signals
we detect 28 SDKs that play a key role in extensive cross-library are collected alongside GPS coordinates and are often aggregated
interactions, potentially enabling colluding SDKs to silently share into publicly accessible databases such as Wigle [127], and pro-
with each other data such as Bluetooth, WiFi scans, and geoloca- prietary ones. This allows SDKs to infer a user’s location solely
tion for advertising and tracking purposes (§5.2). through nearby BLE signals and access to such datasets.
• We observe that 86% of beacon-enabled apps extensively collect BLE beacons are not a Bluetooth SIG standard; rather, they are
personally identifiable information (PII), along with GPS coor- custom standards developed by large providers or groups of compa-
dinates, WiFi, and Bluetooth scan results (§6.2). However, their nies. Popular BLE beacon solutions include iBeacon by Apple [66],
data collection practices extend further, with 19% of beacon SDKs the now deprecated Eddystone by Google [67], and the widely sup-
engaging in ID bridging by linking persistent IDs (e.g., Android ported open-source and platform-agnostic AltBeacon [7], which
ID and MAC addresses) with resettable ones (e.g., AAID) to build is becoming a predominant solution due to their cross-platform
detailed user mobility profiles, potentially violating Google Play interoperability. We note that standard Bluetooth devices can be
Store policies (§6.3). These risks are exacerbated by the use of also scanned to collect device names and MAC addresses, which
persistent proprietary IDs (e.g., Adobe’s Marketing Cloud ID), could be used for environmental sensing (e.g., by inferring locations
unvetted cross-library data sharing, and by exploiting shortcom- based on paired BLE devices), and social network inference [83].
ings of Android’s permission and sandboxing models. Moreover,
71% of apps requesting location permissions fail to provide a 2.2 WiFi Beacons
rationale through Android’s shouldShowRequestPermissionsRa- WiFi Access Points (APs) broadcast beacon frames containing their
tionale() API, leaving users unaware of why access is requested MAC addresses and received signal strength indicator (RSSI) over
(§6.4). We also observe SDKs abuse vulnerabilities in unpatched 802.11b/g/n channels. Mobile devices can passively scan these bea-
devices to bypass the Android permissions governing BLE and cons to locate and connect to nearby APs by sending association
WiFi permissions. frames. WiFi APs are typically deployed in known locations (e.g.,
• These widespread practices undermine existing privacy protec- homes, shops, hotels, and airports) and rarely move once deployed.
tions and controls. In §7, we propose mitigation strategies, in- This means that correlating WiFi SSID and BSSID data2 with free
cluding: SDK sandboxing to restrict cross-library data sharing, online databases (e.g., wigle.com) or commercial location services
performing runtime audits to detect unauthorized tracking, en- 2 SSID is the name of a wireless network that devices use to identify and connect to it.
forcing stricter platform policies to curb ID bridging, and im- BSSID is the unique identifier for a specific access point within a wireless network
proving transparency mechanisms by requiring clear permission (i.e., MAC address).
2
Your Signal, Their Data Proceedings on Privacy Enhancing Technologies YYYY(X)

(e.g., here.com) makes them highly effective for determining user

location. In fact, there are commercially-available WiFi Positioning
Third-party trackers,
System (WPS) that facilitate inferring users’ locations from WiFi Location data brokers and
signals, as a complement or alternative to GPS-based systems. Apple platforms marketplaces.

integrates WPS [10] into iOS devices for enhanced location services, Beacon
Device and location metadata
though Rye et al. [110] recently highlighted the potential for mass (Nearby beacon scan data) con guration
surveillance using this data. Similarly, Google maintains a WPS
populated through WiFi AP data collected from Android devices
Beacon
and its ecosystem, which also serves as a data source for Android’s identi ers SSID/BSSID
coarse location permission [58, 121]. These WPSes expose APIs
BLE beacons
that allow a client to submit WiFi scan data and receive location es- Nearby WiFi
routers
timates in return. Other providers, such as Skyhook Wireless [114]
and Navizon [90], offer hybrid systems combining GPS, WiFi, and Geofence (latitude, longitude)
cellular signals to triangulate device location.
Figure 1: Beacon data ecosystem.
2.3 Permission Overview
Android’s permission model regulates access to WiFi and Bluetooth
scanning functions to protect user privacy and security [39]. Over Platform Fragmentation. Due to the high version fragmentation
successive releases, Android’s permission model has evolved to in the Android ecosystem, many apps and SDKs intentionally ex-
impose stricter controls on BLE and WiFi scanning capabilities, ploit OS vulnerabilities and old (typically less restrictive) versions
particularly due to their dual usage as location proxies. of the Android permission model to perform BLE and WiFi scans.
Bluetooth. Initially, Bluetooth operations required only a generic Another key limitation of the permission model is its inability to
permission for scanning and connecting with nearby devices. How- separate between permissions requested by the host app and those
ever, starting with Android 6, apps also had to request the runtime3 by third-party SDKs [52], even for runtime permissions that grant
ACCESS_COARSE_LOCATION permission, as BLE scans could indi- access to sensitive data. As a result, SDKs can piggyback on the
rectly reveal location data [35]. This was later upgraded in Android permissions requested by the host app for secondary purposes such
10, mandating the ACCESS_FINE_LOCATION permission for Blue- as surveillance or advertising.
tooth scanning due to its increased risk of exposing the precise
location data [73]. However, this security improvement only led to 3 Threat Model
confusion among users, especially when apps that did not inher- We consider an adversary whose primary objective is to collect geo-
ently need location data—such as those for connecting to Bluetooth location data from mobile Android apps by scanning nearby devices
peripherals—were also forced to request location permissions [130]. using Bluetooth or WiFi permissions (see Figure 1). This adversary
To address this issue, Android 12 introduced a finer-grained model can be any party with programmatic access to the device for scan-
with three new permissions: one for scanning (BLUETOOTH_SCAN), ning data, including the app developer (the first party) as well as
one for establishing connections (BLUETOOTH_CONNECT), and one third party SDKs offering advertising, analytics, or location-based
to advertise as a peripheral (BLUETOOTH_ADVERTISE). Developers solutions. We consider three key threats posed by such adversaries:
must request both ACCESS_FINE_LOCATION and ACCESS_COARSE_ (1) Continuous Location Tracking through Proxy Sensors.
LOCATION to allow users to choose between precise or approximate Wireless-enabled location SDKs or Android apps can silently
location access at runtime. Yet, without clear context, users may track users by continuously scanning for nearby WiFi and BLE
unintentionally grant excessive location privileges—e.g., precise signals. Scan results can include: device information (e.g., device
location for Bluetooth pairing. To mitigate this, Android 12 intro- name), network information (e.g., SSID/BSSID, MAC addresses),
duced the neverForLocation flag in 2021 to ensure that Bluetooth and other unique device IDs as in the case of BLE beacons. To
scan data is not misused for location inference. infer user location, wireless scanning data can be correlated
WiFi. Since Android’s first release, apps using WiFi must request with external databases that map MAC addresses, beacons and
the CHANGE_WIFI_STATE and ACCESS_WIFI_STATE permissions to WiFi AP BSSIDs and SSIDs to geographic coordinates as de-
toggle connectivity, modify settings, and provide connection de- scribed in the previous section. SDKs often enrich scan data
tails. Since Android 8, any app that scans the WiFi network is also with precise GPS coordinates and other device or user identi-
required to request at least one location permission (i.e., ACCESS_ fiers like the AAID to construct detailed mobility profiles of
FINE_LOCATION or ACCESS_COARSE_LOCATION). More recently, An- millions of users. 4 Table 7 in the Appendix provides an exhaus-
droid 13 introduced a new runtime permission, NEARBY_WIFI_ tive description of the PII types and user/device IDs considered
DEVICES for connecting to nearby devices via WiFi. Android 13
4 The Android OS allows app and SDK developers to programmatically access a wide
also added support for the neverForLocation tag to specify WiFi
range of IDs with varying properties [41]. The MAC address of a WiFi AP are device-
scan data is not used for location inference. specific, persistent and globally unique IDs. Similarly, the user’s email address, even if
hashed, is a user-specific, persistent and unique ID, unless it is shared by a group of
3 Unlikenormal permissions, which are granted during installation, runtime or danger- users. The AAID is a device-specific, resettable and globally unique ID. The Firebase
ous permissions protect sensitive resources and data (e.g., location) and require explicit ID, instead, is a globally unique and app-specific ID that is resettable by reinstalling
user approval at runtime [39]. the app to which it is scoped.
3
Proceedings on Privacy Enhancing Technologies YYYY(X) Girish et al.

in this paper, categorized by their nature. These rich user pro-

files may reveal sensitive information such as social structures,
frequently visited locations and lifestyle patterns [45].
(2) ID Bridging. Beacon information facilitates collecting unique
user geolocation fingerprints—as demonstrated by de Mon-
tjoye [30]—due to the uniqueness of human mobility patterns.
Mobility fingerprints not only allow distinguishing individuals
even in anonymized datasets but also enable ID bridging, i.e.,
correlating and bridging users data and fingerprints for contin-
uous user tracking and profiling. These methods, particularly
when used to bridge resettable IDs like the AAID, significantly
undermine user attempts to maintain anonymity on the Inter-
net, even if users opt-out of personalized ads through system
settings or by resetting their AAID. To mitigate these privacy
risks, Google has set various policies and best practices to in-
form and educate app developers about which IDs would be
better for specific purposes [100]. Google strictly prohibits link-
ing resettable IDs (e.g., AAID) with persistent or global IDs
for advertising or analytics purposes without sufficient trans- Figure 2: Methodology overview. Processes 2.a and 2.b. run
parency [41, 100]. §6.3 analyzes ID bridging practices across in parallel.
beacon SDKs, including AAID bridging, while §5.2 shows how
colluding SDKs programmatically interact with each other to
synchronize user profiles without user awareness. Oftentimes,
geolocation data is aggregated and sold to advertisers, analytics
companies, and other entities like data brokers, causing signifi- Union (EU) as of July 2024, ensuring that our study covers the
cant privacy harm to users. most recent app versions. We use an open-source Google Play
(3) Exploitation of Outdated Permission Models. SDKs can scraper [97] to collect metadata for each app, including its self-
exploit vulnerabilities in Android’s permission model (§2.3) to disclosed app category, developer information, data safety labels,
access sensitive data in unpatched devices. Methods to achieve and install counts.
this include piggybacking on permissions granted to the host
app, using legacy APIs with less stringent requirements, or
leveraging side channels to bypass restrictions and infer infor- 4.2 Detecting Beacon SDKs
mation without explicit permission requests. This type of attack There is no publicly available inventory of SDKs offering BLE and
is facilitated by Android’s version fragmentation: according to WiFi scanning capabilities. While some efforts document advertis-
Statista, over 41% of Android devices run version 12 or below ing and analytics SDKs [52, 84, 104, 105, 134], beacon-enabled SDKs
as of January 2025. §6.2 reports evidence of SDKs using these remain under-reported, often embedded within broader functional-
techniques to access location data. ities, making them difficult to detect and analyze. To address this
gap, we create a first-of-its-kind public dataset, capturing a repre-
4 Methodology sentative set of widely used SDKs with wireless scanning implemen-
tations. Our approach systematically identifies these SDKs through
Figure 2 summarizes the methodology we developed to achieve
a multi-step iterative process, combining third-party datasets and
the paper objectives. We combine both static and dynamic analysis
manual searches to curate a structured list of SDKs actively engag-
techniques to comprehensively detect and analyze how apps collect
ing in wireless scanning.
geolocation data through BLE and WiFi beacons, its dissemination
with user IDs, and the SDKs offering such solutions. We note that, • Step 1: Identifying Known SDKs. To identify SDKs that per-
due to the inherent limitations of black-box testing, we do not form BLE and WiFi scanning, we begin with an initial set of
claim completeness. However, our methods provide actual evidence SDKs listed by Exodus [104] and Libradar [84], two widely used
of privacy concerns associated with the use of wireless scanning SDK detection tools. While these tools cover popular advertising
capabilities by SDKs. We next describe each of the components of and analytics SDKs and label them based on their capabilities
our methodology. (including BLE and WiFi capabilities), they are not comprehen-
sive, potentially missing newer or less-documented SDKs as well
4.1 Dataset as scanning-specific SDKs. From these sources, we identify an
We use the AndroZoo dataset [6] to collect 1,008,539 apps uploaded initial list of 14 SDKs related to BLE/WiFi scanning.
after January 2023. AndroZoo is a large-scale collection of Android • Step 2: Targeted Online Searches. We expand the initial list of
apps that includes over 10 million items historically indexed on SDKs identified in Step 1 by conducting web searches for com-
the Google Play Store. We filter this dataset to select 574K apps mercial SDKs offering proximity, location, and Bluetooth/WiFi
available in the Google Play Store when accessed from the European scanning functionalities. For that, we perform targeted keyword
4
Your Signal, Their Data Proceedings on Privacy Enhancing Technologies YYYY(X)

searches using Google’s search engine. 5 This process identi- the shouldShowRequestPermissionRationale() API, which pro-
fied 22 additional SDKs that were not included in the initial list. vides an educational UI explaining why a specific permission is
However, some results are false positives triggered by keyword needed to enable a feature. App developers should declare these
matches while the SDKs do not implement beacon scanning. attributes to ensure transparency so their absence can indicate a
Hence to confirm functionality, we manually review official doc- lack of proper disclosure. These elements are studied in §6.4 to
umentation, API references, integration guides, and discussions assess beacon SDKs’ transparency over data collection.
in SDKs’ developer forum, along with source code repositories Code Analysis. We use Androguard [8] to extract Dalvik byte-
(where available) to identify SDKs that explicitly invoke BLE or code and identify SDK signatures (e.g., class names and APIs) that
WiFi scanning capabilities. 6 indicate beacon SDK functionality and data dissemination. These
• Step 3: Refining & Expanding SDK Selection Through Static signatures are detailed in Table 8. To analyze execution paths, we
Analysis. We refine and expand the set of SDKs populated in construct control flow graphs (CFGs) for each app, where nodes
the previous steps, by applying the static analysis techniques represent methods or functions (with associated class names), and
illustrated in §4.3 to automatically analyze a subset of 362K apps edges denote function calls between them. CFGs trace execution
invoking methods indicative of beacon scanning. These features from source methods (e.g., Android lifecycle methods like onCre-
are extracted from the curated list of SDKs identified in Steps 1 ate() and onResume(), where SDKs typically initialize) to sink APIs
and 2, producing SDK signatures for each SDK that cover from that collect sensitive data, such as location (e.g., LocationMan-
system API calls related to BLE and WiFi scanning (e.g., ‘WifiMan- ager.getLastKnownLocation()) or beacon data (e.g., WiFi scan re-
ager.startScan()’ [38, 42]) to SDK attribution signals such as class sults). A mapping of API calls considered in this process is provided
names, URL endpoints, and custom permissions. Additionally, in Table 10. To attribute SDKs and identify SDKs actively being used
we search for special functionalities such as UUID broadcasting rather than dead code, we match class names in CFG nodes against
and RSSI analysis, which further indicate BLE/WiFi scanning known SDK signatures extracted from decompiled app code.
behavior. For reference, an example set of signals is provided in API Usage. To analyze how beacon-enabled apps interact with
Table 9 in the Appendix. After applying our refinement process, sensitive resources, we traverse the CFG to trace data flows. Starting
we identified a total of 55 SDKs. from sink APIs (e.g., ‘LocationManager.-getLastKnownLocation()’),
Validation. To ensure high-confidence detection and minimize we visit nodes backward to locate the source methods invoking
false positives, we manually analyze the code of up to three repre- these APIs. This approach links sensitive API calls to the Android
sentative apps per SDK to confirm whether these SDKs implement permissions protecting them, allowing us to study the data flows
scanning capabilities. This check allowed us to remove three SDKs within the app and also third-party SDKs that may piggyback on
designed for general connectivity with peripherals rather than for these permissions (§6.1). As an official and updated comprehensive
wireless scanning. At the end of this manual process, we curate a permission mapping database is not available, we construct one by
final signature set of 52 beacon SDKs features and signals, which combining: (1) pre-existing permission mappings from PScout [14],
we use to statically identify at scale apps integrating these SDKs. Androguard, and Axplorer [16]; and (2) mappings derived from
the @RequiresPermission annotations in the AOSP source code,
which we publicly release as part of our research artifacts.
4.3 Static Analysis
Cross-Library Analysis. We statically investigate interactions
We apply static analysis to examine how apps integrate and interact between SDKs embedded within the same app to identify depen-
with identified beacon SDKs. Specifically, we look for unique SDK dencies and data-sharing practices between co-located SDKs. Specif-
signatures (§4.2) to identify their presence across apps, including ically, we identify cross-library interactions by studying function
app manifest metadata (declared permissions, services, and intent calls where one SDK code invokes methods or accesses data from
filters) and code-level attributes. We also inspect execution paths another SDK. We attribute these interactions among SDKs by de-
via control flow analysis to determine how apps invoke, interact tecting function calls between classes associated with beacon SDKs.
with, or delegate scanning capabilities to other integrated SDKs, To distinguish cross-library interactions from app-internal calls, we
as we describe next. Our static analysis follows accepted research compare the class names of the caller and callee classes: if their top-
practices, focusing on studying public code structures and API and second-level domains (1) do not match each other, and (2) do
calls, ensuring that no proprietary insights or trade secrets are not match the host app’s package name, the interaction is flagged
extracted [13, 55, 101, 124]. as cross-library. We manually validate all detected interactions to
Permission Analysis. We use a custom-built parser to analyze avoid mis-reporting cross-SDK interactions.
the manifest of each app, extracting AOSP and custom permissions
requested by apps and beacon SDKs, along with their declared ser- 4.4 Dynamic Analysis
vices, providers, and receivers. We also analyze metadata such as Dynamic analysis allows us to gather actual evidence of beacon SDK
the neverForLocation attribute which indicate whether location runtime behavior by executing apps on instrumented devices [4, 80,
permissions are used exclusively for non-location purposes, and 106, 108]. Specifically, we observe how apps interact with sensitive
resources, handle beacon data (e.g., BLE, WiFi), transmit network
5We use keywords such as “beacon SDK,” “proximity SDK,” “BLE SDK,” and “WiFi traffic, and respond to injected BLE and WiFi signals. To achieve
beacon SDK.” this, we use a device farm comprising eight Android 9 and eight
6We manually identified more than 200 system APIs related to BLE and WiFi scanning
from Android’s official API reference and AOSP (Android Open Source Project) source Android 12 Google Pixel 3a smartphones located in the EU, each
code. These methods are released as part of our open-science approach. running an instrumented version of the operating system. This
5
Proceedings on Privacy Enhancing Technologies YYYY(X) Girish et al.

dual-version approach allows us to analyze how app behaviors Table 1: Top 20 SDKs in the dataset, classified depending
adapt to changes in the Android permission model across different on their beacon types: Bluetooth, WiFi or they operate as
versions and how SDKs may abuse legacy versions. integration partners. For the purpose of each SDK, in addition
Instrumentation. We use a customized AOSP version to trans- to analytics and location, we mark SDKs that offer advertising
parently monitor runtime resource access, such as accesses to (•) and profiling (⋄) services.
permission-protected APIs, BLE/WiFi scans, I/O file operations,
Total Beacon Purpose
and capturing all network traffic, by instrumenting the relevant SDK Name # Apps
Installs Type Type
methods and APIs to capture their activity. We observe reads and BLE WiFi Integration Analytics Location
writes to TLS sockets by instrumenting relevant APIs, allowing us to AltBeacon 4,022 5B ✓ ✓ ✓
Adobe Experience Platform 1,328 8B ✓ ✓
analyze network traffic without interfering with the TLS handshake Kochava • 1,117 15B ✓ ✓ ✓ ✓
Salesforce Marketing Cloud • 1,080 6B ✓ ✓ ✓
or using our own certificates. We also decode common encodings Estimote 510 201M ✓ ✓ ✓
like gzip and base64, along with bespoke obfuscation methods used LeanPlum ⋄ 456 8B ✓ ✓ ✓ ✓
Gimbal • 396 3308M ✓ ✓ ✓ ✓
by popular SDKs (e.g., Forter, JPush, and Yandex) to identify dis- Radius Networks 369 359M ✓ ✓
mParticle 367 2B ✓ ✓
seminated sensitive data, as discussed in §6.2. To complement our Ad4Screen • 198 1B ✓ ✓
static analysis-based SDK detection (§4.3), we instrument the An- Kontakt 195 31M ✓ ✓
CueAudio 190 9M ✓ ✓
droid Runtime (ART) to log classes loaded at runtime by tracking Swrve ⋄ 153 2B ✓ ✓ ✓
Reveal Mobile 109 6M ✓ ✓ ✓ ✓
the FindClass method of the class linker to detect classes loaded Exponea 99 191M ✓ ✓ ✓
during execution. This approach effectively increases the reliability Radar 93 482M ✓ ✓ ✓
IndoorAtlas 92 7M ✓ ✓ ✓ ✓
of static signals and enables the identification of obfuscated classes SignalFrame 89 56M ✓ ✓ ✓
Bazaarvoice 88 420M ✓ ✓ ✓
that static analysis might miss. Huq Sourcekit 81 347M ✓ ✓ ✓ ✓
Automatization. We use Android Monkey [9] to automate app
execution with synthetic UI inputs for 8-10 minutes. To bypass regis-
tration walls, each device is configured with unique pseudonymous behaviors. Beacon injection effectively triggers scanning in most
identifiers (e.g., phone numbers, email addresses, and usernames), cases but may not trigger SDKs relying on custom or proprietary
allowing us to trace the potential dissemination of this data in formats that are not publicly documented. Additionally, Android
network flows for ID bridging. Our automation also handles stan- Monkey automates standard interactions, though it cannot bypass
dard logins, including Single Sign-On (SSO) flows like Google SSO CAPTCHA or 2FA logins yet prior work [108] shows it explores
whenever applicable. code paths 60% similar to human interaction.
Beacon Signal Injection. In addition of automatizing UI inputs, it We run our experiments on EU-based devices where stricter
is essential to simulate realistic beacon signals to trigger runtime privacy rules apply so it is possible that specific SDK behaviors
responses in SDKs implementing them. We achieve this by inject- may vary in jurisdictions with more permissive regulations. Nev-
ing Bluetooth and WiFi scan results during app scans, simulating ertheless, these limitations do not compromise the validity of our
nearby devices or networks directly on our AOSP instrumentation. findings: while we do not claim completeness, our methodology
The injected BLE advertising data conforms to standard beacon effectively uncovers previously undocumented tracking behaviors
formats and includes beacon types such as iBeacon, AltBeacon, within beacon SDKs, highlighting systemic privacy risks and the
Eddystone (URL, UID), and GAEN beacons, formatted according to need to regulate their usage.
their respective standards [7, 65–68]. Additionally, we use a Rasp-
berry Pi 4 to replay intercepted BLE beacon payloads and MAC 5 Beacon SDK Landscape
addresses every 5 seconds, with the goal of exercising further app This section studies the beacon SDK landscape, focusing on their
activity upon beacons detection. Spurious WiFi networks are also purpose, market share (§5.1), and integration capabilities to leverage
injected, including SSIDs and BSSIDs, as well as SSIDs appended complementary features and data sharing (§5.2).
with _nomap and _optout, to evaluate whether SDKs respect router-
owners preferences to exclude their devices from scanning. We use 5.1 SDK Purposes and Prevalence
distinctive palindromic MAC addresses in the injected results to Using our SDK detection method (§4.2), we find the 52 SDKs with
monitor their dissemination in TLS flows to the cloud. beacon capabilities embedded in at least 9,976 apps collectively
installed on 55B devices.7 The market share and feature set of
beacon SDKs varies significantly. Table 1 lists the top-20 SDKs
4.5 Limitations categorized by beacon type (BLE, WiFi, or integration partners)
As with any empirical measurement study, our analysis is inherently and their primary and secondary purposes (e.g., analytics, location
constrained by the black-box nature of testing methods, the opacity services, or advertising). A full list is provided in Table 6 in the
of SDKs, and the continuous evolution of implementations. In fact, Appendix. The most widely used SDKs are AltBeacon (40% of apps),
our list of beacon SDKs extracted with static analysis methods may Adobe Experience Platform (13% of apps), Kochava (11% of apps),
not offer a complete picture of this complex landscape due to code Salesforce Marketing Cloud (11% of apps) and Estimote (5% of
obfuscation, reflection, and dynamic loading [25, 50, 86].
7 Google Play install counts provide an approximate range of market reach, not exact
Dynamic analysis successfully executes 97% of the apps, despite
adoption figures. Prior work has used them as a standard reference for estimating user
challenges like root detection, certificate pinning, emulator checks, base and impact, though they have limitations such as the exclusion of pre-installed
and behavioral fingerprinting, which may limit visibility into SDK or sideloaded apps [123].
6
Your Signal, Their Data Proceedings on Privacy Enhancing Technologies YYYY(X)

Table 2: Top 10 most common SDK combinations. Count is

the number of apps embedding each combination.

SDK Combination Count

(AltBeacon, Kontakt) 270
(AltBeacon, Radius Networks) 228
(CueAudio, Gimbal) 173
(AltBeacon, Areametrics, Cuebiq, Reveal Mobile) 117
(Adobe Experience Platform, Gimbal) 100
(AltBeacon, Cuebiq) 80
(LeanPlum, mParticle) 78
(AltBeacon, Salesforce Marketing Cloud) 73
(AltBeacon, Estimote) 67
(AltBeacon, Cuebiq, SignalFrame) 59
Total Unique SDK Combinations 281
Total Installs 6B

Figure 3: Cross-library interactions between beacon and non-

beacon SDKs (square nodes). Dotted lines represent interac-
tions between beacon SDKs, while solid lines show interac-
tions with non-beacon SDKs. Arrows indicate directionality,
apps),8 which are collectively embedded in apps with a total of
from caller to callee SDK, with colors denoting the specific
37 billion installs. While we find beacon SDKs in apps from every
APIs accessed.
Google Play store categories, they are more prevalent in Lifestyle
(12%), Shopping (9%), and Sports (8%), with BLE and WiFi beacon
SDKs being more prominent in specific market sectors: 5.2 Cross-Library Analysis
The 9,976 analyzed apps also include 331 non-beacon SDKs with fur-
• BLE beacon SDKs are found in 54% of the apps with a total in-
ther data collection capabilities, including advertising and tracking
stall count of 55B devices. They dominate the Lifestyle (20%) and
services. We study the interactions between beacon SDKs with other
Business (12%) app categories, with SDKs like Radius Networks
SDKs (including non-beacon SDKs) that are co-located within the
(44%) and Estimote (34%) more likely integrated in Lifestyle apps.
same app using the methodology outlined in §4.3. Such co-existence
Interestingly, all BLE beacon SDKs also support geofencing for
allows SDK operators to exchange sensitive data or complement
location-based services, including targeted advertising and prox-
their functionality including their tracking capabilities. In total,
imity marketing (e.g., Radius Networks and Estimote [47, 92]).
we identify 281 unique SDK combinations across the 9,976 apps
• WiFi beacon SDKs are found in 17% of the apps, totaling 72B
containing at least one beacon SDK. Table 2 reports examples of
installs. They are commonly found in Sports (16%) and News
such combinations, being AltBeacon and Kontakt the most common
& Magazines (10%) apps. The SDKs Yinzcam Sobek and Gimbal
combination, found in 270 apps (195M users).
SDKs [1] specialize in sporting events and live stadium experi-
Figure 3 captures SDK cross-invocations and data flows. We
ences. Anecdotally, some apps in these categories also embed
detect 28 beacon SDKs exposing APIs for cross-library interaction
audio beacon SDKs (e.g., CueAudio) to synchronize location data
and data sharing to others. We note that location APIs (red) are the
with contextual audio signals, enhancing real-time interaction
most frequently invoked, often transmitting data from beacon SDKs
and audience tracking [26].
to advertising and analytics services. WiFi-based APIs (green) are
used for network-based geolocation, while BLE APIs (blue) enable
Capabilities. Some of the beacon SDKs identified like Kochava
proximity-based functionalities. We classify these interactions in
or Adobe Experience Platform are well-known advertising and
two major categories:
tracking services [105]. We analyze the capabilities offered by bea-
Beacon SDK ↔ Beacon SDK Interactions. We find 17 beacon
con SDKs by inspecting their public documentation (see §4.2). We
SDKs invoking APIs from one another. Notably, AltBeacon and
observe that most of them claim to offer multiple features to app
Gimbal provide APIs frequently used by other beacon SDKs to
developers, primarily analytics services (43 SDKs, with a total in-
perform BLE scans and access location data. For example, X-Mode,
stall count of 52B installs), location services (40 SDKs, 41B installs),
a location data aggregator, uses AltBeacon’s APIs for BLE scan
advertising (9 SDKs, 21B installs), and user profiling (5 SDKs, 11B
results, while mParticle, a data integration platform, calls Radar’s
installs). These features are not mutually exclusive. For example,
APIs for location tracking. In some cases, multiple beacon SDKs co-
while the the main business area of Kochava, Salesforce Marketing
exist within the same app as in the French versions of McDonald’s
Cloud, and Adobe Experience Platform is an advertising, analytics
and Burger King apps to locate user at their premises, both using
and identity graph services, respectively, they also integrate beacon
AltBeacon for beacon scanning and indoor location tracking, and
scanning capabilities in some of their SDK versions to enhance
their analytics and advertising businesses with location data. This 8 Thesepercentages are relative to the total number of applications found with at least
increases the privacy risks for consumers. one beacon SDK (𝑁 = 9, 976).
7
Proceedings on Privacy Enhancing Technologies YYYY(X) Girish et al.

Woosmap for geofencing. Woosmap also invokes APIs from third- Table 3: Usage of BLE, Location, and WiFi permissions by the
party SDKs, such as Urban Airship, Salesforce Marketing Cloud, top 15 SDKs, showing manifest declarations, API calls, and
and Batch, via REST/OAuth APIs, enabling seamless data sharing specific BLE_SCAN tags introduced in Android 12+.
and SDK-to-SDK integration.
Beacon SDK ↔ ATS Interaction. We identify 24 beacon SDKs SDK Name # apps # Android 12+ BLE Location WiFi BLE_SCAN
Man. API Man. API Man. API % Req % Tag
sharing BLE/WiFi scan results and geolocation data with 21 non- AltBeacon 4024 1822 95% 91% 96% 0% 73% 0% 57% 18%
beacon ATS SDKs. This behavior is concerning as advertising SDKs Adobe 1328 514 35% 0% 80% 0% 89% 0% 9% 25%
Kochava 1118 499 20% 60% 42% 62% 97% 66% 5% 31%
like CleverTap and Twitter MoPub can use this information for Salesforce 1080 713 33% 0% 80% 0% 72% 0% 12% 25%
secondary purposes. Specifically, 11 ATS SDKs (e.g., UrbanAirship) Estimote 510 197 97% 93% 88% 58% 53% 0% 17% 18%
LeanPlum 456 231 18% 0% 60% 0% 98% 74% 13% 14%
invoke WiFi scanning APIs of 6 different beacon SDKs (e.g., Gim- Gimbal 396 160 98% 82% 99% 81% 99% 58% 24% 3%
Radius Networks 369 94 86% 83% 91% 0% 84% 0% 31% 21%
bal), and 16 ATSes invoke geolocation APIs from 22 beacon SDKs. Ad4Screen 198 75 0% 0% 0% 0% 0% 0% 8% 17%
Interestingly, the Yinzcam Sobek SDK calls APIs from Fluzo, an Au- Kontakt 195 82 94% 91% 99% 0% 62% 0% 84% 3%
Swrve 153 76 14% 0% 42% 0% 86% 0% 5% 25%
tomatic Content Recognition (ACR) SDK, for audio fingerprinting in Exponea 99 68 24% 3% 78% 3% 79% 3% 6% 50%
the La Liga app (version 7.2.1), a potential GDPR violation that was Radar 93 61 38% 32% 99% 0% 80% 0% 25% 7%
Bazaarvoice 88 67 38% 0% 95% 0% 88% 0% 19% 31%
investigated by the Spanish Data Protection Agency (AEPD) [46]. Rover SDK 50 26 98% 70% 94% 0% 84% 0% 12% 67%
Zendrive 34 16 85% 59% 100% 0% 100% 79% 75% 8.30%
Such practices highlight the complexity of data sharing and syn- Sensoro 4 2 100% 75% 100% 75% 75% 0% 100% 50%
chronization across-SDKs for secondary purposes like advertising. Abbreviations Used: # Android 12+ - Number of apps targeting Android 12 or above;
Unfortunately, these capabilities introduce unexpected security % Req - Percentage of BLE_SCAN permission requests; Man. - Manifest;
API - API calls; % Tag - Percentage of apps using the neverForLocation tag.
and privacy concerns due to Android’s coarse-grained sandbox and
permission model. Since there is no security boundary between
libraries within the same app process, one library can interact with
another (e.g., invoking functions) to access IDs and sensitive data suggests the existence of close ties between beacon SDKs and geo-
without restrictions or user awareness [124]. Unlike the same-origin location services. Interestingly, 28% of these apps request audio
policy for limiting cross-site tracking on the web, Android’s lack of permissions, which in some cases could be used for ultrasonic
cross-SDK isolation mechanism allows them to access and share beaconing [12, 88, 98]. However, the analysis of audio-tracking
data within the same app process without any restrictions. technologies is outside the scope of this paper. Finally, over 40% of
apps request phone state permissions to access the IMEI on Android
6 Privacy Analysis 9 and 35% the AAID on Android 12.
Most of the analyzed apps with beacon SDKs (77%) self-disclose We inspect the code of apps requesting these permissions to de-
the collection of user data through Google Play’s data safety labels. termine whether the caller class belongs to the app itself (first-party
The most frequently collected data are device IDs (62%), personal code) or the beacon SDK (third-party code) using the backward
information such as names, emails, and other user IDs (60%), and slicing technique described in §4. This process allows us to infer
location (35%) supposedly for app functionality (69%) and analytics the usage and purpose of API invocations by reasoning about the
(68%), followed by account management (51%), and advertising or business models of the SDKs requesting them according to publicly
marketing (36%). However, this information is self-disclosed by app available information. In line with our static permission analysis,
developers and may be erroneous or intentionally deceptive. we find that API usage for location tracking closely matches de-
In this section, we use our dynamic analysis pipeline (§4.4) to an- clared permissions. For WiFi, we observe an 11% decrease in API
alyze the runtime data collection practices associated with beacon usage compared to declared permissions, suggesting possible over-
SDKs across our 9,652 apps. Specifically, we study their permission permissioning or the presence of obfuscated code. For Bluetooth,
requests (§6.1) and monitor the dissemination of 18 sensitive data 18% of apps invoke Bluetooth APIs without declaring the corre-
types including beacon-specific data and user IDs (§6.2), demon- sponding permissions. This under-permissioning could stem from
strating how beacon data is often bridged with device IDs like the cases like Facebook and Ogury Ad SDKs, which provide multiple
AAID (§6.3). To contextualize our permission analysis in §6.1, we functionalities (i.e., advertising, location services, BLE), while app
conclude with an evaluation of how developers follow permission developers may use them just for very specific purposes.
consent best practices (§6.4). The results presented in this section Meanwhile SDKs like, AltBeacon and Estimote seem to have
constitute actual evidence of the dissemination of geolocation data legitimate high rates of Bluetooth-related permission requests—95%
linked to user IDs from apps to cloud services and across SDKs, and 97%, respectively—for detecting and interacting with beacons.
for potential secondary purposes like identity profiling, mobility Interestingly, 91% of apps integrating AltBeacon and also requesting
tracking, advertising and potentially data brokerage. location permission never invoke the corresponding AltBeacon
location APIs in Java code, indicating that the permission request
could be a requirement for complying with Android versions 11
6.1 Permission Analysis and lower. On the contrary, we observe how the majority of apps
We compare declared permissions in each app’s manifest with stati- integrating Estimote, LeanPlum, Gimbal or Radius Networks make
cally identified APIs to flag cases of over-permissioning. Our analy- use of the corresponding location APIs, as described in §5.
sis shows that 82% of the apps request either fine or coarse-grained The dual purpose of many Android permissions has been crit-
location permissions, 79% of beacon-enabled apps request WiFi icized for causing confusion among developers and users. To il-
permissions and 62% request Bluetooth-related permissions. This lustrate this, we analyze the manifest files to extract the presence
8
Your Signal, Their Data Proceedings on Privacy Enhancing Technologies YYYY(X)

Table 4: SDKs collect location data and exfiltrate identifiers 6.2 Beacon Data Collection
classified under global persistent IDs, app persistent IDs,
We study the runtime data access practices of beacon-enabled apps
global resettable IDs, app resettable IDs, WiFi/Bluetooth
using the dynamic analysis pipeline described in §4.4. We find that
scans, and GPS data (§3). Symbols indicate data collection on
they collectively contact over 25K unique domains, with 86% of
Android 9 (^), Android 12 (▼), or both (⋆). Highlighted rows
apps and 20% of domains collecting at least one of the sensitive
represent SDKs from our dataset; others are co-embedded
data types detailed in Table 4. While our dynamic analysis results
SDKs detected through dynamic analysis.
are a lower-bound estimation of the potential practices due to
Glob.
inherent coverage limitations of runtime analysis, they provide
SDK Glob. Pers. WiFi/BLE scan GPS
(# of Apps) App.
Rst.
App
actual evidence of SDK behaviors and potential privacy abuses.
Pers. Rst. Additionally, dynamic analysis extends SDK detection beyond static

BLE ibeacon MAC

Router scan MAC

Router Scan SSID
methods by uncovering wireless scanning behaviors in advertising,
# App. Installs

ibeacon UUID

Coarse gelog.
Router MAC

Router SSID

Fine geoloc.
Android ID

analytics, and fraud-detection SDKs missed by static analysis due

WiFi MAC

BLE Name
Boot ID

HW ID
GSF ID

to code obfuscation or reflection (§4.5).

AAID
Email
IMEI

FID

Kochava (220) 2B ^ ⋆ ⋆ ⋆ ⋆ We observe discrepancies between the app’s runtime behavior

Yandex (220) 572M
Amplitude (190) 988M
^
^
⋆
^
^
^
⋆
⋆ ⋆
⋆ ⋆ ⋆ ⋆
⋆ ⋆
and the declared safety labels. We find that 2,292 apps collect device
Datadog (140) 146M ^ ^ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ identifiers without disclosing them. For location data, a different
Sentry (81) 53M ^ ^ ⋆ ^ ▼ ⋆ ⋆ ⋆ ⋆
Omniture (49) 1B ^ ^ ⋆ ⋆ ⋆ ⋆ pattern emerges: only 23% of the 3,535 apps both declare the col-
Forter (34) 297M ⋆ ⋆
Radar (33) 280M
^ ^ ^
^ ^
^
⋆ ⋆ ⋆
lection of location data and transmit it at runtime while 563 apps
Huq Sourcekit (24) 25M ^ ⋆ ⋆ ⋆ ^ ^ ⋆ ⋆ transmit location data without disclosing it in their data safety la-
cellrebel (18) 134M ⋆ ⋆ ⋆ ⋆
Vizbee (16) 164M ^ ⋆ ⋆ ⋆ ⋆ ⋆ bels. For the rest of the analysis, we report how SDKs collect beacon
Cuebiq (6) 50M ⋆ ⋆ ⋆ ⋆ ⋆ ^ ^
taobao (6) 1B ^ ^ ⋆ and geolocation data across apps and distinguish beacon SDKs from
My Tracker SDK (6) 132M ⋆ ⋆ ⋆ non-beacon SDKs that also exhibit beacon scanning behaviors.
AdsWizz (6) 9M ⋆ ^ ⋆ ⋆
phunware (5) 78K ⋆ ⋆ ⋆ ⋆ ⋆
conviva (5) 134M ^ ⋆
^
⋆ ⋆ ⋆ ⋆
Router: SSIDs and BSSIDs represent the names and MAC addresses
PayPal (5) 100M ⋆ ^ ^ ^ ⋆ ^ ⋆ ⋆ ⋆ of connected and nearby WiFi networks. They serve as precise loca-
Singlespot (5) 30M ⋆ ⋆
Incognia (5) 38M ⋆ ^ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ tion proxies [106]. We find that 1.95% and 1.62% of apps collect the
Colocator (4) 395K ^ ⋆
Swrve (3) 9M ^ ⋆ router SSID and BSSID of their connected WiFi access points, re-
JPush (3) 346K ⋆ ⋆ spectively. At the SDK level, 29 of them collect either router SSIDs or
Kontakt (3) 23K ⋆
Proxy Cloud (2) 7M ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ BSSIDs, with only 4 SDKs collecting both. Furthermore, 0.32% of the
pingID (1) 3M ^ ^ ▼ ⋆
appICE (1) 3M ⋆ ⋆ ⋆ ^ ^ apps and 8 different SDKs extend their reach to the SSID and BSSID
Tangerine (1) 3M ⋆ ⋆
Proximi.io (1) 162K ▼
of nearby WiFi access points. Leading beacon SDKs collecting AP
data include Kochava, Colocator, Cuebiq—which was removed from
the Play Store due to invasive data collection practices [71]—and
non-beacon SDKs like Yandex, JPush [107], and Incognia that offer
advertising, fraud prevention, and push notifications solutions [69].
Jointly, these SDKs account for 4B total installs.
of the BLUETOOTH_SCAN permission and the usage of the neverFor- BLE: we observe 218 apps disseminating the device’s Bluetooth
Location flag, introduced for apps targeting Android 12 or higher, name—i.e., the user-friendly name often defined by users and po-
as the official Android documentation recommends [37]. As sum- tentially containing PII like a user’s name [34]—to cloud services.
marized in Table 3, only 18% of apps that include AltBeacon and Additionally, 18 apps collect the AltBeacon UUID and 6 collect the
request Bluetooth scan permissions set also the neverForLocation iBeacon UUID, both of them being unique and persistent IDs tied
flag, indicating that the remaining apps likely use this permission to a specific physical location. At the SDK level, 7 beacon SDKs
both for BLE scanning and location purposes. Furthermore, only collect the device’s Bluetooth address, 3 targets the iBeacon UUID,
3% of the apps integrating Kontakt SDK set this flag. Among the and 1 collects the iBeacon MAC address. Huq Sourcekit, Kontakt,
SDKs offering location data aggregation—e.g., Kochava, Adobe Ex- and Radar are the most prevalent SDK with such capabilities, with
perience Platform, and Salesforce Marketing Cloud—the use of this a cumulative install count of 280M users. These results suggest that
flag ranges from 25% to 35%. We observe that, while apps can use BLE scanning is comparatively less prevalent than WiFi scanning.
the neverForLocation flag with the NEARBY_WIFI_SCAN permission, This discrepancy could stem from the more controlled scanning
only 11 apps request this permission, and only 6 set the flag. methods offered by SDKs, or the use of geofencing—where scans are
Overall, our results show that only a minority of apps using only enabled within specific areas—that limit our dynamic testing
scan APIs explicitly declare the intention of not to use these meth- approach, as detailed in §4.5.
ods for location tracking purposes through mechanisms like the GPS Sensors: 20% and 18% of apps actively collect coarse or fine
neverForLocation flag. Meanwhile, a significant proportion of apps geolocation data, respectively. The majority of apps with beacon
integrating SDKs like Gimbal, LeanPlum, or Kochava appear over- SDKs declare access to Android geolocation permissions, either
permissioned, requesting more access than may be necessary. Un- fine (78%) or coarse location (77%) and even when the app is put in
fortunately, these practices can create potential opportunities for the background (20%). The 13 beacon SDKs collecting location data
third-party data harvesting, as we show next.
9
Proceedings on Privacy Enhancing Technologies YYYY(X) Girish et al.

20%

Intersection
com . geomobile . tiendeo outbound to api . radar . io :443
POST / v1 / logs HTTP /1.1 15%

size
Content - Type : application / json 10%
Host : api . radar . io 5%
..
0
" androidid ":" XXXXXXXXXXXXXX "
20% Global persistent ID
{
20% App resettable ID
" createdAt ": 1720523270332 , 33% WiFi/BLE scan
" level ": " DEBUG " , 40% GPS data
" message ": " Ranged beacon | beacon . type = IBEACON ; beacon . uuid = 01022022 - 49% App persistent ID

fa0f -0100 -00 ac - dd1c6502da1c ; beacon . major = 53479; beacon . minor = 70% Global resettable ID

42571; beacon . rssi = -12"

},
{ Figure 5: The UpSet plot illustrates how SDKs collect differ-
" createdAt ": 1720523270334 ,
" level ": " DEBUG " ,
ent combinations of ID categories. The top bars represent the
" message ": " Handling beacon entry | beacon . type = IBEACON ; beacon . uuid = percentage of SDKs collecting specific combinations (indi-
01022022 - fa0f -0100 -00 ac - dd1c6502da1c ; beacon . major = 53479; beacon .
minor = 42571; beacon . rssi = -12"
cated by connected dots below), while the left bars show the
}, total percentage of SDKs collecting each category, regardless
" events ":[] , " nearbyGeofences ":[{" _id ":"6318 a0381c18820019e1e07e " , " live ": true , of other data types collected.
" type ":" circle " , " tag ":" es . s . m " ," externalId ": "103769" ," geometryCenter ":
{" coordinates ":[ longtitude : -X . XXXXX , latitude : XX . XXX ] ," type ":" Point "} ,

This SDK transmits sensitive data, including SSIDs, security types

Figure 4: iBeacon advertisements and geofence data exfil- (e.g., WPA_PSK), network associations, and device IDs like the
trated to Radar.io, including Android ID, beacon details IMEI. In contrast, version 2.4.12 of the Forter SDK integrated in
(UUID, major, minor, RSSI), and geofence metadata (coor- apps targeting Android 12 collects even more extensive network
dinates and type). data, from DNS and DHCP details to WiFi scan results of nearby
SSIDs and their security configurations, device traffic statistics,
device IDs, and DNS settings.
include Radar, Salesforce Marketing Cloud, Rover SDK, LeanPlum,
and Huq Sourcekit, with a cumulative install count of 4B devices.
Additionally, we observe 33 non-beacon SDKs within the same 6.3 ID Bridging
apps accessing the location data, with OneSignal, Amplitude, Braze, ID bridging is a privacy-intrusive practice that weakens the privacy
and Flurry being the most prevalent ones. Among the SDKs that protections of resettable identifiers (e.g., AAID) and allows the cre-
collect the device’s GPS location, 15 gather also the WiFi AP SSID ation of rich and persistent user profiles for advertising, identity
and BSSID. Similarly, as shown in Figure 4, Radar SDK collects the profiling, and surveillance. We identify 61 SDKs potentially per-
device’s GPS location along with BLE ibeacon data to potentially forming ID bridging, including 16 beacon SDKs and 45 non-beacon
improve location accuracy and enable precise location tracking [19]. SDKs. Figure 5 summarizes the instances of ID bridging captured by
Yet, this collection of location data solely for advertising or analytics our dynamic analysis pipeline, showing how beacon SDKs bridge
purposes may potentially violate Google’s Play Store policies [99]. various types of device IDs, geolocation, and BLE/WiFi scan results.
Side-channels: we identify two non-beacon SDKs exploiting known Overall, 70% of the beacon SDKs also collect global resettable IDs
vulnerabilities in older Android versions to perform wireless scans like the AAID and BLE device name, and 41% collect global persis-
by bypassing permission requirements as of August 2024. The pres- tent IDs like the GSF ID. Oftentimes, both persistent and resettable
ence of such SDKs on the Play Store suggests that Google Play global IDs are bridged alongside WiFi or BLE scans (32% of all SDKs)
Protect may fail to detect apps invoking vulnerable APIs. or geolocation coordinates directly collected from the GPS sensor
(39% of SDKs). We note that the uniqueness of human mobility
• Vizbee SDK is a third-party library for mobile-to-TV deep-
traces makes user de-anonymization through geolocation data fea-
linking present in apps with over 164M installs. Vizbee exploits
sible, as demonstrated in prior work [30]. ID bridging strengthens
the side channel vulnerability CVE-2020-0454 [2] to collect AP’s
this risk by linking mobility data with other identifiers, allowing
SSIDs in Android versions 9 and below. The SDK uses the on-
precise user re-identification and persistent tracking. Prominent
CapabilitiesChanged callback function, registered via Connec-
beacon SDKs such as Kochava, Adobe Experience Platform, and
tivityManager’s NetworkCallback, which inadvertently provides
Cuebiq, as well as non-beacon SDKs present in the analyzed apps
SSID data. Vizbee caches and transmits this data to metrics.
like Yandex, Adjust and AdColony appear to perform these prac-
clasptws.tv under the key WIFI_SSID (See Table 12 in the Ap-
tices. We highlight some notable cases next.
pendix). The transmission also includes GEO_LAT and GEO_LONG
fields with values set to UNKNOWN, indicating that location WiFi/BLE Scans with Global IDs: 33% of SDKs collect WiFi or
permission is denied in this test. Vizbee stores the SSID in a vari- Bluetooth scan data, 10% combine this data with global persistent
able named hackedSsid, suggesting a deliberate attempt to bypass IDs, and another 15% with resettable IDs. These practices typically
Android permission controls. follow three main patterns:
• Forter SDK (v2.4.11) present in apps with over 297M installs, • Connected Router Data: 19% of SDKs collect either resettable
exploits the legacy API ‘WifiConfiguration.SSID‘ in Android 9 or persistent user/device IDs along with connected WiFi network
devices to collect SSIDs without requiring location permissions. information (e.g., router MAC, router SSID), while 15% of SDKs
According to current market shares, these vulnerabilities remain extend this by linking the Android ID with connected router de-
active on approximately 9% of Android devices globally [116]. tails. Namely, beacon SDKs such as Kochava, Adobe Experience
10
Your Signal, Their Data Proceedings on Privacy Enhancing Technologies YYYY(X)

Table 5: Packages with Yandex SDK, collecting multiple IDs. with the AAID. To protect users’ privacy, the Google Play Store
user data policy explicitly prohibits linking persistent IDs with
Router resettable ones like AAID for advertising or analytics purposes

Android ID
unless explicitly disclosed to users via privacy policies or in-app

WiFi MAC

Scan MAC
Scan SSID
consent dialogs [41]. However, our findings suggests that such link-

Installs

AAID

MAC
IMEI

SSID
ing still occurs, which could potentially enable cross-app tracking,
Package Name profiling, targeted advertising, and third-party data aggregation for
ru.dvaberega 968K x x x resale. We also find non-beacon SDKs like MixPanel, Amplitude,
com.numplates.nomera3 576K x x x x x and New Relic bridging other IDs like the Android ID with the IMEI
com.zenhotels.android 261K x x x x x x x x
com.wromanticgirlgame_10378860 60K x x x x x (in Android 9 and below) in 244 of the analyzed apps. MixPanel
com.weSPPTPBBKotaBogor_13752947 39.4K x x x x x further enriches this profile by adding GSF ID. The privacy impli-
com.ratehawk.android 34.5K x x x x x x x x cations of our findings are concerning. In fact, beacon SDKs like
com.wMadaniQaidahUrdu_15187981 515 x x x x x Huq Sourcekit, Radar, Incognia, and Vizbee seem to opportunis-
com.wBukuMenwa_15656972 179 x x x x x
tically attempt to piggyback on the permissions requested by the
com.AirportTransportation_4990860 85 x x x x x
app developer to collect the full spectrum of IDs along with GPS
and BLE/WiFi data. For geolocation data, SDKs like Huq Sourcekit
Platform, and Colocator, along with non-beacon SDKs like Con- and Radar do not directly invoke location APIs but instead appear
viva, PingID, AppICE, Taobao, Vizbee, and Datadog, combine the to collect location data indirectly via host app permissions. We
AAID with the persistent GSF ID. For example, Figure 7 shows demonstrate the risks of ID bridging with two case studies:
Kochava collecting AAID with connected WiFi MAC. Similarly,
non-beacon SDKs like Yandex and Alipay incorporates the An- • Amplitude: This mobile analytics platform performs extensive
droid ID and WiFi MAC, enabling cross-session tracking linked to data collection practices by bridging precise GPS coordinates
precise network settings, regardless of AAID resets. We observe with IDs like the AAID, the Android IDs, and the IMEI (in An-
these practices in 5% of the apps that we analyze. droid 9 and below). Combining location data with persistent or
• Nearby WiFi Scans: Six SDKs upload nearby WiFi network data resettable IDs for analytics purposes may violate Google’s pol-
(e.g., router scan SSID, router scan MAC), along with user IDs. icy [99]. Additionally, Amplitude collects user email addresses, as
For instance, Cuebiq and Incognia combine AAID and Android seen in apps like br.com.brainweb.ifood (100M+ downloads),
ID alongside both nearby and connected router scan data to track where emails are transmitted during the Sign In with Google
user movements across WiFi contexts, as shown in Figure 8. This OAuth event triggered in our testing. Of particular concern is
data may be collected to enhance location services via crowd- Amplitude’s ability to track every user interaction within the
sourcing. Notably, Yandex combines AAID, Android ID, WiFi app that embeds the SDK. Each user-triggered event is transmit-
MAC, IMEI (in Android 9 and below), and even clipboard data ted to Amplitude’s servers, along with precise GPS coordinates,
with both connected and nearby router data. Table 5 lists popular hence potentially enabling semi-continuous tracking of users’
apps with this behavior integrating the Yandex SDK. interactions and the exact locations where they occur.
• BLE Beacon Data: our analysis shows that three SDKs collect • Adobe Experience Platform collects various user identifiers
BLE beacon IDs such as iBeacon UUIDs or MAC addresses. This through demdex.net and *.omtrdc.net domains, including reset-
approach offers finer granularity than WiFi-based data and GPS table (AAIDs), globally persistent (WiFi MACs, hashed emails),
location indoors. Proximi.io collects iBeacon UUIDs with device geolocation (router SSIDs, GPS), and app- or device-scoped IDs
fingerprints, while the Kontakt SDK gathers iBeacon MAC ad- (Firebase installation IDs, Android IDs). Additionally, Adobe sets
dresses. Radar further integrates iBeacon UUIDs with GPS data, its proprietary marketingCloudId, a “persistent and universal iden-
Android IDs, and AAIDs to enable detailed location-based track- tifier designed to track users across all Adobe Experience Cloud
ing tied to physical BLE infrastructure even after AAID resets. products and subsidiaries” [5]. Such SDK-specific IDs add opacity,
limit user control and enabling potential ID bridging. In over
GPS Data with Global Resettable or Persistent IDs: 39% of SDKs 16 apps, we find the adobedtm tracker to collect hashed emails
collect GPS data along with user IDs. This includes beacon SDKs alongside the marketingCloudId. This data is stored in a dictio-
such as LeanPlum, Huq Sourcekit, and Cuebiq, and non-beacon nary labelled “PII” and logged under an event named PiiInfor-
SDKs like Vizbee, Incognia, and Conviva. Interestingly, Incognia mationReceived, suggesting an intentional collection of PII. We
goes a step further by harvesting the Boot ID, a 64-bit unique hex also observe cross-library interactions and potential data sharing.
string ID generated on a device’s first boot and stored securely, that In com.totalwine.app.store (1M+ downloads), the marketing-
should remain constant for the lifetime of the device unless the CloudId is shared with Appsflyer alongside AAIDs, suggesting a
user performs a factory reset. direct interconnection with Adobe’s identity graph solutions.
AAID Bridging: We find that 14% of SDKs link the AAID with
global persistent IDs such as the IMEI (available only on Android
9 or below) or GSF ID. In more than 180 apps, beacon-enabled an- 6.4 Permission Usage Rationale
alytics and marketing SDKs such as Adobe Experience Platform Android’s official developer guidelines recommend that apps clearly
and LeanPlum appear alongside non-beacon counterparts like Am- communicate the necessity of the permission requests and the po-
plitude, Sentry, and MixPanel, which appear to bridge the IMEI tential impact if the user denies it [36]. Android 6.0 introduced the
11
Proceedings on Privacy Enhancing Technologies YYYY(X) Girish et al.

shouldShowRequestPermissionRationale() method to inform develop- these apps. Their wireless devices, such as headphones or AirTags,
ers if their app should explain to the user the purpose of a requested can be continuously observed by passive scanners. While our fo-
dangerous permission. cus is on mobile apps, similar tracking risks may exist—including
Beacon SDK-enabled apps pose significant privacy risks to users connected platforms (e.g., IoT)—highlighting the need for better
while offering them little to no control over data collection. To transparency, accountability, and regulatory safeguards.
demonstrate this, we measure their compliance with Android’s Beacon SDKs and Location Surveillance. In §6 we demonstrate
permission request guidelines when requesting dangerous permis- how beacon SDKs continuously scan for WiFi, Bluetooth, and GPS
sions. We do this by statically searching for instances where beacon signals, supporting a vast data ecosystem of targeted advertising
SDKs invoke the shouldShowRequestPermissionRationale() and re- and data brokers [75]. For instance, Singlespot, a French marketing
questPermissions() methods. We then parse the permission strings firm, claims to have collected data from 2 million users and sells it
associated with these function calls. Finally, we analyze the app’s for up to $20,000 via platforms like Datarade [113]. If persistent iden-
UI components to detect any consent dialogs, such as alerts and tifiers are linked to specific geolocations, SDKs can then leverage
banners, that might be used to explain the permissions. By contex- WPS, data brokers and public databases to infer the users’ location
tually linking all these elements, we infer whether the app clearly and accurately track their movements. Such knowledge is harmful
provides a rationale for the requested permissions. to users’ privacy because it can disclose information about their
We find that 24% of apps in our dataset do not implement the personal beliefs or sexual orientation, or it can even reveal classified
shouldShowRequestPermissionRationale() API and include a ratio- information such as the location of secret facilities [30, 45, 62, 128].
nale for permission requests. Among those that do implement the Beyond first-hand data collection, beacon SDKs may also share or
API, 92% rely on third-party SDKs to provide such explanations cor- repurpose the data they obtained [75]. As we analyzed in §5.2, SDKs
rectly, a transparency feature beyond the control of app developers. co-located on the same app can exchange the collected information.
Additionally, the presence of these justifications varies significantly This interconnectivity enables pervasive data flows across orga-
across permission types: 71% of apps requesting location data fail to nizations, where user-tagged beacon data spreads across multiple
justify access, only 13% of apps justify FINE_LOCATION access, 7% third parties. Similarly, as shown in §6.3, proprietary identifiers like
for COARSE_LOCATION, and 8% for BACKGROUND_LOCATION, Adobe’s Marketing Cloud ID get linked with persistent and reset-
in all cases primarily handled by third-party SDKs. The lack of table user IDs and then shared with other SDKs. These practices
justification is even worse for Bluetooth permissions, with 97% of circumvent user control and blur accountability.
apps providing no explanation despite its known tracking risks. Platform Policy Enforcement. Google Play has introduced poli-
Our results suggest that, most developers underestimate BLE data cies designed to protect user privacy by imposing strict rules on
risks compared to location data. what data apps can collect and how they use it. According to these
On the other hand, only five beacon SDKs in our dataset use policies, developers are responsible for ensuring that any SDKs
the shouldShowRequestPermissionRationale() API to explain specific embedded in their apps do not sell or misuse sensitive user informa-
dangerous permissions. Estimote shows rationales for coarse loca- tion they collect [100]. For instance, one policy explicitly prohibits
tion in 75% of apps embedding it. Radar, Salesforce Marketing Cloud, linking user data or resettable IDs (e.g., AAID) with persistent de-
and Singlespot show fine location rationales in 42%, 54%, and 55% vice IDs or PII for advertising [99]. However, while analyzing apps
of apps, respectively. Additionally, InMarket provides rationales for in practice, we find that 14% of SDKs (§ 6.3) bridge resettable iden-
accessing background location in 52% of apps. In contrast, SDKs like tifiers with persistent ones. Such identifier bridging undermines
Swrve and IndoorAtlas delegate this responsibility entirely to app Android’s privacy safeguards, as resetting identifiers no longer
developers despite invoking permission-protected APIs themselves. limits continuous user tracking. A second recital mandates clear
Swrve implements a callback to check if the rationale was shown to user disclosure for any location data collected for ads, ensuring
the user [118], allowing it to piggyback on the app’s permissions. transparency and data minimization. Unfortunately, these policies
These findings highlight systemic transparency failures in how shift the burden to developers. As they rush their market release,
beacon-enabled apps handle permission requests, leaving users regulatory complexity, inexperience, and incomplete SDK docu-
with little insight or control despite the dual usage of these permis- mentation hinders compliance. To enforce compliance and detect
sions. Stricter auditing, policy interventions and broader ecosystem policy violations, marketplaces could implement stricter indepen-
reforms are necessary to address these gaps as we discuss next. dent audits before app release, runtime monitoring, and publicly
disclose audit results for transparency.
7 Discussion Regulation and Transparency. Regulatory efforts in the EU and
Our study reveals the pervasive tracking risks of beacon-enabled the US aim to mitigate privacy risks and enhance transparency
SDKs in Android. By analyzing behaviors, cross-library interactions, in mobile platforms. GDPR [48] mandates data minimization and
and data collection practices, we show how beacon SDKs track consent, yet enforcement remains a challenge due to opaque SDK
users across apps and services. Building on Dehaye and Reardon’s data-sharing practices. Meanwhile, CNIL and AEPD have issued
premise [32], our findings challenge the assumption that BLE-based guidelines to curb passive wireless tracking [29, 31]. CNIL advises
distance authentication is secure against global passive adversaries. app developers to map data flows, SDK providers to document
The belief that large-scale Bluetooth surveillance is economically compliance, and marketplaces to enforce vetting. However, en-
unfeasible is flawed, as SDKs turn millions of everyday apps into forcement gaps persist as widespread over-permissioning (§6.1),
passive scanners. This shifts costs—power and data collection—to proprietary identifier use by SDKs (§6.3), and uncontrolled SDK-
users while enabling tracking of individuals who never installed driven data sharing beyond user control enable large-scale tracking,
12
Your Signal, Their Data Proceedings on Privacy Enhancing Technologies YYYY(X)

making regulatory oversight difficult. Our empirical findings re- social networks (LBSNs) [43, 44, 135, 137, 138], crowdsourced lo-
veal how beacon SDKs evade existing protections through wireless cation tracking [61, 112, 126, 133], and how GPS data from mobile
scanning, cross-SDK interactions, and non-compliant tracking. By apps [43, 44, 137] inadvertently reveals sensitive information such
highlighting these risks, our analysis calls for strengthening audits, as military base locations or can be exploited for stalking and harass-
mandating SDK disclosures, and stricter enforcement to ensure ment [133, 138]. On the other hand, studies of Call Detail Records
compliance and curb unchecked data collection. (CDRs) and Twitter geolocation data revealed the uniqueness and
Defense Measures. Our work highlights systemic transparency predictability of human mobility patterns [30, 45, 57]. De Mon-
failures and policy gaps in the data collection practices of beacon- tjoye et al. [30] demonstrated that with just four location points it
enabled apps and Android’s transparency features. Mitigating these is possible to uniquely identify 95% of individuals However, there
risks requires stronger privilege separation and sandboxing to limit is a gap in the literature on how location data is collected, who
cross-library data sharing. While Google’s Privacy Sandbox is in operates these location data services within the mobile ecosystem,
the right direction, it only isolates advertising SDKs [59]. Stricter and how they can be misused to track users and their movements.
runtime audits and app store vetting are needed to detect covert Mobile App Privacy. Privacy risks in mobile apps have been
SDK behavior, yet these rely solely on platform enforcement, leav- extensively studied using static [13, 82, 89, 96, 125, 137] and dy-
ing users with no control over beacon data collection and sharing. namic [43, 80, 105, 106, 120] analysis techniques to uncover ma-
This lack of control is worsened by the absence of transparency licious behaviors, third-party code implications [52, 85, 105, 132],
mechanisms in the beacon ecosystem. As shown in §6.4, the should- transparency issues [11, 49, 80], and regulatory compliance gaps [77,
ShowRequestPermissionRationale() API designed to improve user 79, 94, 95, 136]. However, the limitations of relying solely on static
awareness is rarely used, exposing gaps in permission governance. or dynamic analysis [18, 25, 55, 101] have led to hybrid approaches
Existing privacy controls offer little protection against abuse. The that more effectively expose side and covert channels [102, 106, 124]
FCC suggests setting Bluetooth to hidden mode, but this only pre- and privacy risks from analytical SDKs [33, 105, 115, 117]. Despite
vents device discovery, not beacon scanning [20]. Addressing these several proposed solutions like privacy policies and labels, discrep-
risks requires a multi-layered approach, including stricter app store ancies still persist between stated and actual data usage [11, 63, 132].
policies, independent audits, and technical safeguards to curb un- Our work does not use formal privacy accounting frameworks that
regulated beacon tracking. While our work focuses on policy and rely on mathematical models to estimate privacy issues, such as
platform-level privacy controls, future research can explore usabil- data de-anonymization or re-identification [30, 43, 44, 133]. On
ity improvements to enhance user awareness and transparency. the contrary, we align with prior empirical privacy research that
combines static and dynamic analysis to measure the prevalence
8 Related work of beacon data-collection behaviors and estimate the number of
WiFi and BLE Scanning. Studies have shown how WiFi probe affected users [52, 80, 83, 95, 105, 106, 108].
requests, which lack encryption and authentication, are exploited
to track users and establish social links using SSIDs and BSSIDs [27, 9 Conclusions
53]. This data contributes to large databases created through tech- This paper presents the first large-scale empirical analysis of wireless-
niques like wardriving, enabling passive location tracking by third scanning SDKs in the Android ecosystem. By combining static and
parties [111]. Rye and Levin [110] highlighted the risks by revealing dynamic analysis with signal injection and runtime monitoring,
how Apple’s WiFi Positioning System (WPS) mapped geolocations we reveal how 52 SDKs across 9,976 apps exploit Bluetooth and
for over 2 billion BSSIDs globally, enabling mass surveillance. On WiFi scanning to infer user location and collect sensitive data. Our
the other hand, vulnerabilities in Bluetooth have been exploited to findings reveal that this ecosystem is tightly connected with adver-
track users [17, 28, 51, 74, 81], spoof, and perform denial-of-service tising and tracking purposes and operates with minimal oversight.
attacks [78] and exfiltrate private data [103]. Achara et al. [4] high- Most SDKs collect geolocation data for such secondary purposes
lighted how Android’s WiFi permissions were exploited by apps and violate platform policies by engaging in ID bridging—linking
to infer user locations, prompting stricter controls by linking WiFi persistent and resettable identifiers to construct detailed user pro-
data to location permissions. files without user consent or knowledge for persistent user track-
Several studies also identified privacy abuses across apps and ing. Some SDKs even intentionally exploit side channels to access
SDKs. Reyes et al. [108] exposed children’s apps harvesting WiFi sensitive data and IDs without requesting the pertinent Android
data to infer locations, violating COPPA. Reardon et al. [106] un- permissions. We provide concrete evidence of non-compliance with
covered covert channels in Android used to infer user locations. platform policies and inadequate enforcement of existing rules. Our
Dehaye and Reardon [32] showed SDKs like X-Mode harvesting study demonstrates that existing privacy protections are insuffi-
Bluetooth scans for user tracking to demonstrate the existance of cient, highlighting the need for stricter regulatory control, robust
global passive adversaries in the context of contact tracing apps. SDK sandboxing to limit cross-library data sharing, proactive audits
Building on this, our work provides the first empirical, large-scale to curb policy violations, and stronger transparency mechanisms
analysis of the Android beacon ecosystem, revealing how SDKs to prevent large-scale tracking and ensure user control.
utilize GPS, BLE beacons, and WiFi signals to track user proximity
with high precision and link this data to the user or device IDs.
Location. Location privacy has drawn significant research atten- Acknowledgments
tion due to the rise of location-based services (LBS). A large body We thank the reviewers and the shepherd for their valuable feed-
of work has focused on GPS data dissemination in location-based back and suggestions for improving our paper. We used OpenAI’s
13
Proceedings on Privacy Enhancing Technologies YYYY(X) Girish et al.

ChatGPT to correct grammatical errors and to improve the clar- Automated Software Engineering (ASE).
ity and coherence of our paper. The AI model was used with the [19] Wolfie Christl. 2024. Tracking Indoor Location, Movement and Desk Occu-
pancy in the Workplace. https://crackedlabs.org/en/data-work/publications/
following prompt: "please improve the clarity and coherence of the indoortracking.
text while maintaining the original intent". This research was par- [20] Federal Communications Commission. 2024. How to Protect Yourself Online.
https://www.fcc.gov/consumers/guides/how-protect-yourself-online.
tially supported by project PID2022-143304OB-I00 (PARASITE) [21] Federal Trade Commission. 2016. Mobile Advertising Network InMobi
funded by MCIN/AEI /10.13039/501100011033/ and by the ERDF Settles FTC Charges It Tracked Hundreds of Millions of Consumers’ Loca-
“A way of making Europe”, the Spanish National Cybersecurity tions Without Permission. https://www.ftc.gov/news-events/news/press-
releases/2016/06/mobile-advertising-network-inmobi-settles-ftc-charges-it-
Institute (INCIBE) under Proyectos Estratégicos de Ciberseguri- tracked-hundreds-millions-consumers.
dad – CIBERSEGURIDAD EINA UNIZAR, and by the Recovery, [22] Federal Trade Commission. 2024. FTC Order Prohibits Data Broker X-
Transformation and Resilience Plan funds, financed by the Eu- Mode/Outlogic from Selling Sensitive Location Data. https://www.ftc.gov/news-
events/news/press-releases/2024/01/ftc-order-prohibits-data-broker-x-mode-
ropean Union (Next Generation), the Natural Sciences and Engi- social-outlogic-selling-sensitive-location-data. In FTC Press Releases.
neering Research Council of Canada (NSERC) (funding reference [23] Federal Trade Commission. 2024. FTC v. Kochava Inc. https://www.ftc.gov/legal-
library/browse/cases-proceedings/ftc-v-kochava-inc.
number RGPIN/04237-2018), and the Spanish AEI grant CYCAD [24] Federal Trade Commission. 2024. How "Location, Location, Lo-
(PID2022-140126OB-I00). Dr. Srdjan Matic was partially funded by cation" Can Lead to "Enforcement, Enforcement, Enforcement".
the Atracción de Talento grant (Ref. 2020-T2/TIC-20184), funded https://www.ftc.gov/business-guidance/blog/2024/01/how-location-location-
location-can-lead-enforcement-enforcement-enforcement. In FTC Business
by Madrid regional government. Prof. N. Vallina-Rodriguez was Guidance Blog.
appointed as 2019 Ramon y Cajal fellow (RYC2020-030316-I) funded [25] Andrea Continella, Yanick Fratantonio, Martina Lindorfer, Alessandro Puc-
by MCIN/AEI/10.13039/501100011033 and ESF Investing in your fu- cetti, Ali Zand, Christopher Kruegel, Giovanni Vigna, et al. 2017. Obfuscation-
Resilient Privacy Leak Detection for Mobile Apps Through Differential Analysis..
ture. The opinions, findings, and conclusions, or recommendations In Proceedings of the Network and Distributed System Security Symposium (NDSS).
expressed are those of the authors and do not necessarily reflect [26] Cue. 2024. Cue - Creating Unforgettable Experiences. https://www.
connectwithcue.com/.
the views of any of the funding bodies. [27] Mathieu Cunche, Mohamed Ali Kaafar, and Roksana Boreli. 2012. I know who
you will meet this evening! linking wireless devices using wi-fi probe requests.
In IEEE Symposium on a World of Wireless, Mobile and Multimedia Networks
References (WoWMoM). IEEE.
[1] 2007. Gimbal Ad Platform. https://infillion.com/gimbal-ad-platform-learn- [28] Aveek K. Das, Parth H. Pathak, Chen-Nee Chuah, and Prasant Mohapatra. 2016.
more/. Uncovering Privacy Leakage in BLE Network Traffic of Wearable Fitness Track-
[2] 2020. CVE-2020-0454 Detail. https://nvd.nist.gov/vuln/detail/CVE-2020-0454. ers. In International Workshop on Mobile Computing Systems and Applications.
https://nvd.nist.gov/vuln/detail/CVE-2020-0454 National Vulnerability Data- [29] Commission Nationale de l’Informatique et des Libertés (CNIL). 2024. Recom-
base, National Institute of Standards and Technology (NIST). mandation relative aux applications mobiles. https://www.cnil.fr/sites/cnil/files/
[3] 2024. Ausspioniert mit Standortdaten. https://interaktiv.br.de/ausspioniert-mit- 2024-09/recommandation-applications-mobiles.pdf.
standortdaten/en/. [30] Yves-Alexandre de Montjoye, Cesar Hidalgo, Michel Verleysen, and Vincent
[4] Jagdish Prasad Achara, Mathieu Cunche, Vincent Roca, and Aurélien Fran- Blondel. 2013. Unique in the Crowd: The privacy bounds of human mobility. In
cillon. 2014. Wifileaks: Underestimated privacy implications of the AC- Nature.
CESS_WIFI_STATE Android permission. In Proceedings on Security and privacy [31] Agencia Española de Protección de Datos. 2024. Tecnologías de seguimiento
in wireless and mobile networks. Wi-Fi: Orientaciones para responsables del tratamiento. https://www.aepd.es/
[5] Adobe. 2023. Identifying Visitors in Adobe Target Delivery API. guias/orientaciones-wifi-tracking-seguimiento.pdf.
https://experienceleague.adobe.com/docs/target-dev/developer/api/delivery- [32] Paul-Olivier Dehaye and Joel Reardon. 2020. Proximity Tracing in an Ecosystem
api/identifying-visitors.html. of Surveillance Capitalism. In Proceedings of the Workshop on Privacy in the
[6] Kevin Allix, Tegawendé F. Bissyandé, Jacques Klein, and Yves Le Traon. 2016. Electronic Society.
AndroZoo: Collecting Millions of Android Apps for the Research Community. In [33] Soteris Demetriou, Whitney Merrill, Wei Yang, Aston Zhang, and Carl A Gunter.
Proceedings of the 13th International Conference on Mining Software Repositories. 2016. Free for all! assessing user data exposure to advertising libraries on an-
[7] AltBeacon. 2024. AltBeacon Specification. https://github.com/AltBeacon/spec. droid.. In Proceedings of the Network and Distributed System Security Symposium
[8] Androguard. 2024. Androguard. https://github.com/androguard/androguard. (NDSS).
[9] Android Developers. 2025. UI/Application Exerciser Monkey. https://developer. [34] Loleta Detweiler. 2023. How To Name Bluetooth Devices. https://robots.net/
android.com/studio/test/other-testing-tools/monkey tech/how-to-name-bluetooth-devices.
[10] Apple. 2024. Location Services and Privacy. https://support.apple.com/en- [35] Android Developers. 2024. Android 6.0 Changes: Behavior Changes.
us/HT207056. https://developer.android.com/about/versions/marshmallow/android-6.0-
[11] Ioannis Arkalakis, Michalis Diamantaris, Serafeim Moustakas, Sotiris Ioannidis, changes#behavior-hardware-id.
Jason Polakis, and Panagiotis Ilia. 2024. Abandon All Hope Ye Who Enter Here: [36] Android developers. 2024. App permissions best practices | Android Developers.
A Dynamic, Longitudinal Investigation of Android’s Data Safety Section. In https://developer.android.com/training/permissions/usage-notes.
Proceedings of the USENIX Security Symposium. [37] Android Developers. 2024. Bluetooth Permissions. https://developer.
[12] Daniel Arp, Erwin Quiring, Christian Wressnegger, and Konrad Rieck. 2017. android.com/develop/connectivity/bluetooth/bt-permissions#assert-never-
Privacy Threats through Ultrasonic Side Channels on Mobile Devices. In IEEE for-location.
European Symposium on Security and Privacy. [38] Android Developers. 2024. Find Bluetooth Devices. https://developer.android.
[13] Steven Arzt, Siegfried Rasthofer, Christian Fritz, Eric Bodden, Alexandre Bartel, com/develop/connectivity/bluetooth/find-bluetooth-devices.
Jacques Klein, Yves Le Traon, Damien Octeau, and Patrick McDaniel. 2014. [39] Android Developers. 2024. Permissions on Android. https://developer.android.
Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint com/guide/topics/permissions/overview.
analysis for android apps. In ACM sigplan notices. [40] Android Developers. 2024. Request Location Permissions. https://developer.
[14] Kathy Wain Yee Au, Yi Fan Zhou, Zhen Huang, and David Lie. 2012. PScout: android.com/develop/sensors-and-location/location/permissions.
Analyzing the Android Permission Specification. In Conference on Computer [41] Android Developers. 2024. User Data and Identifiers in Android. https://
and Communications Security (CCS). developer.android.com/identity/user-data-ids.
[15] Azira. 2024. Homepage. https://azira.com. [42] Android Developers. 2024. Wi-Fi Scan. https://developer.android.com/develop/
[16] Michael Backes, Sven Bugiel, Erik Derr, Patrick McDaniel, Damien Octeau, and connectivity/wifi/wifi-scan.
Sebastian Weisgerber. 2016. On Demystifying the Android Application Frame- [43] Karel Dhondt, Victor Le Pochat, Yana Dimova, Wouter Joosen, and Stijn Vol-
work: Re-Visiting Android Permission Specification Analysis. In Proceedings of ckaert. 2024. Swipe Left for Identity Theft: An Analysis of User Data Privacy
the USENIX Security Symposium. Risks on Location-based Dating Apps. In Proceedings of the USENIX Security
[17] Johannes Becker, David Li, and David Starobinski. 2019. Tracking Anonymized Symposium.
Bluetooth Devices. In Proceedings on Privacy Enhancing Technologies (PoPETs). [44] Karel Dhondt, Victor Le Pochat, Alexios Voulimeneas, Wouter Joosen, and Stijn
[18] Shauvik Roy Choudhary, Alessandra Gorla, and Alessandro Orso. 2015. Auto- Volckaert. 2022. A Run a Day Won’t Keep the Hacker Away: Inference Attacks
mated Test Input Generation for Android: Are We There Yet?. In Proceedings on on Endpoint Privacy Zones in Fitness Tracking Social Networks. In Conference
14
Your Signal, Their Data Proceedings on Privacy Enhancing Technologies YYYY(X)

on Computer and Communications Security (CCS). agencies-11593026382.

[45] Kostas Drakonakis, Panagiotis Ilia, Sotiris Ioannidis, and Jason Polakis. 2019. [73] Tom Karpiniec. 2023. The Road to Good Bluetooth Permissions on Mobile.
Please Forget Where I Was Last Summer: The Privacy Risks of Public Loca- https://ditto.live/blog/bluetooth-permissions-on-mobile.
tion (Meta)Data. In Proceedings of the Network and Distributed System Security [74] Edden Kashi and Angeliki Zavou. 2020. Did I Agree to This? Silent Tracking
Symposium (NDSS). Through Beacons. In HCI for Cybersecurity, Privacy and Trust.
[46] Rachel England. 2018. Spanish soccer league app spied on fans to catch pirate [75] Jon Keegan and Alfred Ng. 2021. There’s a Multibillion-Dollar Market for Your
broadcasts. https://www.engadget.com/2018-06-13-spanish-soccer-app-la-liga- Phone’s Location Data. https://themarkup.org/privacy/2021/09/30/theres-a-
spying-pirate-broadcast.html. multibillion-dollar-market-for-your-phones-location-data
[47] Estimote. 2018. Estimote Proximity SDK for Android. https://github.com/ [76] Tom Kemp. 2022. A Look at the Different Types of Data Brokers. https://www.
Estimote/Android-Proximity-SDK. tomkemp.ai/blog/2022/10/05/a-look-at-the-different-types-of-data-brokers.
[48] EU. 2018. General Data Protection Regulation. https://gdpr-info.eu/. [77] Simon Koch, Benjamin Altpeter, and Martin Johns. 2023. The { OK } is not
[49] Ming Fan, Jifei Shi, Yin Wang, Le Yu, Xicheng Zhang, Haijun Wang, Wuxia enough: A large scale study of consent dialogs in smartphone applications. In
Jin, and Ting Liu. 2024. Giving without Notifying: Assessing Compliance of Proceedings of the USENIX Security Symposium.
Data Transmission in Android Apps. In Proceedings on Automated Software [78] Constantinos Kolias, Lucas Copi, Fengwei Zhang, and Angelos Stavrou. 2017.
Engineering (ASE). Breaking BLE Beacons For Fun But Mostly Profit. In Proceedings of the European
[50] Parvez Faruki, Ammar Bharmal, Vijay Laxmi, Manoj Singh Gaur, Mauro Conti, Workshop on Systems Security.
and Muttukrishnan Rajarajan. 2014. Evaluation of android anti-malware tech- [79] Konrad Kollnig, Pierre Dewitte, Max Van Kleek, Ge Wang, Daniel Omeiza,
niques against dalvik bytecode obfuscation. In IEEE Conference on Trust, Security Helena Webb, and Nigel Shadbolt. 2021. A fait accompli? an empirical study
and Privacy in Computing and Communications. into the absence of consent to { Third-Party } tracking in android apps. In
[51] Kassem Fawaz, Kyu-Han Kim, and Kang G. Shin. 2016. Protecting Privacy of Symposium on Usable Privacy and Security (SOUPS).
BLE Device Users. In Proceedings of the USENIX Security Symposium. [80] Konrad Kollnig, Anastasia Shuba, Reuben Binns, Max Van Kleek, and Nigel
[52] Álvaro Feal, Julien Gamba, Juan Tapiador, Primal Wijesekera, Joel Reardon, Shadbolt. 2021. Are iphones really better for privacy? comparative study of ios
Serge Egelman, and Narseo Vallina-Rodriguez. 2021. Don’t accept candy from and android apps. In Proceedings on Privacy Enhancing Technologies (PoPETs).
strangers: An analysis of third-party mobile sdks. In Data Protection and Privacy: [81] Aleksandra Korolova and Vinod Sharma. 2018. Cross-App Tracking via Nearby
Data Protection and Artificial Intelligence. Bluetooth Low Energy Devices. In Proceedings of the ACM Conference on Data
[53] Julien Freudiger. 2015. How talkative is your mobile device? An experimental and Application Security and Privacy.
study of Wi-Fi probe requests. In Proceedings on Security and Privacy in Wireless [82] Haoran Lu, Qingchuan Zhao, Yongliang Chen, Xiaojing Liao, and Zhiqiang Lin.
and Mobile Networks (WiSec). 2023. Detecting and measuring aggressive location harvesting in mobile apps
[54] Guillaume Gagnon, Sébastien Gambs, and Mathieu Cunche. 2024. RSSI based via data-flow path embedding. In Proceedings of the ACM on Measurement and
attacks for identification of BLE devices. Computers & Security. Analysis of Computing Systems.
[55] Julien Gamba, Mohammed Rashed, Abbas Razaghpanah, Juan Tapiador, and [83] Allan Lyons, Julien Gamba, Austin Shawaga, Joel Reardon, Juan Tapiador, Serge
Narseo Vallina-Rodriguez. 2020. An Analysis of Pre-installed Android Software. Egelman, and Narseo Vallina-Rodríguez. 2023. Log: { It’s } Big, { It’s } Heavy, { It’s }
In 2020 IEEE Symposium on Security and Privacy (SP). Filled with Personal Data! Measuring the Logging of Sensitive Information in
[56] Aniketh Girish, Tianrui Hu, Vijay Prakash, Daniel J. Dubois, Srdjan Matic, the Android Ecosystem. In Proceedings of the USENIX Security Symposium.
Danny Yuxing Huang, Serge Egelman, Joel Reardon, Juan Tapiador, David [84] Ziang Ma, Haoyu Wang, Yao Guo, and Xiangqun Chen. 2016. LibRadar: fast and
Choffnes, and Narseo Vallina-Rodriguez. 2023. In the Room Where It Hap- accurate detection of third-party libraries in Android apps. In Proceedings of the
pens: Characterizing Local Communication and Threats in Smart Homes. In International Conference on Software Engineering Companion.
Proceedings of the Internet Measurement Conference (IMC). [85] Samin Yaseer Mahmud, K Virgil English, Seaver Thorn, William Enck, Adam
[57] Marta C González, César A Hidalgo, and Albert-László Barabási. 2008. Under- Oest, and Muhammad Saad. 2022. Analysis of Payment Service Provider SDKs
standing individual human mobility patterns. In Nature. in Android. In Proceedings on Computer Security Applications Conference.
[58] Google. 2024. Geolocation API Overview. https://developers.google.com/maps/ [86] Davide Maiorca, Davide Ariu, Igino Corona, Marco Aresu, and Giorgio Giacinto.
documentation/geolocation/overview. 2015. Stealth attacks: An extended insight into the obfuscation effects on android
[59] Google Developers. 2025. Privacy Sandbox on Android. https://developers. malware. In Computers & Security.
google.com/admob/android/privacy/sandbox [87] Célestin Matte, Jagdish Prasad Achara, and Mathieu Cunche. 2015. Device-to-
[60] Ben Greenstein, Ramakrishna Gummadi, Jeffrey Pang, Mike Y Chen, Tadayoshi identity linking attack using targeted wi-fi geolocation spoofing. In Proceedings
Kohno, Srinivasan Seshan, and David Wetherall. 2007. Can Ferris Bueller Still on Security and Privacy in Wireless and Mobile Networks (WiSec).
Have His Day Off? Protecting Privacy in the Wireless Era. In Proceedings of the [88] Vasilios Mavroudis, Shuang Hao, Yanick Fratantonio, Federico Maggi, Christo-
USENIX Workshop on Hot Topics in Operating Systems (HotOS). pher Kruegel, and Giovanni Vigna. 2017. On the Privacy and Security of the Ul-
[61] Alexander Heinrich, Milan Stute, Tim Kornhuber, and Matthias Hollick. 2021. trasound Ecosystem. In Proceedings on Privacy Enhancing Technologies (PoPETs).
Who can find my devices? security and privacy of apple’s crowd-sourced blue- [89] Yuhong Nan, Zhemin Yang, Xiaofeng Wang, Yuan Zhang, Donglai Zhu, and Min
tooth location tracking system. In Proceedings on Privacy Enhancing Technologies Yang. 2018. Finding clues for your secrets: semantics-driven, learning-based
(PoPETs). privacy discovery in mobile apps. In Proceedings of the Network and Distributed
[62] Urs Hengartner and Hui Zang. 2011. Anonymization of Location Data Does System Security Symposium (NDSS).
Not Work: A Large-Scale Measurement Study. In Proceedings of the Conference [90] Navizon. 2024. Navizon. http://www.navizon.com/.
on Mobile Computing and Networking (MobiCom). [91] Neoma. 2024. IoT and Crowd Management: Insights and Solutions. https:
[63] Hiroki Inayoshi, Shohei Kakei, and Shoichi Saito. 2024. Detection of Inconsisten- //neoma.ai/thinking/blog/13/iot-and-crowd-management.html.
cies between Guidance Pages and Actual Data Collection of Third-party SDKs [92] Radius Networks. 2014. Proximity Kit for Android. https://github.com/
in Android Apps. In Proceedings on Mobile Software Engineering and Systems. RadiusNetworks/proximitykit-android.
[64] Apple Inc. 2024. About Privacy and Location Services in iOS, iPadOS, and [93] The Hacker News. 2014. Spying Agencies Tracking Your Location.
watchOS. https://support.apple.com/en-us/102515. https://thehackernews.com/2014/01/spying-agencies-tracking-your-
[65] Apple Inc. 2024. Exposure Notification Bluetooth Specification. https://developer. location_31.html.
apple.com/documentation/exposurenotification. [94] Trung Tin Nguyen, Michael Backes, Ninja Marnau, and Ben Stock. 2021. Share
[66] Apple Inc. 2024. Getting Started with iBeacon. https://developer.apple.com/ First, Ask Later (or Never?) Studying Violations of { GDPR’s } Explicit Consent
ibeacon/. in Android Apps. In Proceedings of the USENIX Security Symposium.
[67] Google Inc. 2024. Eddystone Protocol Specification. https://github.com/google/ [95] Trung Tin Nguyen, Michael Backes, and Ben Stock. 2022. Freely given consent?
eddystone. studying consent notice of third-party tracking and its violations of gdpr in
[68] Google Inc. 2024. Exposure Notifications API. https://developers.google.com/ android apps. In Conference on Computer and Communications Security (CCS).
android/exposure-notifications/exposure-notifications-api. [96] Damien Octeau, Patrick McDaniel, Somesh Jha, Alexandre Bartel, Eric Bodden,
[69] Incognia. 2024. Incognia Documentation. https://developer.incognia.com/docs/. Jacques Klein, and Yves Le Traon. 2013. Effective { Inter-Component } communi-
[70] iTransition. 2024. Beacons in Retail: How They Work and Benefits for Businesses. cation mapping in android: An essential step towards holistic security analysis.
https://www.itransition.com/retail/beacons. In Proceedings of the USENIX Security Symposium.
[71] Adrianne Jeffries and Bennett Cyphers. 2020. How SDKs, hidden trackers in your [97] Facundo Olano. 2015. Google Play Scraper. https://github.com/facundoolano/
phone, work. Vox (2020). https://www.vox.com/recode/2020/7/8/21311533/sdks- google-play-scraper.
tracking-data-location [98] Moritz Pfister, Robert Michael, Max Boll, Cosima Kö rfer, Konrad Rieck, and
[72] The Wall Street Journal. 2024. House Investigating Company Selling Phone Daniel Arp. 2024. Listening between the Bits: Privacy Leaks in Audio Finger-
Location Data to Government Agencies. https://www.wsj.com/articles/house- prints. In Detection of Intrusions and Malware, and Vulnerability Assessment
investigating-company-selling-phone-location-data-to-government- (DIMVA).

15
Proceedings on Privacy Enhancing Technologies YYYY(X) Girish et al.

[99] Google Play. 2023. Developer Program Policy. https://support.google.com/ [124] Jice Wang, Yue Xiao, Xueqiang Wang, Yuhong Nan, Luyi Xing, Xiaojing Liao,
googleplay/android-developer/answer/9857753 JinWei Dong, Nicolas Serrano, Haoran Lu, XiaoFeng Wang, et al. 2021. Under-
[100] Google Play. 2024. User Data Policy for Android Developers. standing malicious cross-library data harvesting on android. In Proceedings of
https://support.google.com/googleplay/android-developer/answer/10144311? the USENIX Security Symposium.
sjid=18338717510598425318-EU. [125] Fengguo Wei, Sankardas Roy, Xinming Ou, and Robby. 2018. Amandroid: A
[101] Sebastian Poeplau, Yanick Fratantonio, Antonio Bianchi, Christopher Kruegel, precise and general inter-component data flow analysis framework for security
and Giovanni Vigna. 2014. Execute this! analyzing unsafe and malicious dy- vetting of android apps. In ACM Transactions on Privacy and Security (TOPS).
namic code loading in android applications.. In Proceedings of the Network and [126] Mira Weller, Jiska Classen, Fabian Ullrich, Denis Waßmann, and Erik Tews. 2020.
Distributed System Security Symposium (NDSS). Lost and found: stopping bluetooth finders from leaking private information. In
[102] Sajjad Pourali, Nayanamana Samarasinghe, and Mohammad Mannan. 2022. Hid- Proceedings on Security and Privacy in Wireless and Mobile Networks (WiSec).
den in plain sight: exploring encrypted channels in android apps. In Conference [127] WiGLE. 2024. WiGLE All the Networks. Found by Everyone. https://wigle.net.
on Computer and Communications Security (CCS). [128] WIRED. 2024. Anyone Can Buy Data Tracking US Soldiers and Spies to Nuclear
[103] Joseph Priest and Daryl Johnson. 2015. Covert Channel over Apple iBeacon. In Vaults and Brothels in Germany. https://www.wired.com/story/phone-data-us-
Proceedings on Security and Management (SAM). soldiers-spies-nuclear-germany/.
[104] Exodus Privacy. 2024. Homepage. https://exodus-privacy.eu.org/en/. [129] Wired. 2024. Jeffrey Epstein Island Visitors Data Broker Leak. https://www.
[105] Abbas Razaghpanah, Rishab Nithyanand, Narseo Vallina-Rodriguez, Srikanth wired.com/story/jeffrey-epstein-island-visitors-data-broker-leak/.
Sundaresan, Mark Allman, Christian Kreibich, Phillipa Gill, et al. 2018. Apps, [130] Arol Wright. 2021. Android 12 no longer needs your location to scan nearby
trackers, privacy, and regulators: A global study of the mobile tracking ecosys- Bluetooth devices. https://www.xda-developers.com/android-12-location-scan-
tem. In Proceedings of the Network and Distributed System Security Symposium nearby-bluetooth-devices/.
(NDSS). [131] Senator Ron Wyden. 2024. Wyden Reveals Phone Data Used to Target Abortion
[106] Joel Reardon, Álvaro Feal, Primal Wijesekera, Amit Elazari Bar On, Narseo Misinformation at Visitors to Hundreds of Reproductive Health Clinics.
Vallina-Rodriguez, and Serge Egelman. 2019. 50 ways to leak your data: An https://www.wyden.senate.gov/news/press-releases/wyden-reveals-phone-
exploration of apps’ circumvention of the android permissions system. In Pro- data-used-to-target-abortion-misinformation-at-visitors-to-hundreds-of-
ceedings of the USENIX Security Symposium. reproductive-health-clinics.
[107] Joel Reardon, Nathan Good, Robert Richter, Narseo Vallina-Rodriguez, Serge [132] Yue Xiao, Chaoqi Zhang, Yue Qin, Fares Fahad S Alharbi, Luyi Xing, and Xiaojing
Egel-man, and Quentin Palfrey. 2020. Jpush away your privacy: A case study of Liao. 2024. Measuring Compliance Implications of Third-party Libraries Privacy
Jiguang’s Android SDK. (2020). Label Disclosure Guidelines. In Conference on Computer and Communications
[108] Irwin Reyes, Primal Wijesekera, Joel Reardon, Amit Elazari Bar On, Abbas Security (CCS).
Razaghpanah, Narseo Vallina-Rodriguez, Serge Egelman, et al. 2018. “Won’t [133] Tingfeng Yu, James Henderson, Alwen Tiu, and Thomas Haines. 2024. Secu-
somebody think of the children?” examining COPPA compliance at scale. In rity and Privacy Analysis of Samsung’s { Crowd-Sourced } Bluetooth Location
Proceedings on Privacy Enhancing Technologies (PoPETs). Tracking System. In Proceedings of the USENIX Security Symposium.
[109] Ian Rose and Matt Welsh. 2010. Mapping the urban wireless landscape with [134] Jiexin Zhang, Alastair R. Beresford, and Stephan A. Kollmann. 2019. LibID: reli-
Argos. In Proceedings of the ACM conference on embedded networked sensor able identification of obfuscated third-party Android libraries. In Proceedings of
systems. the SIGSOFT International Symposium on Software Testing and Analysis (ISSTA).
[110] Erik Rye and Dave Levin. 2024. Surveilling the Masses with Wi-Fi-Based Posi- [135] Fanghua Zhao, Linan Gao, Yang Zhang, Zeyu Wang, Bo Wang, and Shanqing
tioning Systems. In IEEE Symposium on Security and Privacy (SP). Guo. 2018. You are where you app: An assessment on location privacy of social
[111] Piotr Sapiezynski, Radu Gatej, Alan Mislove, and Sune Lehmann. 2015. Op- applications. In 2018 IEEE 29th International Symposium on Software Reliability
portunities and challenges in crowdsourced wardriving. In Proceedings of the Engineering (ISSRE).
Internet Measurement Conference (IMC). [136] Kaifa Zhao, Xian Zhan, Le Yu, Shiyao Zhou, Hao Zhou, Xiapu Luo, Haoyu Wang,
[112] Narmeen Shafqat, Nicole Gerzon, Maggie Van Nortwick, Victor Sun, Alan Mis- and Yepang Liu. 2023. Demystifying Privacy Policy of Third-Party Libraries
love, and Aanjhan Ranganathan. 2023. Track You: A Deep Dive into Safety Alerts in Mobile Apps. In 2023 IEEE/ACM 45th International Conference on Software
for Apple AirTags. In Proceedings on Privacy Enhancing Technologies (PoPETs). Engineering (ICSE).
[113] Singlespot. 2024. Singlespot - Pricing, Reviews, Data & APIs. https://datarade. [137] Qingchuan Zhao, Chaoshun Zuo, Giancarlo Pellegrino, and Li Zhiqiang. 2019.
ai/data-providers/singlespot/profile. Geo-locating Drivers: A Study of Sensitive Data Leakage in Ride-Hailing Ser-
[114] Skyhook. 2024. Skyhook Wi-Fi Location. https://www.skyhook.com/wifi- vices. Proceedings of the Network and Distributed System Security Symposium
location-solutions. (NDSS).
[115] Sooel Son, Daehyeok Kim, and Vitaly Shmatikov. 2016. What Mobile Ads [138] Shuang Zhao, Xiapu Luo, Bo Bai, Xiaobo Ma, Wei Zou, Xinliang Qiu, and Man Ho
Know About Mobile Users.. In Proceedings of the Network and Distributed System Au. 2016. I know where you all are! exploiting mobile social apps for large-scale
Security Symposium (NDSS). location privacy probing. In Information Security and Privacy: 21st Australasian
[116] Statista. 2024. Mobile Android Version Market Share Worldwide 2018- Conference, ACISP 2016, Melbourne, VIC, Australia, July 4-6, 2016, Proceedings,
2024. https://www.statista.com/statistics/921152/mobile-android-version- Part I 21.
share-worldwide/.
[117] Ryan Stevens, Clint Gibler, Jon Crussell, Jeremy Erickson, and Hao Chen. 2012.
Investigating user privacy in android ad libraries. In Workshop on Mobile Security Appendix
Technologies (MoST).
[118] Swrve. 2024. Swrve Geo SDK Integration Guide. https://docs.swrve.com/
developer-documentation/integration/swrve-geo-sdk/.
[119] Byron Tau. 2023. FBI Once Bought Mobile-Phone Data for Warrantless Tracking.
Other Agencies Still Do. https://www.wsj.com/articles/fbi-once-bought-mobile-
phone-data-for-warrantless-tracking-other-agencies-still-do-ad65ebe9.
[120] Marcos Tileria and Jorge Blasco. 2022. Watch over your tv: a security and
privacy analysis of the android tv ecosystem. In Proceedings on Privacy Enhancing
Technologies.
[121] Narseo Vallina-Rodriguez, Jon Crowcroft, Alessandro Finamore, Yan Grunen-
berger, and Konstantina Papagiannaki. 2013. When assistance becomes depen-
dence: characterizing the costs and inefficiencies of A-GPS. In ACM SIGMOBILE
Mobile Computing and Communications Review.
[122] Mathy Vanhoef, Célestin Matte, Mathieu Cunche, Leonardo S Cardoso, and
Frank Piessens. 2016. Why MAC address randomization is not enough: An
analysis of Wi-Fi network discovery mechanisms. In Proceedings of the Asia
conference on computer and communications security (ASIA CCS).
[123] Haoyu Wang, Zhe Liu, Jingyue Liang, Narseo Vallina-Rodriguez, Yao Guo, Li
Li, Juan Tapiador, Jingcun Cao, and Guoai Xu. 2018. Beyond Google Play: A
Large-Scale Comparative Study of Chinese Android App Markets. In Proceedings
of the Internet Measurement Conference (IMC).

16
Your Signal, Their Data Proceedings on Privacy Enhancing Technologies YYYY(X)

Table 6: All 52 SDKs in our dataset and their purposes.

SDK Name # Apps Purpose Type

Advertising
Analytics

Profiling
Location
AltBeacon 4,022 ✓ ✓
Adobe Experience Platform 1,328 ✓
Kochava 1,117 ✓ ✓ ✓
Salesforce Marketing Cloud 1,080 ✓ ✓ ✓
Estimote 510 ✓ ✓
LeanPlum 456 ✓ ✓ ✓
Gimbal 396 ✓ ✓ ✓
Radius Networks 369 ✓ ✓
mParticle 367 ✓
Ad4Screen 198 ✓
Kontakt 194 ✓
CueAudio 190 ✓ ✓
Swrve 153 ✓ ✓ ✓
Reveal Mobile 109 ✓ ✓
Exponea 99 ✓
Radar 93 ✓ ✓
IndoorAtlas 92 ✓ ✓
SignalFrame 89 ✓
Bazaarvoice 88 ✓ ✓
Huq Sourcekit 81 ✓ ✓
Yinzcam Sobek 80 ✓ ✓ ✓
BlueKai (acquired by Oracle) 73 ✓
Cuebiq 73 ✓ ✓
Rover SDK 50 ✓ ✓ ✓
Coulus Coelib 47 ✓
Colocator 40 ✓ ✓
X-Mode 38 ✓ ✓
Zendrive 34 ✓ ✓ ✓
Dynamic Yield 27 ✓
Pilgrim by Foursquare 25 ✓
Sense360 24 ✓ ✓
Locuslabs 23 ✓ ✓
InMarket 23 ✓ ✓
Singlespot 18 ✓
Roximity 17 ✓
Zapr 17 ✓ ✓ ✓
Swirl 16 ✓ ✓
Bluecats 14 ✓
Areametrics 8 ✓
OpenLocate 8 ✓
Point Inside 7 ✓ ✓
PredicIO 6 ✓ ✓ ✓
MOCA 5 ✓ ✓ ✓
BeaconsInSpace (Fysical) 5 ✓
Unacast Pure 5 ✓
Woosmap SDK 5 ✓ ✓
Sensoro 4 ✓ ✓
Signal360 4 ✓
Placer 4 ✓ ✓ ✓
Proximi.io 3 ✓ ✓
Tamoco 3 ✓ ✓
pulseid 1 ✓ ✓

Figure 6: Upset plot of all the identifiers collected by the

SDKs.
17
Proceedings on Privacy Enhancing Technologies YYYY(X) Girish et al.

Table 7: Description of PII types considered in this study. Abbreviations used: Pers - Persistent; Reset - Resettable.

Identifier Pers Reset Definitions

IMEI x Unique hardware ID for the mobile device. Available only on Android 9 or below
WiFi MAC x Unique hardware ID for the WiFi interface.
HWID x Unique hardware ID assigned by the manufacturer.
GSF ID x Unique ID tied to the Google account on the device.
Boot ID x Unique identifier representing the device’s boot session; resets only after a factory reset.
Email x User’s email address.
Device Fingerprint Non-unique Collection of attributes (e.g., OS version, browser) identifying the device..
Android ID x App-specific ID that resets with a factory reset.
AAID x Advertising ID provided by Google for specialized for advertising. Can be reset through device settings.
Firebase ID x App-specific ID tied to a specific app instance. It resets when the app is uninstalled or its data is cleared.
Bluetooth Device Name x User-defined, resettable, and non-unique name for Bluetooth discovery.
Bluetooth iBeacon MAC x Unique hardware address for BLE proximity detection.
iBeacon UUID x Unique ID for iBeacon devices in proximity-based services.
Router MAC x Unique mac address for the connected WiFi router.
Router Scan MAC x Persistent hardware address for nearby routers detected in WiFi scans,
Router Scan SSID x Names of nearby routers detected in WiFi scans,
Router SSID x Name of the currently connected router.
Coarse Geolocation x Co-ordinates of approximate device location derived from network data.
Fine Geolocation x Co-ordinates of precise GPS-based location of the device.

Table 8: Example of Beacon SDK code and network signatures.

SDK Name Package Names Domains / Endpoints

AltBeacon org.altbeacon.beacon., com.altbeacon.beacon., org.altbeacon.bluetooth. data.altbeacon.org
Radius Networks com.radiusnetworks. proximitykit.radiusnetworks.com
Estimote com.estimote. *.estimote.com
Gimbal com.gimbal.android. analytics*.gimbal.com, api.gimbal.com, sdk-info.gimbal.com
Kontakt com.kontakt.sdk.android. kontakt.io
Reveal Mobile com.stepleaderdigital.reveal. *.revealmobile.com rvl.wral.com
SignalFrame com.wirelessregistry.observersdk. *.wirelessregistry.com
IndoorAtlas com.indooratlas.android.sdk. ipsws.indooratlas.com
Rover SDK io.rover. *.rover.io

Table 9: Beacon SDK search keywords and attribution signals.

Technology Search Keywords Attribution Signals

Presence of BLE scanning APIs,
"beacon SDK", "proximity SDK",
class names associated with BLE scanning,
"BLE SDK", "Bluetooth tracking SDK",
BLE declared BLE-related permissions in AndroidManifest.xml,
"BLE advertising SDK", "Bluetooth beacon SDK",
references to hardcoded UUIDs for beacon identification,
"RSSI scanning SDK"
extraction of RSSI values for signal strength analysis
Presence of WiFi scanning APIs,
"WiFi beacon SDK", "proximity SDK",
class names related to WiFi scanning,
WiFi "WiFi tracking SDK", "WiFi positioning SDK",
declared WiFi-related permissions in AndroidManifest.xml,
"WiFi scanning SDK"
analysis of hardcoded SSIDs, references to known WiFi telemetry endpoints
Presence of location-related APIs,
"geofencing SDK", "proximity SDK",
class names associated with location services,
Location "location tracking SDK", "indoor positioning SDK",
declared location-related permissions in AndroidManifest.xml,
"RTLS SDK", "asset tracking SDK"
embedded geofencing configuration files, hardcoded location-based UUIDs

18
Your Signal, Their Data Proceedings on Privacy Enhancing Technologies YYYY(X)

Table 10: Android framework APIs (Java) that enable wireless beacon scanning.

Technology Permissions APIs

android.bluetooth.BluetoothAdapter/startLeScan
BLUETOOTH_SCAN android.bluetooth.BluetoothLeScanner/startScan
BLE BLUETOOTH_CONNECT android.bluetooth.BluetoothDevice/connectGatt
ACCESS_FINE_LOCATION android.bluetooth.BluetoothGatt/discoverServices
android.bluetooth.BluetoothLeAdvertiser/startAdvertising
android.net.wifi.WifiManager/getScanResults
CHANGE_WIFI_STATE
android.net.wifi.WifiManager/startScan
ACCESS_WIFI_STATE
WiFi android.net.wifi.WifiManager/getConnectionInfo
ACCESS_FINE_LOCATION
android.net.wifi.WifiManager/setWifiEnabled
ACCESS_COARSE_LOCATION
android.net.wifi.WifiManager/reconnect
android.location.LocationManager/getLastKnownLocation
ACCESS_FINE_LOCATION android.location.LocationManager/requestLocationUpdates
Location ACCESS_COARSE_LOCATION android.telephony.TelephonyManager/getAllCellInfo
FOREGROUND_SERVICE android.telephony.TelephonyManager/getCellLocation
android.location.LocationManager/addProximityAlert

Table 11: Market share of the top-15 SDKs per top-10 app category.

SDK Name # Apps Lifestyle Shopping Sports Business Travel & Local Finance News & Magazines Education Entertainment Weather
AltBeacon 4024 18% (721) 6% (240) 3% (137) 12% (498) 8% (338) 3% (133) 1% (59) 8% (302) 3% (114) 1% (32)
Adobe Experience Platform 1328 3% (45) 7% (89) 9% (120) 4% (47) 5% (65) 13% (179) 16% (212) 1% (13) 7% (97) 18% (245)
Kochava 1118 3% (34) 3% (36) 7% (73) 2% (20) 2% (18) 5% (60) 2% (25) 4% (42) 7% (75) 0% (2)
Salesforce Marketing Cloud 1080 9% (98) 23% (244) 3% (33) 10% (103) 8% (83) 18% (197) 2% (24) 1% (12) 2% (24) 0% (0)
Estimote 510 34% (174) 3% (14) 1% (6) 12% (60) 13% (65) 1% (6) 0% (2) 13% (64) 3% (14) 0% (0)
LeanPlum 456 3% (15) 7% (33) 1% (6) 2% (10) 14% (63) 5% (21) 1% (3) 14% (66) 2% (8) 0% (2)
Gimbal 396 10% (40) 6% (23) 42% (167) 1% (5) 1% (5) 20% (80) 3% (10) 5% (21) 6% (24) 0% (0)
Radius Networks 369 44% (162) 6% (23) 2% (9) 6% (21) 4% (13) 1% (3) 1% (3) 3% (12) 2% (7) 0% (1)
mParticle 367 3% (11) 6% (21) 6% (21) 3% (11) 16% (59) 8% (30) 14% (53) 1% (4) 9% (32) 0% (0)
Ad4Screen 198 5% (10) 19% (38) 3% (5) 2% (3) 7% (14) 12% (23) 29% (58) 1% (2) 2% (3) 0% (0)
Kontakt 195 9% (17) 15% (30) 7% (13) 21% (40) 7% (13) 2% (4) 2% (3) 4% (7) 5% (9) 1% (1)
CueAudio 190 0% (0) 0% (0) 98% (187) 0% (0) 0% (0) 0% (0) 0% (0) 0% (0) 1% (2) 0% (0)
Swrve 153 2% (3) 8% (13) 3% (4) 0% (0) 7% (11) 5% (8) 1% (2) 2% (3) 5% (7) 1% (1)
Reveal Mobile 109 0% (0) 0% (0) 0% (0) 0% (0) 0% (0) 0% (0) 13% (14) 0% (0) 1% (1) 86% (94)
Exponea 99 4% (4) 38% (38) 0% (0) 2% (2) 10% (10) 15% (15) 0% (0) 3% (3) 4% (4) 0% (0)
Total apps per category 12% (1385) 9% (999) 8% (935) 8% (903) 7% (847) 7% (795) 5% (600) 5% (562) 4% (473) 4% (420)

19
Proceedings on Privacy Enhancing Technologies YYYY(X) Girish et al.

Table 12: Data collected by Vizbee. POST / track / json HTTP /1.1^ M
User - Agent : Dalvik /2.1.0 ( Linux ; U ; Android 12;

Coarse Geolocation
AOSP on sargo Build / SP2A .220505.008) ^ M
Content - Type : application / json ; charset = UTF -8^ M
Host : control . kochava . com ^ M

Router MAC
Router SSID
Android ID
Content - Length : 1729^ M

Installs
^M

AAID
Package Name " action ":" install " ," kochava_app_id ":" kobiubiuclub
com.gotv.nflgamecenter.us.lite 120.1M x x x x x -3 b00 " ," kochava_device_id ":"
com.cnn.mobile.android.phone 50M x x x x KA31101723813375tdacae51f18644fed9ef9b8467b07d2be
com.handmark.sportcaster 18.6M x x x x " ," sdk_protocol ":"14" ," sdk_version ":"
com.turner.tnt.android.networkapp 7.6M x x x x AndroidTracker 3.11.0" ," nt_id ":" bc770 -1 -
com.nfl.fantasy.core.android 7.4M x x x x x acccf2f1 -33 da -4 dbc -80 bf -6 a5981859f3f " ," data
com.neulion.android.tablet.nfl.wnfln 3.9M x x x x x ":{" screen_brightness ":0.2902 ,"
com.turner.trutv 1.7M x x x x
device_orientation ":" portrait " ," volume ":0.32 , "
com.fox.weather 959.7K x x x x x
aaid ": " X7dD24S2 - CcD4 -4 Cfv - hhgg - bbbb7yk245f6 "
com.gannett.local.library.news.kare 198.8K x x x x x
com.raycom.wtol 194.1K x x x x x ," device ":" AOSP on sargo - Android " ," disp_h
com.gannett.local.library.news.wxia 151.0K x x x x x ":2220 ," disp_w ":1080 ," package ":" com . biubiuclub
com.gannett.local.library.news.kxtv 54.7K x x x x x . biubiuclubchat " ," installed_date ":1723813319 ,"
app_name ":" BiubiuClub " ," app_version ":"291" ,"
Table 13: SDKs that present rationale behind dangerous app_short_string ":"2.9.1" ," os_version ":"
permission requested using shouldShowRequestPermission- Android
Rationale().
" network_conn_type ": " wifi " ," ssid ": , " routerssid :
ABC - WIFI " , " bbsid ": " routermac : XX : XX : XX : XX :
SDK % Ctx C. Loc F. Loc B. Loc
XX : XX " , " network_metered ": false ," nvp ":0 ,"
Estimote 75% ✓ carrier_name ":"" ," usertime ":1723813375 ," uptime
InMarket 52% ✓ ":0.945 ," state_active ": true ,"
Radar 42% ✓ ✓
app_limit_tracking ": false ," platform ":" android
Singlespot 55% ✓
Salesforce Marketing Cloud 54% ✓ "} ," sdk_id ":" c946 - s88450 -" ," send_date
Abbreviations Used: SDK - Software Development Kit, % Ctx - % of apps that Show ":"2024 -08 -16 T13 :02:56.954 Z "
Context, C. Loc - Access Coarse Location, F. Loc - Access Fine Location, B. Loc - Access
Background Location.
Figure 7: The Kochava SDK in com.biubiuclub.biubiuclubchat
collects AAID and router MAC address and transmits them
to control.kochava.com

20
Your Signal, Their Data Proceedings on Privacy Enhancing Technologies YYYY(X)

POST / events / v3 HTTP /1.1

x - dynatrace : MT_3_4_2021016446_1 -0 _36d6e79e -
" records ": [
{
" app_session_id ": "474 c6944 -823 d -4 da3 - b154
-001 b272a6f59 " ,
" event_type ": " bulk_localization_event " ,
" localizations ": [
{
" ad_tracking_enabled ": " true " ,
" Ad_id ": " ccccccc - cccc - cccc - cccc -
ba1bccccc0a " ,
" app_package_name ": " br . com . bancobmg .
bancodigital . atletico " ,
" app_state ": " FOREGROUND " ,
" fingerprint ": {
" elapsed_ts ": "1589677460" ,
" environment_scan ": {
" environment_state ": " outdoor " ,
" timestamp ": "1723858094723"
},

" gps_fix ": {

" altitude ": "721.5999755859375" ,
" bearing ": "227.02573" ,
" bearing_acc ": "45" ,
" gps_acc ": "12.75" ,
" lat ": "30.3368394" ,
" lng ": " -2.7705837" ,
" provider ": " fused " ,
" speed ": "2.1049643" ,
" speed_acc ": "1.5" ,
" vertical_acc ": "1.5948421"
},
" gps_ts ": "1723858073227" ,
" mock_location ": " false " ,
" precise_location ": " true "
},
" wifi_scan ": {
" ap_measures ": [
{
" ap_ts ": "1723858075286" ,
" auth ": " false " ,
" bssid ": " XX : XX : XX : XX : XX : XX " ,
" channel_width ": "20 _mhz " ,
" con ": " false " ,
" frequency ": "2462" ,
" level ": " -60" ,
" ssid ": " ABC - WIFII " ,
" venue_name ": "" ,
" wifi_rtt_responder ": " false "
},

Figure 8: The Incognia SDK in br.com.bancobmg.bancodigital.

atletico collects AAID, GPS coordinates, and WiFi scan data
and transmits them to service2.us.incognia.com.
21