Tag Archives: sandbox

Preparing for the Android Privacy Sandbox Beta

Posted by Anthony Chavez, VP Product ManagementIn February we announced the Privacy Sandbox on Android, with the goal of bringing new, more private advertising solutions to mobile.

Over the course of 2022, we've published design proposals and released a number of Developer Previews. We appreciate all of the feedback we've received which has helped us refine and improve these proposals.

Beginning early next year we plan to rollout the initial Privacy Sandbox Beta to Android 13 mobile devices, so that developers can take the next steps in testing these new solutions. We'll start with a small percentage of devices and increase over time. Note that Developer Previews will continue to be released and this is where we’ll first deliver the latest features for early feedback before being released on production devices.

Today, we're sharing more details about the Privacy Sandbox Beta so that developers can get prepared.


Enroll to access the Privacy-Preserving APIs

Starting with the Beta release, as well as future Developer Previews, developers will need to complete an enrollment process in order to utilize the ads-related APIs (including Topics, FLEDGE, and Attribution Reporting). The enrollment process will verify developer identity and gather developer-specific data needed by the APIs. You can learn more about how to enroll here.


How to participate

The Privacy Sandbox Beta will be available for ad tech and app developers who wish to test the ads-related APIs as part of their solutions.

During the initial rollout stages, enrolled developers will also need to join the early testers program. This program will allow developers to test the APIs on a limited number of their own Android 13 devices for internal apps and requested published apps.

For the SDK Runtime, we’ll have a closed beta for developers to test Runtime-enabled SDK distribution to select apps. Because of the coordination required to test the SDK Runtime on production devices, we expect this beta to involve a limited number of partners who can dedicate resources to support this testing. If you’re interested in participating, please register your interest.

To utilize the Beta release, developers will need to compile their solutions with an API level 33 SDK extension update that is coming soon.


Advice For Advertisers & Publishers

We’ve heard from many advertisers and publishers about the role they can play in testing these new technologies. For companies that rely on third party solutions for ad serving or ad measurement, we recommend working with your providers to understand their testing roadmaps and how you can participate in early testing of Privacy Sandbox.

We want to thank everyone who has engaged on the Android Privacy Sandbox, and look forward to continued feedback as we enter this next phase of testing."

Preparing for the Android Privacy Sandbox Beta

Posted by Anthony Chavez, VP Product ManagementIn February we announced the Privacy Sandbox on Android, with the goal of bringing new, more private advertising solutions to mobile.

Over the course of 2022, we've published design proposals and released a number of Developer Previews. We appreciate all of the feedback we've received which has helped us refine and improve these proposals.

Beginning early next year we plan to rollout the initial Privacy Sandbox Beta to Android 13 mobile devices, so that developers can take the next steps in testing these new solutions. We'll start with a small percentage of devices and increase over time. Note that Developer Previews will continue to be released and this is where we’ll first deliver the latest features for early feedback before being released on production devices.

Today, we're sharing more details about the Privacy Sandbox Beta so that developers can get prepared.


Enroll to access the Privacy-Preserving APIs

Starting with the Beta release, as well as future Developer Previews, developers will need to complete an enrollment process in order to utilize the ads-related APIs (including Topics, FLEDGE, and Attribution Reporting). The enrollment process will verify developer identity and gather developer-specific data needed by the APIs. You can learn more about how to enroll here.


How to participate

The Privacy Sandbox Beta will be available for ad tech and app developers who wish to test the ads-related APIs as part of their solutions.

During the initial rollout stages, enrolled developers will also need to join the early testers program. This program will allow developers to test the APIs on a limited number of their own Android 13 devices for internal apps and requested published apps.

For the SDK Runtime, we’ll have a closed beta for developers to test Runtime-enabled SDK distribution to select apps. Because of the coordination required to test the SDK Runtime on production devices, we expect this beta to involve a limited number of partners who can dedicate resources to support this testing. If you’re interested in participating, please register your interest.

To utilize the Beta release, developers will need to compile their solutions with an API level 33 SDK extension update that is coming soon.


Advice For Advertisers & Publishers

We’ve heard from many advertisers and publishers about the role they can play in testing these new technologies. For companies that rely on third party solutions for ad serving or ad measurement, we recommend working with your providers to understand their testing roadmaps and how you can participate in early testing of Privacy Sandbox.

We want to thank everyone who has engaged on the Android Privacy Sandbox, and look forward to continued feedback as we enter this next phase of testing."

Preparing for the Android Privacy Sandbox Beta

Posted by Anthony Chavez, VP Product ManagementIn February we announced the Privacy Sandbox on Android, with the goal of bringing new, more private advertising solutions to mobile.

Over the course of 2022, we've published design proposals and released a number of Developer Previews. We appreciate all of the feedback we've received which has helped us refine and improve these proposals.

Beginning early next year we plan to rollout the initial Privacy Sandbox Beta to Android 13 mobile devices, so that developers can take the next steps in testing these new solutions. We'll start with a small percentage of devices and increase over time. Note that Developer Previews will continue to be released and this is where we’ll first deliver the latest features for early feedback before being released on production devices.

