A first look: Google’s Privacy Sandbox and its effect on SDKs | by Dor Sakal | May, 2022

Earlier this year Google announced its Privacy Sandbox for Android which aims to build technology that improves user privacy in a fundamental way, while supporting the critical ecosystem use cases.

This was done as part of a broader move Google started a few years ago on Chrome, and will have a profound impact on the mobile advertising industry as a whole. The company has said that the Privacy Sandbox APIs will be built over a couple of years, during which they will release developer previews to allow the Android ecosystem parties to learn how it will affect their products, and to provide Google with feedback.

The first developer preview, which was released a couple of weeks ago, provides a glimpse into how two of the four Privacy Sandbox design proposals will work; SDK Runtime and Topics API.

I tested the SDK Runtime preview — here’s what I learned as well as some thoughts on things that we can expect to come. Of course, since this is the first developer preview, things may still change as Google matures the initiative.

Historically, Android was built as an open platform that allowed its developers to build apps that do pretty much anything they want on the device. While this approach created a wealth of possibility, it also brought up many security, privacy, and user experience issues. As the platform matured, Google limited more and more of what apps can do via API deprecation, permission protections, and different policies. However, SDKs that are hosted on APKs still have many capabilities that are not critical to support their main use cases. For example: if an app has permission granted by the user to access their contact list, all SDKs hosted on that app will have the same capability.

The SDK Runtime design proposal, which is initially intended to be adopted by ad platforms, aims to reduce undisclosed access to sharing user data, and allows SDKs to only do what they need to do — nothing more, nothing less. Such SDKs are named Runtime Enabled SDKs (RE SDKs).

With that in mind, I set up a working test environment to play around with this new tech.

Google provided great tutorials for setting up your development environment and downloading a device or emulator image. It is important to note that this Privacy Sandbox Developer Preview is not a part of the Android 13 Beta 1 that was released on April 26th, and so I set my emulator to use the “TiramisuPrivacySandbox” API level (and not “Tiramisu”).

Choosing the right system image in Android Studio

In addition, Google provided sample projects that work out of the box. I imported the PrivacySandboxKotlin project into Android Studio, and followed the README.md file which has a step-by-step guide for running the project correctly. I carefully followed the instructions as there are specific steps that must be taken for the apps to be installed successfully.

For example — the RE SDK app is a headless app (an app that doesn’t have a launcher icon) and to be installed successfully it needs to be set to be installed without launching an Activity.

So I followed the steps, and voila! We have a working app that loads an RE SDK, and presents a WebView that is managed by that RE SDK.

RE SDK sample project

I then started experimenting and learned a few interesting things.

The general idea of ​​the SDK Runtime Sandbox from a technical standpoint is to have RE SDKs and their host app run on separate processes. So those RE SDKs run segregated with limited resources, permissions, and capabilities. The way this is done is interesting; There is a system app with a package name of “com.google.android.sdksandbox”. This app starts a process when an app loads an RE SDK:

In case an app uses two RE SDKs, both of those SDKs are loaded into the same process:

Then, if another app uses the same RE SDK as another app’s, the com.google.android.sdksandbox app loads that SDK in a new process:

It’s worth mentioning:

  • When I made a change in RE SDK #1, it took effect in both App #1 and App #2 without needing to rebuild those apps. Imagine this with many apps that use the same SDK.
  • When I made a change in RE SDK #1 while App #1 was running, App #1 was killed, which makes sense as that app depends on that SDK. I assume that it will be the Android app stores’ responsibility to avoid a situation where they update an SDK that is currently being used.
  • Though the RE SDKs are APKs installed like any other app, they cannot be found in the Settings>Apps section of the device. I found the following path in the logs, where I assume the RE SDKs are installed: ‘/data/app/ ~~CvlPF2J8-S7qvAK2MIRJFQ==/com.example.privacysandbox.provider-PKSpCMsAFYF7Jsiv6nEIbw==/base.dm’
    However, since the emulator provided by Google with this preview is not rooted, I can’t navigate to that folder and validate.

The way RE SDKs work is truly innovative. It solves many problems while presenting a completely new way to work with SDKs on Android, and so, many questions come to mind when reading the design proposals and playing with the first preview. I will mention a few I find interesting:

  • In their test device setup tutorial, Google write:
    “The Privacy Sandbox on Android emulator system image requires a device definition with the ‘Play Store’…”.
    However the Privacy Sandbox is an AOSP feature, and so it’s not yet clear why Google Play or Google Play Services would be required. Moreover, I disabled both Google Play and Google Play Services on the emulator, and the SDK Runtime project works great. It might just be how Google set things up for the developer preview to work, and it will be interesting to see this in future releases.
  • The fact that the RE SDKs are developed and built as apps is interesting from three different perspectives:
    – RE SDK developers (ad platforms at the moment) now have a new way to build and manage their artifacts. And, potentially, ship minor updates without having to ‘bother’ the app developers.
    – App developers that use RE SDKs no longer use gradle dependencies. Instead, they declare their SDKs in their app’s AndroidManifest.xml file.
    – Store developers need to make sure that the RE SDKs required by an app are installed before that app is installed (otherwise, the installation will fail).
    It will be interesting to see what tools Google will provide to help all parties adapt to this completely new and different way of integrating with SDKs on the Android platform.
  • The fact that a RE SDK can be installed once and reused by all of the apps that are integrated with it is incredibly efficient, as the number of SDKs is minor compared to the number of apps that use them. However, it remains unclear how this will be managed across Android App Stores. For example, will an app installed via Samsung’s Galaxy store be able to use RE SDK installed via the Google Play store? Will there be a centralized place for ad platforms to manage their RE SDKs in, or will they need to start managing their SDKs in different Android App Stores?

A change like the RE SDKs is important and shows the Android ecosystem’s maturity. As such, it is complex to implement, and it will be very interesting to see Google build it together with the ecosystem.

At ironSource, we constantly keep track on all of these changes, and we’d love to hear your thoughts on the topic. What interests/concerns/excites you about Google’s Privacy Sandbox? Feel free to reach out to me on dors@is.com.

Leave a Comment