Disclaimer – This is a personal point of view of a design proposal , details of which may change as industry input is gathered and at Google’s discretion to make them available

Responding to Apple’s privacy enhancing ad revenue killing engine named ATT , Google announced Privacy Sandbox for Android.

A key change proposed is the way Android platform executes code when someone installs an app with the introduction of SDK Runtime. This change will improve the way marketing technology platforms especially analytics & advertising will be implemented on Android apps.

What is SDKRuntime?

When an Android app is installed , it assigns a unique UID to ensure dedicated processes can be run & resources can be dedicated accordingly. Each UID has defined set of privileges based on permissions selected by the user. Hence if app A is lets say trying to dial a number or access a user’s location , it wont be able to if the permission was never granted by the user. This dedicated environment with its own set of privileges is referred to as ‘Application Sandbox’.

In Android 13, Google is adding a dedicated runtime environment to integrate 3rd party SDKs named ‘SDKRuntime’ . Isolated from the host app code, this runtime environment would ensure that proper access & data rights are assigned accordingly to third party SDK integrations.

Change 1 : MarTech SDKs would be distributed from the App Store

Currently, if you want to update the martech SDK on your Android app, you would need implement them as a new build and release them as an app update. Then you would wait on your users to update the app to then actually activate the new SDK and its capabilities.

Google proposes to separate the app from the SDK. It (SDK) no longer needs to be linked & packaged together within the app. Rather, these SDKs or the latest versions of the SDKs would be available in app stores for distribution and developers can define dependencies on various SDKs in the manifest file. Upon installation, the specified SDK dependencies would be installed from the app store.

---

---

Change 2 : Bye Bye Advertising ID, Hello Attribution Reporting API

Commonly known as device ID across the industry to measure attribution of the last click or conversion, registering this is ID was one of the key task of any MarTech SDK upon app installation.

Google is introducing Attribution Reporting API that manages the task of attribution on behalf of the device, withut giving away critical personal information that opens the Pandora’s box of ads. Here’s how it works –

---

Reports for ad view attribution sources are sent 1 hour after the source expires. This expiry date can be configured, but it cannot be fewer than 2 days or more than 30 days. Reports for ad click attribution sources cannot be configured and are sent before the source expires, at specified points in time relative to when the source was registered

Change 3 : MarTech SDKs can be terminated at any time while app is running

Today all SDKs within an app follow the same lifecycle activities i.e. if the apps crashes or stops working , the same happens for the SDKs as well. In the new paradigm of Google’s SDK Runtime, these SDKs would get a lower priority than others.

It means that they can be terminated at anytime due to memory shortage or exceptions in data processing. I expect that in such scenarios a unique event such as ‘ SDK crash’ should get triggered to set expectations on the functionality and expected value.

Change 4 : Reduced Android Device Coverage

Continuing on the same thread for hassle free app experiences, MarTech SDKs might not work on entry devices such as Android’s Go edition. That means that any marketing , advertising & measurement use cases cannot be achieved by the population using such devices. Google mentions that over 200 million people use an Android ( Go edition) phone by close of 2021.

The final list of minimum system requirements for such SDKs would be shared shortly.