Today, we're sharing more details about the Privacy Sandbox Beta so that developers can get prepared.


Enroll to access the Privacy-Preserving APIs

Starting with the Beta release, as well as future Developer Previews, developers will need to complete an enrollment process in order to utilize the ads-related APIs (including Topics, FLEDGE, and Attribution Reporting). The enrollment process will verify developer identity and gather developer-specific data needed by the APIs. You can learn more about how to enroll here.


How to participate

The Privacy Sandbox Beta will be available for ad tech and app developers who wish to test the ads-related APIs as part of their solutions.

During the initial rollout stages, enrolled developers will also need to join the early testers program. This program will allow developers to test the APIs on a limited number of their own Android 13 devices for internal apps and requested published apps.

For the SDK Runtime, we’ll have a closed beta for developers to test Runtime-enabled SDK distribution to select apps. Because of the coordination required to test the SDK Runtime on production devices, we expect this beta to involve a limited number of partners who can dedicate resources to support this testing. If you’re interested in participating, please register your interest.

To utilize the Beta release, developers will need to compile their solutions with an API level 33 SDK extension update that is coming soon.


Advice For Advertisers & Publishers

We’ve heard from many advertisers and publishers about the role they can play in testing these new technologies. For companies that rely on third party solutions for ad serving or ad measurement, we recommend working with your providers to understand their testing roadmaps and how you can participate in early testing of Privacy Sandbox.

We want to thank everyone who has engaged on the Android Privacy Sandbox, and look forward to continued feedback as we enter this next phase of testing."

Privacy Sandbox Developer Preview 3: Support for conversion measurement, custom audiences, and ad selection

Posted by Fred Chung, Android Developer Relations

Privacy Sandbox Developer Preview 3 

The Privacy Sandbox on Android aims to develop new solutions that preserve user privacy and enable effective, personalized advertising experiences for apps. Since our first developer preview, we've shared progress updates and continue to engage the industry on everything from the Developer Preview timeline, to Topics taxonomy, to SDK version management. We appreciate your feedback!

Today, we’re releasing Developer Preview 3, which includes APIs and developer resources for conversion measurement and remarketing use cases. In addition to the preview of SDK Runtime and Topics APIs released earlier, you can for the first time begin testing and evaluating impact on all key APIs for Privacy Sandbox on Android.


Event-Level and Aggregate Attribution Reporting APIs

These APIs allow developers to measure when an ad click or view event leads to a conversion, such as the download of a new game. They support key use cases for attribution across apps and the web, and improve user privacy by removing reliance on cross-party user identifiers.

This release includes a developer guide and sample apps to help you understand client- and server-side set up and interactions for key parts of the attribution reporting workflow, including:

  • Registering attribution source and trigger events.
  • Receiving event reports and unencrypted aggregatable reports.

    • (Note that aggregatable report encryption is not yet implemented. See the release notes for details.)

To help facilitate testing, the release also supports ADB commands to override reporting time windows. Refer to the API reference to learn more about the Android client APIs.


Custom Audience and Ad Selection APIs

Part of FLEDGE for Android, these APIs provide the building blocks to serve customized ads to users based on previous app engagement, without third-party data sharing. You’ll be able to:

  • Manage Custom Audience membership and observe how its parameter values may affect auction outcomes
  • Fetch JavaScript auction code from remote endpoints
  • Configure and initiate on-device ad auctions
  • Handle impression reporting

To learn more, refer to the Custom Audience and Ad Selection API reference pages, as well as the release notes.


Other key features

If you’re just starting to explore the Developer Preview, please also review the supported features described in the SDK Runtime and Topics API developer guides.

If you need a refresher on key technologies for the Privacy Sandbox on Android, we recommend watching this overview video and reviewing the design proposals.

Get started with the Developer Preview

Today’s Developer Preview release provides the resources you need to begin early testing of features and share feedback. To get started developing, see instructions to set up the SDK and system images on the emulator or supported Pixel devices.

For more information on the Privacy Sandbox on Android Developer Preview, visit the developer site and sign up for our newsletter to receive regular updates.

The first developer preview of Privacy Sandbox on Android

Posted by Fred Chung, Android Developer Relations

Blue graphic with privacy icons such as an eye, a lock, and cursor 

We recently announced the Privacy Sandbox on Android to enable new advertising solutions that improve user privacy, and provide developers and businesses with the tools to succeed on mobile. Since the announcement, we've heard from developers across the ecosystem on our initial design proposals. Your feedback is critical to ensure we build solutions that work for everyone, so please continue to share it through the Android developer site.

Today, we're releasing the first developer preview for the Privacy Sandbox on Android, which provides an early look at the SDK Runtime and Topics API. You'll be able to do preliminary testing of these new technologies and evaluate how you might adopt them for your solutions. This is a preview, so some features may not be implemented just yet, and functionality is subject to change. See the release notes for more details on what's included in the release.


What’s in the Developer Preview?

