Mobile Advertising IDs Explained: IDFA, GAID, ATT and How to Reset Them

A mobile advertising ID is a random identifier your phone's operating system hands to apps for advertising: Apple calls it the IDFA, Google calls it the advertising ID (often shortened to GAID or AAID). Since iOS 14.5, apps must ask before reading the IDFA. On Android you can reset or delete the ID in Settings, and a deleted ID reads as all zeros.

The ID itself is only a string. It matters because many software development kits (SDKs) inside many apps can read the same string and send it to servers you never see, where it becomes the join key between your app use, your location history and data bought elsewhere. This post goes one level deeper than our explainer on browser fingerprinting, which covers the web side of the same problem. It covers where advertising IDs came from, what Apple's App Tracking Transparency (ATT) does according to Apple's own documentation, how Android handles reset, delete and the AD_ID permission, what US regulators alleged about location data brokers, what replaces cross-app tracking, what the law says, and how to check everything step by step as a phone owner and as an app developer.

Key takeaways

• Apple's IDFA arrived with iOS 6 (the AdSupport framework), which Apple shipped on 19 September 2012. Google announced its advertising ID on 31 October 2013 with Google Play services 4.0, as a replacement for Android ID in advertising.
• Since iOS 14.5 (released 26 April 2021), an app needs permission through the ATT prompt to read the IDFA. Without it the IDFA reads as all zeros, and Apple's rules forbid tracking you by other identifiers such as a hashed email.
• On Android you can reset the ID or delete it. Since 1 April 2022 on all devices with Google Play, a deleted ID reads as zeros. Apps targeting Android 13 or later must declare the AD_ID permission to read it at all, and SDKs often add that permission for you.
• Google said on 17 October 2025 it is retiring most Privacy Sandbox technologies, including Topics, Protected Audience, Attribution Reporting and the SDK Runtime on Android. The advertising ID remains the Android control that matters.
• Apple's replacements for cross-app measurement, SKAdNetwork and AdAttributionKit, send signed postbacks that Apple says carry no user or device specific data.
• The EDPB says Article 5(3) of the ePrivacy Directive applies when an app makes a device send a unique identifier. California's CCPA names "mobile ad identifiers" in its definition of a unique identifier.
• FTC orders against location data brokers in 2024 describe location data tied to advertising IDs, gathered through SDKs in third party apps and through ad auctions.

What a mobile advertising ID is

An advertising ID is a device level identifier that the operating system generates, stores and hands out through an API. Apple's documentation for the advertisingIdentifier property describes it as "an alphanumeric string that's unique to each device, and which you only use for advertising". Google's Play Console help describes its version as "a unique, user-resettable, and user-deletable ID for advertising, provided by Google Play services".

Three properties separate an advertising ID from the identifiers that came before it:

1. It is meant only for advertising. Apple lists frequency capping, attribution, conversion events, counting unique users, ad fraud detection and debugging. Google's Play policy requires apps to use the advertising ID, where the device has one, instead of any other device identifier whenever the purpose is advertising.
2. The user can change it. On Android you can reset or delete it. On iOS the control is a permission: say no, and the app sees zeros.
3. It is the same across apps on one device. Every app allowed to read the IDFA or the Android advertising ID gets the same value. That shared value is what lets an ad network know that the device which installed a game is the one that saw the ad in a news app.

The format on both platforms is a UUID, 36 characters with hyphens, such as 6D92078A-8246-4BA4-AE5B-76104861E7DC. Apple's documentation calls the IDFA a UUID. The Android documentation for the AndroidX Advertising ID library says the ID uses version 3 of the UUID format or an equivalent 128 bit format, and notes that on devices with several users, including guest users, each user can get a different advertising ID. A UUID says nothing about you until a server stores it next to your purchases, your email address or a list of GPS coordinates.

What it replaced: UDID, IMEI, MAC addresses and Android ID

