Privacy Sandbox on Android Developer Preview is here! Learn how to get started, and continue to provide feedback.

Progress updates on Privacy Sandbox for Android

Welcome to the first progress update for the Privacy Sandbox on Android. Since announcing in February, we have received feedback from partners across the Android ecosystem. We appreciate all this input, and continue to invite you to share your feedback and questions.

These progress updates will share a summary of new developments and updates to the design proposals, key questions and feedback we have received, and updates on the developer preview releases.

Last updated: May 24, 2022

Design proposal updates

This section describes several specific updates to the design proposals.

Attribution Reporting API

Topics API

  • The Topics API returns a list of up to 3 topics, one for each of the past 3 epochs (for example, during the past 3 weeks). We have updated the Topics API technical proposal to clarify that the returned topics represent the interests of the user and any or all the returned topics can be used for ads personalization.

New releases

The initial Developer Preview releases give you an early look at the Attribution Reporting API, as well as the Topics API and the SDK Runtime. To help you test, you have access to developer resources including documentation, API reference, sample apps, SDK, emulators, and system images for supported Pixel devices. You can build and install a runtime-enabled SDK and use it to render a WebView-based ad, use the Topics API to retrieve test values, or register app ad events.

We'll update the developer preview resources as new functionality is released in the months to come. Please share your feedback or questions and consider signing up to receive regular updates on the initiative.

Update on timeline for Developer Preview releases

All dates and details are subject to change

Each Developer Preview will come with detailed release notes and guides to describe what functionality is and is not available with each release.

Available now:

  • Developer Preview 2 - Early look at SDK Runtime, Topics APIs, and Attribution Reporting APIs (see above for details)

May and June 2022:

  • Early look at FLEDGE APIs (both Custom Audience and Ad Selection APIs)
  • Early look at Attribution Reporting APIs (both event and aggregate APIs)
  • Updates to the SDK Runtime and Topics API developer previews

July 2022 onwards:

  • Regular updates to the developer previews for all APIs and SDK Runtime

By end of 2022:

  • Beta release of the Privacy Sandbox on Android on consumer mobile devices

Reminder: When we announced the Privacy Sandbox on Android in February, we underlined that, while we design, build, and test these new solutions, we plan to support existing ads platform features for at least two years, and we intend to provide substantial notice ahead of any future changes.

Summary of additional questions and feedback received

This section presents some of the questions and feedback that we've received, along with our responses.

General questions

Will the Privacy Sandbox on Android apply to connected TV devices?
Our current design proposals are focused on supporting use cases for mobile devices and apps. We plan to share more on other Android form factors in the future.
How will the Privacy Sandbox on Android be rolled out to devices for the Beta?

To flexibly release updates over time to users, the key components will be distributed as mainline modules to supported Android mobile devices.

This will allow us to deliver improvements to supported devices in a seamless way, outside of the Android platform's normal release cycle.

What's your plan for Kotlin support?

We're working on iterating the Privacy Sandbox API design and intend to enable developers to write idiomatic Kotlin code.

Related developer resources, such as sample apps in the Developer Preview, are available in Kotlin (in addition to Java programming language).

SDK Runtime

How will SDKs versions be managed under these proposals? Will apps be able to control SDK version dependencies if vendors can independently update their SDKs?

This is currently being designed; one approach under consideration is that SDK developers specify the major.minor.patch version of any SDK they choose to distribute through an app store that supports the SDK Runtime.

App developers can then choose the major.minor version they wish to depend on by declaring it in their app manifest. The most recent patch release for that major.minor version will be installed until the next patch is released (which itself will be automatically installed) or until the app developer rebuilds their app specifying a different major.minor version dependency.

Which types of SDKs is the SDK Runtime intended for?

The initial version of the SDK Runtime is being designed to support use-cases for advertising-related SDKs, including SDKs which enable ad serving, ads measurement, ads fraud, and abuse detection.

Although the initial focus is for advertising-related SDKs, developers of non-advertising-related SDKs that seek a pro-privacy posture and believe they can operate under the conditions outlined above can share feedback about their SDKs running in the SDK Runtime.

We currently use permissions outside of those specified in the proposal for our use cases. Can we request further permissions?

We are keen to understand advertising-related use cases that require specific access permissions beyond those in our initial design proposal.

Please continue to share feedback on impacted functionality.

Would moving SDKs into the SDK Runtime process provide download size or space savings?

If multiple apps are integrated with individual runtime-enabled SDKs of the same version, then this would save on download size and disk space.


Would I be able to see a list of all possible topics that can be returned by the API?
For testing purposes, Developer Preview 1 uses topics from this taxonomy, which is subject to change. We expect to evolve this over time based on feedback from the ecosystem.

FLEDGE on Android

Will exclusion targeting be supported by FLEDGE?

The current design proposal does not support negative targeting based on a Custom Audience in FLEDGE.

For app install campaigns, we will be offering a filter ad function for ad tech providers to filter out apps that are already installed. More detail will be provided in upcoming updates to the design proposal.

Attribution reporting

Will the Privacy Sandbox APIs work together to support web-to-app and app-to-web use cases?
We are exploring use cases where a mobile browser app calls the Android Attribution Reporting API to enable attribution across app and web on the same device. If you choose to enable app-to-web, then Privacy Sandbox for Android APIs will be used for storage and attribution and will dedupe attribution across app and web (though you may receive separate reports for app and web from the API which will need to be combined).
Does the API support other attribution models besides last click?
The API supports a source-prioritized, last touch attribution model. Additionally, the proposal supports optional attribution logic for post-install conversions to be attributed to the click or view that drove the install.
Will the Privacy Sandbox impact the Play Install Referrer?

On the basis of the current design and plans, the Privacy Sandbox APIs will not impact the functionality provided by the Play Install Referrer.

Some developers have identified ad formats whereby users can be "rewarded" for completing specific post-click events. Without user level attribution, this would be a challenge under current proposals.

This is an area undergoing investigation to determine possible solutions. We encourage additional feedback for this use case and other use cases that may exist.