Director of SDK Engineering for Kochava, Nathan Darst, discusses SDK runtime within Google’s privacy Sandbox, and a developer’s perspective on the problems it solves and new challenges it creates. He also dives into how Google’s SDK Runtime will put operational control into the app users’ hands, and a lot more.
Google recently announced its plans to bring its Privacy Sandbox to Android. Largely conceptual at this point, Google has made it clear this will be a multi-year lift (at least 2 years). The lead time is much appreciated; however, it’s so distant that we don’t have any solidified documentation, betas, or developer previews to act on. So what does that mean? Well, it means at this point we can only speculate as to how the final implementation will look but let’s speculate nonetheless.
There are many components of the Privacy Sandbox, but today we’ll focus on the SDK Runtime component, and what it may mean for the future of advertising or analytics software development kits (SDKs) for apps on Android.
The problem that needs solving
When an app integrates an SDK, the SDK becomes a part of the app; there is no distinction between the app and the SDK from an operational standpoint, which means only the app developer can decide when and how an SDK operates. The app user, by contrast, has no control over SDK operation unless the app developer explicitly designs things that way.
Google’s SDK Runtime aims to put some level of SDK operational control directly into the hands of the app user by decoupling the SDK from the host app. In doing so, the app user or Google may decide whether to restrict or disable an SDK without impacting app functionality.
In other words, similar to the way in which apps are sandboxed, Google aims to provide a means of sandboxing SDKs within apps.
No simple feat
Decoupling the SDK from the app may seem like a simple feat, but this is actually quite a lift from a technical perspective. It’s a challenge because an app developer writes their code with the assumption that an SDK, which they have explicitly integrated, is both 1) operational and 2) functioning as expected. If Google allows the user to choose whether an SDK is disabled or restricted, what happens when the app code attempts to call a disabled SDK or asks an SDK to perform a function that the user chose to restrict?
As of today, this would lead to a crash or some other undefined behavior, but Google’s SDK Runtime attempts to solve this by placing an interface layer between the app code and the SDK. This interface layer will act as a liaison between the app and the SDK so that the app developer doesn’t have to care about the operational state of the SDK, and can instead rely on this interface to gracefully broker communication between the app and the SDK.
This solution will work, but it does come at a cost and cannot be used for every SDK because the SDK Runtime will add overhead and latency to all SDK interactions. For many SDKs, this is not an issue, but for those SDKs which the app expects to be performant or which are tied to critical functionality, the added latency or restricted functionality may adversely impact app performance and user experience. For this reason, Google has suggested the SDK Runtime is optional and that only advertising or analytics SDKs should be placed into it. We don’t yet know how that option will manifest, but we assume the developer will choose which SDKs to place into the SDK Runtime.
The impact
An SDK that has been placed into the SDK Runtime may be operationally restricted in a variety of ways, likely based on privacy-related user preferences. We can only speculate for now as to what sort of restrictions might be imposed.
Let’s hypothesize an example scenario where the user chooses to restrict SDK functionality, the SDK Runtime might prevent an SDK from:
- Accessing certain device data points
- Accessing certain APIs
- Performing network requests
- Reading data from other apps or SDKs
- Writing to disk or reading from disk
In short, SDKs placed into the SDK runtime could see some or all of their functionality restricted, depending on the circumstances.
Additionally, although we don’t know how this will look in code, it’s hard to envision the SDK Runtime not adding some level of burden to the app developer. We expect that all SDK API calls must be wrapped or transformed into interface API calls and will probably require additional error handling. Long term we may even see SDK providers redesigning their APIs to be more SDK Runtime interface-friendly.
SDK Runtime within Google’s Privacy Sandbox
While the app developer could choose not to place an SDK into the SDK Runtime and avoid all of these restrictions, Google may offer up additional incentive to do so by reviewing these SDKs independently of the app. This could appeal to the app developer because historically the app developer has been 100% responsible for all actions taken by their integrated SDKs. If Google considers SDKs in the SDK Runtime separately from the app, an SDK that is non-compliant or violates a policy might simply be operationally restricted (or even removed from the app) by Google, rather than causing the app to fail the certification process or holding the app developer responsible. Google may even be able to retroactively restrict or disable an SDK if new information comes to light after the app has been published, which would prevent an app from being taken down from the store because of questionable SDK behavior.
As Google continues to share its vision for this concept and the industry gives its feedback, we will be watching closely and preparing for the future of the Kochava SDK on Android.
