Separate identity purposes
| Requirement | Appropriate design question |
|---|---|
| Signed-in account | Use the application's authenticated user identity |
| Local installation state | Use a scoped installation mechanism where appropriate |
| Advertising use | Follow advertising-ID availability and policy rules |
| Abuse prevention | Evaluate supported integrity and server-side controls |
Do not silently substitute a hardware identifier when a user removes an advertising ID. That changes both the privacy properties and the policy question.
Treat retrieval as fallible
When using the supported advertising-ID API, follow its threading and error-handling requirements. Devices may lack the expected service or may return an unavailable identifier. Avoid blocking startup or treating a zeroed value as a real unique user.
SDKs often handle access internally. Determine whether your own application actually needs to retrieve the ID before adding another collection path.
Inspect the manifest and the complete SDK inventory
The AD_ID permission can come from dependency manifest merging. Review the final release artifact, not just the source file. Removing this permission does not necessarily disable every form of analytics, advertising or identifier collection performed by other components.
APKLint's Advertising ID Checker can highlight declared access. Its result is not a packet capture or a guarantee of runtime privacy behavior.
Respect resets and disclosure boundaries
Do not join a reset identifier to its previous value using another persistent identifier to bypass the reset. Keep advertising purposes separate from account authentication and review the applicable consent and audience requirements.
When documenting Data Safety, use the actual data flows and current SDK disclosure guides. “Anonymous ads” is an imprecise claim when IP addresses or device information still leave the device.
The Android identity guidance and Google Play User Data policy are the starting references. Record which SDK owns access, why it needs it and how unavailable values are handled; that makes future SDK or policy changes easier to audit.
Do not turn an unavailable value into one shared user
Suppose a diagnostic pipeline indexes advertising events by the returned identifier. If an unavailable or zeroed value is stored as an ordinary key, unrelated devices can collapse into the same record. Model availability separately from the identifier string. An unavailable advertising identifier should remain unavailable; it should not become a valid account key, session credential or substitute installation identity.
The AdvertisingIdClient information reference explains the returned information and its limitations. Review the complete retrieval API's execution requirements before adding application-owned access. If an advertising SDK already handles the identifier, another manual retrieval path may add unnecessary collection and failure handling.
Test change and absence without recording real identifiers
Use an application test double to supply an available synthetic value, an unavailable result and a different synthetic value on a later request. Verify that the UI remains usable and that the event construction handles each branch deliberately. Keep these synthetic cases distinct from a device test of the actual service; a stub validates your handling code, not platform availability.
On an authorized test device, exercise the supported user controls and observe the application's behavior after returning. Do not log the complete real identifier merely to prove that a callback occurred. Record an availability category and the relevant feature transition instead, with enough context to diagnose a failure without retaining an advertising identifier unnecessarily.
Keep authenticated account identity out of this fallback logic. A user signing in should not silently recreate an advertising linkage that a reset or deletion was intended to remove. Review the current advertising-ID requirements before designing any relationship between identifiers.
Finally, test retrieval failure independently from ad-load failure. One does not automatically imply the other, and neither should corrupt saved application data. A useful implementation can explain that advertising identity was unavailable while preserving the app's ordinary account, navigation and content behavior through their own supported identity mechanisms.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