The Privacy Sandbox Developer Preview provides additional platform APIs and services on top of the Android 13 Developer Beta release, including an SDK, system images, emulator, and developer documentation. Specifically, you'll have access to the following:

  • Android SDK and 64-bit Android Emulator system images that include the Privacy Sandbox APIs. See the setup guide.
  • Device system images for Pixel 6 Pro, Pixel 6, Pixel 5a (5G), Pixel 5, Pixel 4, and Pixel 4a. This preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download only.
  • Developer guides for the SDK Runtime and Topics API.
  • Sample code that demonstrates the implementation of runtime-enabled SDKs and usage of the Topics API, available on GitHub.
  • Privacy Sandbox API reference.

Things you can try

When your development environment is set up, consider taking the following actions:

  • Familiarize yourselves with the technical proposals on the SDK Runtime, Topics, Attribution Reporting, and FLEDGE on Android.
  • Topics API: Invoke the API and retrieve test values, representing a user's coarse-grained interests. See the documentation for detail.
  • SDK Runtime: Build and install a runtime-enabled SDK on a test device or emulator. Create a test app to load the SDK in the runtime and request the SDK to remotely render a WebView-based ad in the app. See the documentation for detail.
  • Review and run the sample apps.
  • For details on capabilities and known limitations in this Developer Preview release, check out the release notes.

Over the coming months, we'll be releasing updates to the Developer Preview including early looks at the Attribution Reporting and FLEDGE APIs. For more information, please visit the Privacy Sandbox developer site. You can also share your feedback or questions, review progress updates so far, and sign up to receive email updates.

Happy testing!

Shut the HAL Up

Posted by Jeff Vander Stoep, Senior Software Engineer, Android Security

Updates are essential for security, but they can be difficult and expensive for device manufacturers. Project Treble is making updates easier by separating the underlying vendor implementation from the core Android framework. This modularization allows platform and vendor-provided components to be updated independently of each other. While easier and faster updates are awesome, Treble's increased modularity is also designed to improve security.

Isolating HALs

A Hardware Abstraction Layer (HAL) provides an interface between device-agnostic code and device-specific hardware implementations. HALs are commonly packaged as shared libraries loaded directly into the process that requires hardware interaction. Security boundaries are enforced at the process level. Therefore, loading the HAL into a process means that the HAL is running in the same security context as the process it's loaded into.

The traditional method of running HALs in-process means that the process needs all the permissions required by each in-process HAL, including direct access to kernel drivers. Likewise, all HALs in a process have access to the same set of permissions as the rest of the process, including permissions required by other in-process HALs. This results in over-privileged processes and HALs that have access to permissions and hardware that they shouldn't.

Figure 1. Traditional method of multiple HALs in one process.

Moving HALs into their own processes better adheres to the principle of least privilege. This provides two distinct advantages:

  1. Each HAL runs in its own sandbox and is permitted access to only the hardware driver it controls and the permissions granted to the process are limited to the permissions required to do its job.
  2. Similarly, the process loses access to hardware drivers and other permissions and capabilities needed by the HALs.
Figure 2. Each HAL runs in its own process.

Moving HALs into their own processes is great for security, but it comes at the cost of increased IPC overhead between the client process and the HAL. Improvements to the binder driver made IPC between HALs and clients practical. Introducing scatter-gather into binder improves the performance of each transaction by removing the need for the serialization/deserialization steps and reducing the number of copy operations performed on data from three down to one. Android O also introduces binder domains to provide separate communication streams for vendor and platform components. Apps and the Android frameworks continue to use /dev/binder, but vendor-provided components now use /dev/vndbinder. Communication between the platform and vendor components must use /dev/hwbinder. Other means of IPC between platform and vendor are disallowed.

Case study: System Server

Many of the services offered to apps by the core Android OS are provided by the system server. As Android has grown, so has system server's responsibilities and permissions, making it an attractive target for an attacker. As part of project Treble, approximately 20 HALs were moved out of system server, including the HALs for sensors, GPS, fingerprint, Wi-Fi, and more. Previously, a compromise in any of those HALs would gain privileged system permissions, but in Android O, permissions are restricted to the subset needed by the specific HAL.

Case study: media frameworks

Efforts to harden the media stack in Android Nougat continued in Android O. In Nougat, mediaserver was split into multiple components to better adhere to the principle of least privilege, with audio hardware access restricted to audioserver, camera hardware access restricted to cameraserver, and so on. In Android O, most direct hardware access has been entirely removed from the media frameworks. For example HALs for audio, camera, and DRM have been moved out of audioserver, cameraserver, and drmserver respectively.

Reducing and isolating the attack surface of the kernel

The Linux kernel is the primary enforcer of the security model on Android. Attempts to escape sandboxing mechanisms often involve attacking the kernel. An analysis of kernel vulnerabilities on Android showed that they overwhelmingly occurred in and were reached through hardware drivers.

De-privileging system server and the media frameworks is important because they interact directly with installed apps. Removing direct access to hardware drivers makes bugs difficult to reach and adds another layer of defense to Android's security model.