Recently, we've seen both Apple and Google strive towards creating a more privacy-conscious ecosystem when it comes to advertisements. With Apple, it was with the introduction of a button to prevent apps from tracking you, and with Google, it has been the Android Privacy Sandbox initiative. While information was scarce during its announcement, more details have emerged surrounding the "SDK Runtime" that encompasses part of Google's solution to advertising and privacy.

The Android Privacy Sandbox is comprised of two main components -- the SDK Runtime and Privacy-Preserving APIs -- which will be distributed as Modular System Components, which you may remember as Project Mainline. Google has since published developer documentation surrounding the SDK Runtime and how it will further enhance user privacy. The company says that the SDK Runtime will allow third-party SDKs to run in a dedicated runtime environment in Android 13, away from an app's code.

In Android, each app runs in a sandbox with its own permissions and varying access to the system depending on the access that is granted. As Google puts it, "if app A tries to do something malicious, such as read application B's data or dial the phone without permission, it's prevented from doing so because it doesn't have the appropriate default user privileges." The SDK Runtime further expands that sandbox to execute third-party SDKs in a dedicated runtime environment, away from any one particular app.

Why the SDK Runtime exists

Google wants to prevent advertiser SDKs from collecting data that it shouldn't have access to maliciously (or even inadvertently) as a result of sharing the host app's sandbox. When an advertisement SDK is executed inside of an app, it has access to everything that the app does too, and an app developer may not be completely aware of how much access that actually is. By removing that advertiser code and executing it in its own runtime, then it can only access the data that the developer explicitly shares with it.

As a result, Google says that the SDK Runtime provides the following stronger safeguards and guarantees around user data collection and sharing:

  • A modified execution environment
  • Well-defined permissions and data access rights for SDKs

The first version of the SDK Runtime is focused purely on advertising-related SDKs, including SDKs that enable ad serving, ads measurement, ads fraud, and abuse detection.

How the SDK Runtime works

Currently, without the SDK runtime, an app process will call an SDK and that SDK will execute inside of the same sandbox as the rest of the app's code. Google wants developers to instead have an interface for an SDK that works in an app's foreground process, and that interface can then connect to and share specific data back and forth with the SDK that's being utilized.

Before

Runtime SDK before

After

Runtime SDK after

The "before" diagram (first) shows that the SDK-calling code, along with the SDKs that receive the calls from this code, all reside in the app's process. This means that the SDK can access all of the data that the app can. The "after" diagram (second) shows that, in the app's foreground process, the SDK calling code communicates with SDK interfaces. These interfaces then cross a process boundary into the SDK Runtime process to call into the SDKs themselves. This means that the SDK being used can't just access whatever it wants, it can only be provided with information from the app that it runs alongside.

New trusted distribution model for SDKs

Currently, when you download an application with third-party SDKs, those are included by the developer in the app that's uploaded and distributed on the Google Play Store. Google instead wants it to be the case that when you install an app on your phone that uses those SDKs, they're downloaded separately from the app itself. That means that SDK developers could make non-breaking changes (that is, no changes to APIs or their semantics) to their SDKs and distribute them to devices without any involvement from app developers.

In turn, non-breaking SDK changes could be deployed or rolled back, without necessarily needing to wait for app developers to rebuild their apps with the new SDKs, or waiting for end-users to update their apps. Breaking changes that change APIs and their semantics would still need to be updated by app developers, but SDK developers could get their latest non-breaking changes and fixes out more quickly and more uniformly to more people at once, without relying on an app developer to update their app and package in the new SDK.

Before

SDK Distribution before

After

SDK distribution after

The "before" diagram shows exactly how apps are distributed with SDKs now. They're packaged into an app and the app is what's submitted to the Google Play Store. In the "after" diagram, SDK developers would no longer put their SDKs directly into apps; instead, the SDK developers would upload an SDK and publish it to the Google Play Store. The Google Play Store would then handle the distribution of apps, along with any SDK dependencies, to end-user devices. Google is also intentionally using the phrase "app store" in its diagrams, as it's an open and general solution that can work across other stores.

Changes to how SDKs and apps are built, run, and distributed

The initial proposal for the SDK Runtime proposes a series of changes across five key areas:

  • Access
  • Execution
  • Communications
  • Development
  • Distribution

Google wants to define the following set of permissions for the SDK Runtime:

  • INTERNET: Access to the internet to be able to communicate with a web service.
  • ACCESS_NETWORK_STATE: Access information about networks.
  • Permissions to access the privacy-preserving APIs, which provide core advertising capabilities without needing access to cross-app identifiers. The permission names haven't been finalized but these APIs would be gated by the app's access to these permissions.
  • AD_ID: Ability to request the advertising ID. This would also be gated by the app's access to this permission.
  • BIND_GET_INSTALL_REFERRER_SERVICE: Ability to use the Google Play Install Referrer API to attribute the source of an app's installation.

The company also wants to limit the access that SDKs have to the memory of a running app, but also, to prevent an app from accessing an SDK's own data, too. An app would not be able to directly access its SDKs storage, and vice versa, external storage would not be open to SDKs, and there would be both storage accessible to all SDKs, and storage that's private to a given SDK.

As for how SDKs will run, they will run at a slightly lower priority than the app itself. That is to say that it's very likely an app would be terminated shortly after an SDK Runtime was terminated if the situation arose that it needed to be closed by the system. In the case that it isn't terminated at the same time, or in the case that there is a different reason, the proposal offers related lifecycle callback methods to app developers for them to handle this exception and re-initialize the SDK Runtime. Runtime SDKs will not be able to use the notifications APIs to send user notifications at any point in time.

Finally, Google notes that this is a general proposal that is not unique to any particular app store. While it's presumably going to be built into the Google Play Store, there's no reason why other app stores could not incorporate a similar structure. Google says that the following benefits are clear:

  • Ensure the quality and consistency of SDKs.
  • Streamline publication for SDK developers.
  • Expedite rollout of SDK minor version updates to installed apps.

The Android Privacy Sandbox looks promising

Google’s timeline for release is that Q1 of 2022 involves the initial design proposals and design feedback and iterations. Developer previews will come later on in the year, with a beta at the end of the year. Finally, 2023 will see scaled testing commence. These previews and betas will be independent of the Android 13 release cadence. There will also be user-facing controls in the settings app, once rolled out.

In my opinion, the Android Privacy Sandbox looks promising, but we'll have to wait and see how the company implements it. It's entirely possible that developers won't like it, or that it will actually cause more problems than it solves. Developers are encouraged to read the documentation that Google has posted to get a better feel for what's to come in the future of Android privacy.

This is currently a proposal and not a definitive outlook on what exactly will happen in a future Android version, but it's likely that it will end up pretty close. We'll be keeping an eye out for any further developments!

Source: Android Developer Documentation