Before advertising IDs, apps and ad SDKs used whatever stable number the device exposed. On iPhone that was the UDID, the unique device identifier tied to the hardware. On Android, ad SDKs read the IMEI (the cellular modem's identity), the device serial number, the Wi-Fi MAC address or Settings.Secure.ANDROID_ID. None of these could be reset by an ordinary user, so a profile built on them followed the device until it was thrown away, and sometimes followed it to the next owner.

Both platforms closed those doors over several releases:

• iOS 6 introduced two separate identifiers for apps to use instead of hardware identifiers: the advertising identifier in the AdSupport framework, and identifierForVendor (IDFV) in UIKit. Apple's documentation lists both as available from iOS 6.0. IDFV is "the same for apps that come from the same vendor running on the same device" and different across vendors, so it supports analytics across one company's apps without creating a cross company key.
• Google Play services 4.0 (announced 31 October 2013) added "a new, anonymous identifier for advertising purposes (to be used in place of Android ID)", with user controls to reset it or opt out of interest based ads.
• Android 10 restricted access to non-resettable identifiers. Apps now need the READ_PRIVILEGED_PHONE_STATE permission, which is reserved for privileged system apps, to read "the device's non-resettable identifiers, which include both IMEI and serial number". Android 10 also turned on randomised MAC addresses by default.
• Android 12 onward zeroed the advertising ID after a user deletes it (covered below). Google also offers the App Set ID for analytics and fraud prevention that do not need a cross developer identifier.

The direction is consistent: identifiers that cannot be changed were pushed out of reach, and an identifier the user controls was put in their place. That only helps if users know the control exists.

How the ID moves: from SDK to ad network to data broker

You never type your advertising ID anywhere. It leaves your phone inside network requests made by code you did not choose. The usual path looks like this:

1. An app embeds SDKs. A typical free app includes an ad SDK, an attribution SDK that tells marketing which campaign produced each install, an analytics SDK and often a crash reporter, each compiled into the app.
2. An SDK reads the ID. If the operating system allows it, the SDK calls the system API and gets the advertising ID. On Android before the AD_ID permission was required, any SDK in the process could do this silently.
3. The ID travels with events. The SDK sends app open events, purchase events or ad impression records to its own servers with the ID attached. Location aware SDKs can attach GPS coordinates and timestamps.
4. Ad auctions spread it further. When an app requests an ad, many ad systems run a real-time auction. The bid request can include device details and, when available, the advertising ID and location. Every bidder that receives the request sees that data, whether or not it wins.
5. Brokers aggregate. Data brokers buy or license these event streams from SDK owners and auction participants, join them on the advertising ID, and sell audience segments, location panels or "foot traffic" datasets.

Apple's developer guidance names exactly these flows as tracking. Its examples include sharing device location data or email lists with a data broker, and sharing lists of emails or advertising IDs with a third party ad network that retargets those users in other developers' apps. Apple adds that embedding a third party SDK which combines your users' data with other developers' data counts as tracking even when you do not use the SDK for that purpose yourself.

What US regulators alleged in location data cases

The US Federal Trade Commission has brought several cases that show this pipeline in public records. These are the FTC's allegations and orders as described in its own press releases and orders; each case was resolved by a consent order rather than a trial.

The lesson for app teams is not about those companies. It is that an advertising ID next to a timestamped coordinate is not anonymous. The final Mobilewalla order defines location data broadly enough to include data combined with a mobile advertising identifier or IDFA, and states that location data linked to a mobile advertising identifier or a home address "is not Deidentified". A string of hex digits plus the place where a phone sits every night points to a household.

How App Tracking Transparency changed iOS

Apple shipped the AppTrackingTransparency framework in the iOS 14 SDK (Apple's documentation lists it as available from iOS 14.0) and began enforcing it with iOS 14.5, which Apple announced as available on 26 April 2021. Apple's newsroom release for that update said apps "are now required to get a user's permission to track or access their device's advertising identifier".

What Apple counts as tracking

Apple's definition, from its user privacy and data use page for developers, is the heart of ATT. Tracking means linking user or device data collected in your app with user or device data that other companies collected in their apps, on their websites or offline, when the purpose is targeted advertising or advertising measurement. Sharing user or device data with data brokers is tracking too. Apple then lists what is not tracking: linking data only on the device without sending it off in an identifying way, sharing with a data broker solely for fraud detection or security, and sharing with a consumer reporting agency for credit purposes.

Three details in Apple's FAQ matter more than the prompt itself:

• It is not only about the IDFA. Apple's FAQ says that without ATT permission an app may not track the user with some other identifier, and gives a hashed email address or hashed phone number as examples. The identifiers the policy governs include the advertising identifier, session IDs, fingerprint IDs and device graph identifiers.
• Fingerprinting is banned outright. Asked whether an app can fingerprint the device or use device signals to identify a user, Apple answers no, citing the Apple Developer Program License Agreement, and warns that apps referencing SDKs that do so may be rejected from the App Store.
• The developer owns its SDKs' behaviour. "Developers are responsible for all code included in their apps," Apple says, and that includes single sign-on libraries and web views used for app functionality.

What happens when you tap Ask App Not to Track

Apple's support article for users says that if you choose Ask App Not to Track, "the app developer can't access the system advertising identifier (IDFA)", and the app is also not allowed to track you through other information that identifies you or your device, such as your email address. You can still use the full app either way, and Apple's App Review Guidelines (section 5.1.2(i), cited in Apple's FAQ) forbid apps from gating features on the answer.

Technically, Apple's advertisingIdentifier documentation says the property returns all zeros in these cases:

• In Simulator, regardless of settings.
• On macOS, and in a compatible iPhone or iPad app running in visionOS.
• On iOS and iPadOS 14.5 and later, if the app has not requested authorisation through ATT.
• If the app requested authorisation and the user declined (status denied).
• When a configuration profile restricts access to the advertising identifier.

So enforcement has two layers: the operating system withholds the IDFA, and Apple's policy forbids tracking by any other means. The second layer depends on App Review and on honest privacy labels and privacy manifests.

The global switch and who cannot turn it on

In Settings, Privacy & Security, Tracking, the switch "Allow Apps to Request to Track" controls whether apps can show the prompt at all. Apple's support article says that with it off, every app that asks is treated as if you had tapped Ask App Not to Track. The same screen lists each app that asked, with its own toggle.

Apple also lists cases where the switch cannot be turned on: child accounts and users under 18 by birth year signed in with their Apple Account, Apple Accounts managed by a school or business, managed devices with a configuration profile that limits tracking, and Apple Accounts created in the last three days. In those states, apps that request tracking cannot get the IDFA.

Changes in the European Union

Apple's developer page says it is changing ATT in the EU as part of agreements with some European competition authorities. Beginning with iOS 27.2 and iPadOS 27.2, developers can use an alternative ATT prompt in the EU with modified wording and an optional "Additional Information" button. Apple says that, due to legal requirements, only the alternative prompt is available for apps distributed in Germany, France, Italy, Poland and Romania. EU developers may re-prompt a user one year after the previous choice, unless the user has turned off the global switch. The rules on when permission is needed do not change, and the app still cannot read the IDFA until the user grants permission in the ATT prompt.

What ATT does not cover

ATT governs linking your data across companies. It does not stop first party use (an app personalising based on what you do inside it, or a company using IDFV across its own apps without other companies' data), data collected outside the app and unrelated to it, or contextual ads. Nor does it stop a bad actor by itself: an SDK that fingerprints anyway breaks Apple's rules, and the defence is App Review and enforcement rather than cryptography.

How Android handles the advertising ID

Android's advertising ID lives in Google Play services, not in the core operating system, so the controls appear on devices with Google Play and Google can change behaviour through Play services updates.

Reset versus delete

The Play Console help page describes two user actions in Settings, Privacy, Ads:

• Reset Advertising ID generates a new random ID. Apps that read the ID afterwards get a value unconnected to the old one. Data already linked to the old ID on someone's server stays there.
• Delete Advertising ID removes it. Google says that since a Google Play services update in late 2021, deleting the ID in Android Settings removes it, and any app that asks for it gets a string of zeros instead.

Google rolled this out in phases: apps running on Android 12 from late 2021, then all devices that support Google Play from 1 April 2022. On some older Android versions the setting is Settings, Privacy, Advanced, Ads, with a toggle named "Opt out of Ads Personalization". The API also exposes a limit ad tracking flag (isLimitAdTrackingEnabled) that apps are expected to honour. Returning zeros is the stronger control, because it does not depend on every SDK checking a flag.

The Google Play services API reference for AdvertisingIdClient.Info.getId() states it plainly: on Android 12 devices, from late 2021, when limit ad tracking is enabled the returned value "will be 00000000-0000-0000-0000-000000000000 regardless of the app's target SDK level".

The AD_ID permission

Google added a second gate for developers. The Play Console help says that apps which update their target to Android 13 or above must declare a Google Play services normal permission in the manifest:

<uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

Without it, getId() returns zeros on those apps even if the user has not deleted the ID. Apps targeting API level 32 (Android 12L) or older do not need the permission.

Two subtleties matter in practice:

• SDKs can add it for you. Google's help notes that some SDKs, including Google's own mobile ads SDK, declare AD_ID in their library manifest, and the Android build tools merge it into your app's final manifest by default. You can ship the permission without ever typing it.
• You can strip it. The Play services reference shows the removal form for apps that do not want the ID:

<uses-permission android:name="com.google.android.gms.permission.AD_ID"
    tools:node="remove"/>

Because AD_ID is a "normal" permission, users are not prompted for it. Its value is as a declaration you can audit, and as a lever: an app that removes it cannot read the ID no matter which SDK asks.

Google Play policy on identifiers

The Play Developer Program Policy requires new apps and updates to use the advertising ID, when available on the device, instead of any other device identifier for advertising. Apps using another persistent ID for ads may receive a policy violation warning. Persistent identifiers remain available for non-advertising uses as long as the app has a privacy policy and follows the Developer Distribution Agreement and applicable privacy law. When an advertising ID is not present, the policy allows falling back to a persistent or proprietary identifier under those same conditions. For essential uses that are not ads, such as analytics and fraud prevention, Google points developers to the App Set ID.

App Set ID

The App Set ID is scoped either to one app or to the set of apps published under the same Google Play developer account on a device, similar in spirit to Apple's IDFV. The Android documentation says the SDK tries to return a developer scoped ID automatically, and that the system resets the value when no app in the group has accessed the API for over 13 months, when the last app in the group is uninstalled, or after a factory reset. Apps must read it through the SDK each time they need it. It is not an advertising identifier and Google directs it at analytics and fraud cases only.

Devices without Google Play

On devices without Google Play services, the AndroidX Advertising ID library (Android 4.0, API level 14, and higher) lets an ad provider app on the device supply a resettable ID with its own settings screen for reset and opt out. Whether such a provider exists depends on the device maker.

What happened to Privacy Sandbox on Android

Google spent several years building Privacy Sandbox for Android, a set of APIs meant to support ads and measurement with less reliance on cross app identifiers. On 17 October 2025 Google said that, "in light of their low levels of adoption", it would retire the Attribution Reporting API (Chrome and Android), On-Device Personalization, Private Aggregation, Protected Audience (Chrome and Android), Protected App Signals, SDK Runtime and Topics (Chrome and Android), among others. The Privacy Sandbox home page now says some of the technologies are being phased out and points to a feature status page.

For Android users, the advertising ID and your choice to reset or delete it remain the primary control. For developers whose measurement plan assumed Attribution Reporting on Android, check Google's feature status page before building on it.

What replaces cross-app tracking

Advertisers still want to know whether an ad worked. Apple's answer is aggregated, signed attribution that does not send the device identity to the ad network.

SKAdNetwork

Apple's SKAdNetwork class is available from iOS 11.3. The flow, according to Apple's documentation, involves three parties: ad networks that sign ads and receive install validation postbacks, source apps (or Safari web pages) that show the ads, and advertised apps that update "conversion values" as people use them. If the person installs and opens the advertised app within the attribution window, the device later sends a postback. Starting in iOS 16.1, apps can update conversion values during three conversion windows, producing up to three postbacks for ads signed with SKAdNetwork version 4.

Two design choices carry the privacy:

• Apple says the information in the postback that Apple cryptographically signs "doesn't include user- or device-specific data". Values from the ad network and the advertised app are included only when they meet a privacy threshold Apple sets.
• Apple assigns each conversion a postback data tier, and the device uses that tier to decide how much detail the postback may carry, so that each person stays hidden in a crowd. A tiny campaign gets coarse data.

AdAttributionKit

AdAttributionKit, available from iOS 17.4, extends the same model to the App Store and alternative app marketplaces. Apple's documentation describes the same three participants, signed postbacks and data tiers, and adds re-engagement conversions, where an ad brings someone back to an app they already have. Apple documents interoperability between SKAdNetwork and AdAttributionKit, so ad networks can support both.

Privacy manifests and tracking domains

Apple added a second mechanism aimed at SDKs. A privacy manifest is a property list named PrivacyInfo.xcprivacy that apps and third party SDKs include. Its top level keys include:

• NSPrivacyTracking: whether the app or SDK uses data for tracking as ATT defines it.
• NSPrivacyTrackingDomains: the internet domains the code contacts that engage in tracking. Apple's documentation says that if the user has not granted tracking permission through ATT, network requests to these domains fail and the app receives an error.
• NSPrivacyCollectedDataTypes: the data types collected.
• NSPrivacyAccessedAPITypes: the "required reasons" APIs used and why.

Apple's user privacy page says Xcode combines all the manifests in an app into one report to help build accurate privacy labels. For SDKs on Apple's list of commonly used SDKs, a privacy manifest and a signature are required.

ATT alone gates one API; declared tracking domains let the operating system block network calls too, provided the SDK declares its domains honestly.

Fingerprinting rules

Both platforms prohibit using device signals as a substitute ID for ads. Apple forbids deriving data from a device to identify it uniquely, and Google's Play policy requires the advertising ID instead of other device identifiers for advertising. In the EU, the EDPB guidelines (below) bring fingerprinting techniques within Article 5(3) of the ePrivacy Directive. Our browser fingerprinting explainer covers how those signals work on the web.

Comparison: tracking methods side by side

Resetting your ID helps but does not finish the job: it only cuts links keyed to the advertising ID. If an app also has your email, the email bridges the gap.

Timeline: advertising IDs and the rules around them

What the law says

ePrivacy Article 5(3)

Article 5(3) of the ePrivacy Directive (2002/58/EC, as amended in 2009) says that "the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user" is allowed only with consent, or where strictly necessary for specific purposes. It is often called the cookie rule, but the EDPB's guidelines stress that it reaches similar technologies as well as cookies.

EDPB Guidelines 2/2023 on the technical scope

The European Data Protection Board adopted version 2.0 of its Guidelines 2/2023 on 7 October 2024 after public consultation, and published them on 16 October 2024. They do not single out IDFA or the Android advertising ID by name, but their reasoning covers them:

• The guidelines name smartphone system APIs, including access to identifiers, as information an app can use strictly inside the device. Such use is not "gaining of access" while the information stays on the device. Once the information, or anything derived from it, is accessed from outside, Article 5(3) applies.
• In the section on unique identifiers, they say that when the collecting entity instructs the device, through client side code, to send an identifier, "a 'gaining of access' is taking place and Article 5(3) ePD applies".

Read together: an ad SDK that reads the advertising ID and sends it to a server is the textbook case. In the EU, that generally requires consent unless an exemption applies, separately from whatever lawful basis the later processing needs under the GDPR.

GDPR

Once the advertising ID sits on a server next to other data about you, it is generally treated as personal data under the GDPR, because it can single out a device and the person using it. The GDPR then governs the lawful basis, transparency, retention, access and deletion for everything joined to it. That is why many EU apps show a consent platform as well as, on iOS, the ATT prompt. Apple's FAQ explicitly allows referencing a prior consent platform choice in the ATT purpose string, but says the app must always respect the answer given in the ATT prompt, even when the user answered other prompts differently.

US state privacy laws

The California Consumer Privacy Act, as amended, defines "unique identifier" or "unique personal identifier" in Civil Code section 1798.140(aj) as "a persistent identifier that can be used to recognize a consumer, a family, or a device that is linked to a consumer or family, over time and across different services", and its list of examples names "cookies, beacons, pixel tags, mobile ad identifiers, or similar technology". The same section lists unique personal identifiers among the identifiers that count as personal information when they can reasonably be linked to a consumer or household. So a business subject to the CCPA should treat advertising IDs tied to its users as personal information: disclose them, honour opt-outs of sale or sharing, and honour deletion requests. Our post on CCPA and Global Privacy Control explains how browser opt-out signals work alongside this. Several other US state privacy laws follow a similar model; check each statute's definitions rather than assuming they match California's.

FTC Act

At the federal level there is no general privacy statute, but the FTC uses its authority over unfair and deceptive practices. The location data orders above show the FTC treating the sale of sensitive location data tied to advertising IDs as an unfair practice, and treating location data linked to an advertising ID as identifiable.

Step by step: reset, delete and review on your phone

These steps follow Apple's and Google's own help pages. Menu names on Android can differ by manufacturer and version.

iPhone and iPad

1. Turn off the global switch. Open Settings, tap Privacy & Security, tap Tracking, and turn off "Allow Apps to Request to Track". Apple says every app that asks is then treated as if you tapped Ask App Not to Track. Apple's support article also says you can choose to ask all apps you previously allowed to track to stop, or let those apps continue. Choose to ask them all to stop.
2. Review the per app list. If you prefer to keep the switch on, the same Tracking screen lists each app that asked. Turn off any you do not want to track you.
3. Check App Privacy Report. Turn on App Privacy Report in Privacy & Security settings. After a few days, it shows how often apps accessed data such as location, camera and microphone, and which web domains apps contacted most often. Domains you do not recognise in an app that should not need them are worth a closer look.
4. Read the App Store privacy label before installing. Apple says each app's product page shows some of the data types the app may collect and whether that data is used to track you or is linked to your identity or device. Apple's label definitions put the device's advertising identifier under Device ID.
5. Review Location Services separately. ATT does not govern location permission. In Privacy & Security, Location Services, set apps to "While Using" or "Never", and turn off Precise Location for apps that do not need your exact position, since location is the field that turns an ad ID into a map of your life.

Android

1. Delete the advertising ID. Open Settings, tap Privacy, tap Ads, tap Delete Advertising ID and confirm. Apps then receive a string of zeros. On some older versions the path is Settings, Privacy, Advanced, Ads, with a toggle named "Opt out of Ads Personalization".
2. Or reset it. If you prefer to keep an ID, Reset Advertising ID in the same screen generates a new one. Do this after removing apps you no longer trust, so the new ID is not handed straight back to them.
3. Check the Data safety section. On each app's Google Play listing, the Data safety section summarises what the developer says it collects and shares. Google's help page says data is "shared" when it is "transferred to a third party", with exceptions such as transfers to a service provider. Look for "Device or other IDs" under data shared.
4. Review location permission. In Settings, Location, App location permissions (names vary by manufacturer), set apps to "Allow only while using the app" or "Don't allow", and turn off "Use precise location" where the option exists.
5. Remove apps you do not use. Each uninstalled app is a set of SDKs that can no longer read anything.

Exercising your legal rights

Resetting or deleting the ID does nothing about data already collected. In California and other states with privacy laws you can ask businesses to delete personal information and stop selling or sharing it; in the EU you can withdraw consent and request erasure under the GDPR. Some data broker opt-out forms ask for your advertising ID; reset or delete it afterwards.

Step by step for developers: audit your app's ad ID access

If you ship a mobile app, you are accountable for every SDK inside it. Apple says so in its FAQ, and Google's policy applies to the app as published. This walkthrough finds out what your build can actually read and send.

Step 1: inventory your SDKs and their versions

List every third party library in the build, including transitive dependencies pulled in by ad mediation adapters. For Android with Gradle:

# Print the resolved release dependency tree and look for ad, attribution and analytics SDKs
./gradlew :app:dependencies --configuration releaseRuntimeClasspath > deps.txt
grep -iE "ads|attribution|analytics|adid|identifier" deps.txt

For iOS with CocoaPods or Swift Package Manager:

# CocoaPods: the lockfile lists every pod and version
grep -E "^  - " Podfile.lock

# Swift Package Manager: resolved packages and pinned versions
cat *.xcworkspace/xcshareddata/swiftpm/Package.resolved 2>/dev/null \
  || cat *.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved

A software bill of materials (SBOM) does this job continuously instead of once. Generating one per release means you can answer "which of our apps ship version X of this SDK" without rebuilding anything.

Step 2 (Android): check the merged manifest for AD_ID

The permission that matters is the one in the final, merged manifest, not the one you typed:

# Build the release variant, then inspect the merged manifest
./gradlew :app:processReleaseMainManifest
grep -R "com.google.android.gms.permission.AD_ID" app/build/intermediates/ | head

# Or inspect the shipped APK directly with the SDK's apkanalyzer tool
apkanalyzer manifest permissions app-release.apk | grep AD_ID

Gradle task names and intermediate paths vary across Android Gradle Plugin versions; if the task name differs, run ./gradlew :app:tasks --all | grep -i manifest to find it. Android Studio's Merged Manifest tab shows which library contributed each permission.

If AD_ID is present and you do not show personalised ads or need ad attribution, remove it with the tools:node="remove" form shown earlier (with xmlns:tools="http://schemas.android.com/tools" declared on the manifest element), rebuild and check again. If you do need it, make sure your Play Console declarations and Data safety form say so.

Step 3 (Android): confirm on a test device

# List permissions the installed app has been granted
adb shell dumpsys package com.example.yourapp | grep -A2 "AD_ID"

Replace com.example.yourapp with your package name. On a test device you can also delete the advertising ID in Settings and confirm in your own debug logging that your code paths handle the zeroed value without crashing or falling back to another identifier.

Step 4 (iOS): find code that touches the IDFA and ATT

# Which bundled code references the advertising identifier or ATT?
grep -rIl "ASIdentifierManager\|advertisingIdentifier\|ATTrackingManager" Pods/ Sources/ 2>/dev/null

# Does the built binary link the AdSupport or AppTrackingTransparency frameworks?
otool -L "Payload/YourApp.app/YourApp" | grep -iE "AdSupport|AppTrackingTransparency"

# What purpose string will the ATT prompt show?
plutil -extract NSUserTrackingUsageDescription raw "Payload/YourApp.app/Info.plist"

Closed source SDKs ship as binaries that source grep misses; the linked frameworks and privacy manifests (next step) partly cover that gap.

Step 5 (iOS): read every privacy manifest in the build

# Find every privacy manifest bundled with the app and its SDKs
find . -name "PrivacyInfo.xcprivacy" -print

# Print one to see its tracking flag, tracking domains and collected data types
plutil -p path/to/PrivacyInfo.xcprivacy

Look at NSPrivacyTracking and NSPrivacyTrackingDomains in each. If an SDK says it tracks, your app needs the ATT prompt before that SDK's tracking runs, and your privacy label must declare the data as used for tracking. Apple says Xcode combines all the manifests in an app into one report when you prepare to distribute it; that report is a good artefact to attach to your release checklist.

Step 6: gate SDK initialisation on the user's answer

Request ATT authorisation before initialising any SDK that tracks, and initialise those SDKs in a non-tracking mode (or not at all) when the status is anything other than authorised. On Android, wire your EU consent platform so ad SDKs start only after consent where required. Re-check status on each launch, because Apple notes users can change their choice at any time in Settings, and Apple advises not to store the IDFA value but to read the API each time. Google's Android documentation gives the same advice for the advertising ID, because the user can reset it after your app starts.

Step 7: write it down

Record, per release: SDK names and versions, whether AD_ID is in the merged manifest, whether AdSupport is linked, the ATT purpose string, the tracking domains and the store label answers. When a reviewer or regulator asks what your app shares, you want this table, not a fresh investigation.

Common mistakes

• Treating ATT as a switch for the IDFA only. Apple's rules cover hashed emails, fingerprint IDs and device graph identifiers too. Denied permission means no tracking by any route.
• Assuming you have no AD_ID because you never added it. Library manifests merge it in by default. Check the merged manifest or the shipped APK.
• Storing the advertising ID. Both Apple and Google say to read it each time. A cached ID ignores the user's later reset, deletion or withdrawal.
• Falling back to another identifier when the ad ID is zero. On iOS this breaks Apple's policy. On Android, a zeroed ID after deletion reflects the user's choice; read the Play advertising ID policy carefully before using any other identifier for ads.
• Resetting the ID but keeping the apps. A new Android advertising ID handed to the same SDKs that also have your email or login is quickly re-linked.
• Forgetting location. The FTC cases above centred on location data attached to advertising IDs. Ad ID controls and location permissions are separate settings and both matter.
• Treating store labels as verified facts. Apple's labels and Google's Data safety section are developer declarations. They are useful, and they are only as accurate as the developer's SDK inventory.
• Gating features on the ATT answer. Apple's App Review Guidelines forbid it, and Apple's FAQ says you cannot offer incentives for allowing tracking either.

FAQ

What is my IDFA and where do I find it?

The IDFA is Apple's Identifier for Advertisers, a random UUID that apps can read only with your ATT permission on iOS 14.5 and later. iOS does not show it in Settings. What you control is which apps may read it, in Settings, Privacy & Security, Tracking.

Is GAID the same as AAID or the Android advertising ID?

Yes. Google's documentation calls it the advertising ID. "GAID" (Google Advertising ID) and "AAID" (Android Advertising ID) are industry shorthand for the same identifier provided by Google Play services.

Should I reset or delete my Android advertising ID?

Delete it if you do not want personalised ads based on cross app activity; apps then get zeros. Reset it if you want to keep personalised ads but break the link with your old history. Deleting is the stronger option.

Does "Ask App Not to Track" stop all ads?

No. You will still see ads. They will be contextual or based on what you do inside that app, rather than on data linked across other companies' apps and websites. Apple says you keep full access to the app either way.

Can apps still track me after I deny ATT permission?

They are not permitted to. Apple's policy forbids tracking you with other identifiers, such as a hashed email, or with fingerprinting, and network calls to declared tracking domains fail. Enforcement relies on App Review, so an app that breaks the rules is possible, but it is breaking Apple's terms.

Why does my app get an advertising ID of all zeros?

On iOS: the app has not requested ATT permission, the user declined, the device is in a restricted state, or you are in Simulator. On Android: the user deleted the ID, the app targets Android 13 or later without declaring the AD_ID permission, or limit ad tracking is enabled on Android 12 and later.

Is the advertising ID personal data under GDPR?

Once it is linked to other information about a person or used to single out a device, it is treated as personal data. Separately, the EDPB's guidelines say that instructing a device to send an identifier is "gaining of access" under Article 5(3) of the ePrivacy Directive, which generally requires consent.

Is a mobile advertising ID personal information under the CCPA?

Generally yes, when it can reasonably be linked to a consumer or household. California Civil Code section 1798.140(aj) lists "mobile ad identifiers" as an example of a unique identifier, and the same section lists unique personal identifiers among the identifiers that count as personal information.

What replaced IDFA for ad measurement?

On Apple platforms, SKAdNetwork and AdAttributionKit provide signed, aggregated install and re-engagement postbacks that Apple says contain no user or device specific data. On Android, Google announced in October 2025 that it is retiring the Privacy Sandbox Attribution Reporting API, so check Google's feature status page before choosing a measurement approach.

Where Safeguard fits

Safeguard does not manage phones, read device settings or audit app store labels, and the fit with this topic is indirect. It helps with Step 1 of the developer audit: Safeguard builds SBOMs from repositories, container images and SBOM files (for example safeguard scan --dir .), shows which projects contain a given component and version, and matches components against vulnerability databases with reachability analysis. That tells you which apps carry a particular ad or analytics SDK version. It does not tell you whether that SDK tracks; for that you still read its privacy manifest and documentation.

Mobile apps are built from the same open source and third party packages as any other software: ad mediation adapters, analytics libraries, networking stacks and the React Native or Flutter plugins that wrap them. Advertising ID controls do nothing about a vulnerable version of one of those components, so keeping the dependency tree patched remains part of shipping a trustworthy app, even though the fit with this topic is indirect.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: the assistant fixes a lodash CVE, asks before each command, edits package.json, and runs npm install and npm test with approval, pushing nothing. The same flow applies when your SDK inventory shows an outdated library in a React Native or web companion project and you want the upgrade made and tested before release.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code and scans from the terminal. It suits a mobile team that wants an SBOM of each app repository before a privacy review.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It helps when you want to ask which of your projects contain a given SDK version while filling in the Step 7 table.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Apple Developer: App Tracking Transparency framework
• Apple Developer: ATTrackingManager
• Apple Developer: ASIdentifierManager
• Apple Developer: advertisingIdentifier
• Apple Developer: identifierForVendor
• Apple Developer: User privacy and data use
• Apple Developer: App privacy details on the App Store
• Apple Developer: Privacy manifest files
• Apple Developer: SKAdNetwork
• Apple Developer: AdAttributionKit
• Apple Support: If an app asks to track your activity
• Apple Newsroom: Apple introduces iPhone 5 (iOS 6 release date)
• Apple Newsroom: iOS 14.5 release, 26 April 2021
• Google Play Console Help: Advertising ID
• Google Play Help: Data safety section
• Google Play services reference: AdvertisingIdClient.Info
• Android Developers: Get a user-resettable advertising ID
• Android Developers: App set ID
• Android Developers: Android 10 privacy changes
• Android Developers Blog: Google Play services 4.0, 31 October 2013
• Privacy Sandbox: Update on plans for Privacy Sandbox technologies, 17 October 2025
• Privacy Sandbox home page
• EDPB: Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive
• EDPB: Guidelines 2/2023 version 2.0 (PDF)
• California Privacy Protection Agency: CCPA statute text (PDF)
• FTC: Order prohibits X-Mode Social and Outlogic from selling sensitive location data, 9 January 2024
• FTC: Action against Mobilewalla, 3 December 2024
• FTC: Action against Gravy Analytics and Venntel, 3 December 2024
• FTC: Mobilewalla decision and order (PDF)
• FTC: Final order prohibiting Gravy Analytics and Venntel from selling sensitive location data, 14 January 2025
• FTC: Final order banning Mobilewalla from selling sensitive location data, January 2025

Last reviewed: 24 October 2026. Platform settings and policies change with each release; check the linked Apple and Google documentation for the version you run.