Firebase sits inside 1,048 of the 2,247 Android apps we have pulled apart at the bytecode level. Forty-seven percent, and nothing else in our corpus comes close to it. That single number means Google doesn’t need to see your phone’s home screen to know what you did last Tuesday. It already knows, because the code that reports “user opened checkout screen at 9:47pm” is compiled directly into the weather app, the grocery app, and the game your kid plays. Same company, same pipe, three different icons.
That’s the part people miss when they ask what a tracker actually is. A tracker is not a rogue app spying on you from the background. It’s not malware in the classic sense. It’s a software library, an SDK (software development kit), that a developer pasted into their project because it does something useful: measure crashes, count installs, show an ad, or figure out which marketing campaign brought a user in. The tracking is a side effect of a service the developer actually wanted.
it runs inside the app, not next to it
This distinction matters more than it sounds. A tracker doesn’t get its own permission prompt. It doesn’t show up as a separate process in your battery settings. It runs in the same memory space as the app you opened, inherits whatever permissions that app already has, and fires its own network requests using the app’s own network stack. From the OS’s point of view, there’s no difference between “the app checked the weather” and “the app’s embedded analytics SDK phoned home to a server in Virginia.” Both look like the app doing app things.
That’s why permission audits only get you halfway. You can deny location access to a flashlight app and still have three SDKs inside it reporting your device model, carrier, screen resolution, battery level, and installed app list, none of which require a permission dialog at all.
the five species, and what each one actually wants
Not all trackers want the same thing. Lumping them together is how people end up either panicking over nothing or ignoring the ones that matter.
Analytics SDKs (Firebase, Amplitude, Mixpanel) want behavioral events: screens viewed, buttons tapped, time spent. Mostly used to improve the product, but the raw event stream usually leaves the developer’s control the moment it’s collected.
Attribution SDKs (AppsFlyer, Adjust, Kochava, Branch) exist purely to answer “which ad made this person install the app.” To do that they need your device’s advertising ID before you’ve done anything else in the app, sometimes before you’ve even opened it for the first time. This category is invisible to most users because it has nothing to do with ads showing up on your screen. It’s plumbing.
Ad exchange SDKs (Meta Audience Network, AppLovin, Unity Ads, ironSource) are the ones actually running the auction that decides which ad you see. They collect the most granular signal because the auction pays better with better targeting data.
Session replay SDKs (FullStory, UXCam, Glassbox) record literal interaction traces, sometimes including form inputs, so a product team can watch a video reconstruction of what you did on screen. These have caused real scandals when they captured things they shouldn’t have, like partial credit card numbers.
Crash and performance monitors (Crashlytics, Sentry, Bugsnag) are the least alarming of the five, though “least alarming” still means device identifiers, stack traces, and sometimes user IDs get uploaded every time something breaks.
Half the apps in our corpus carry at least one, a quarter carry four or more, and the busiest one percent carry seventeen or more, stacked, each reporting to a different company, each with its own retention policy that the app developer usually hasn’t read closely either.
the key that makes it all connect
The reason a tracker can build a profile of you across apps you never associated with each other is a single identifier: the Google Advertising ID (GAID), sitting quietly in your device settings. Every SDK from every one of those five categories, if the developer wired it up, can request that same ID. So the attribution SDK in your food delivery app and the ad SDK in a mobile game can both report to Kochava using the identical GAID, and Kochava’s backend doesn’t need you to log into anything to know it’s the same phone doing both things. That’s not speculation, it’s the entire business model of the mobile measurement partner (MMP) industry, and it’s legal, disclosed somewhere in a privacy policy you didn’t open.
Resetting your GAID in Android settings breaks this linkage temporarily, but every SDK that’s already fired once has already made the association, and most reset it right back to a fresh profile within days because behavioral fingerprinting (screen size, timezone, battery curve, install order) reconnects the dots without needing the old ID at all.
what this actually changes about how you should think about it
The useful shift here isn’t “delete suspicious apps.” It’s recognizing that the tracker question was never about individual bad actors. It’s about a small number of SDK vendors, maybe two dozen that matter, sitting inside a majority of the apps on your phone, each one able to see a slice of your day that no single app would ever admit to collecting on its own. Scanning tools like the ones we build at AppXpose can tell you which SDKs are present in a given APK, but they can’t tell you what those SDKs do with the data once it leaves your device, because that part happens in server rooms you’ll never audit. The honest takeaway is that “checking permissions” was never enough, and it still isn’t.