Com google android sdk sandbox что это

The first developer preview of Privacy Sandbox on Android

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.

Android’s SDK Runtime in Privacy Sandbox is a game changer

Google’s proposed SDK runtime in Privacy Sandbox on Android is a game-changer that represents a massive opportunity to both reduce ad fraud and boost people’s privacy. It’s also something I wouldn’t be surprised to see Apple copy on iOS, but deliver earlier than Privacy Sandbox’s minimum two-year timeline for delivery.

This is part one of a longer series of deep dives into Privacy Sandbox for Android where I’ll be looking at Google’s new technology for privacy and marketing:

SDK Runtime (this post) (how Privacy Sandbox will do ad targeting) (how Privacy Sandbox will do ad retargeting)
Attribution Reporting (how Google is proposing ad measurement will work

Also see Mobile Attribution via Android Privacy Sandbox and without GAID, Singular CEO Gadi Eliashiv’s deep dive into mobile attribution post GAID.

And finally, sign up for the LinkedIn livestream Gadi and I will run on Thursday.

SDKs and apps: the promise and the peril

In the beginning there was the app. A developer said: I need more app candy and capability, but I don’t have the recipe, or ability to bake the cake all by myself. Solution providers filled the gap with delicious pre-coded goodies that app developers could simply conjure up in code without having to do very much work at all.

But SDKs with extensive fingerprinting code were the cause of Apple rejecting app updates back in the early days of iOS 14.5. They’re one way some apps have been kicked off the App Store. And SDKs from rogue ad networks have been accused of driving both attribution fraud on billions of devices and orchestrating privacy-threatening data exfiltration … including snooping on communications in apps.

The modern app ecosystem couldn’t function without SDKs. They’re absolutely critical to the software that everyone who uses a smartphone or a tablet today depends on.

But they’re also a double-edged sword.

Google thinks it has a solution.

Go to your room right now (SDKs are getting grounded)

Because some SDKs have been very bad boys indeed — and you can bet we’re privy to less information on just how bad than Google itself — Google is grounding them.

Or, confining them to a sandbox.

An “execution environment,” if you will.

Inside this execution environment SDKs will have specific permissions and will execute them outside the main app process. In other words, SDKs will have much less implicit insight into what apps are doing and app developers will have full explicit control — or at least more control — over what an SDK sees and does.

In Privacy Sandbox for Android, processes are isolated.

SDKs live in a separate world. Adtech SDKs are no longer able to see and track app usage via persistent identifiers without developer knowledge and consent, and they’re also going to have a much more difficult time collecting perishable identifiers, or factors that can be summed up into a temporary identifier.

In addition, Google’s making it harder for SDKs to tamper with the functionality of other SDKs.

At the same time, however, Google is leaving room for SDKs to detect and prevent ad fraud and invalid traffic, where developers permit.

Google is your messenger now, SDKs

In the old model (today), apps and SDKs communicate unimpeded. They live, after all, in the same space and can chat whenever they want, however they want.

In the new world, which Google will provide in beta by the end of 2022, Google will build a “marshaling layer” which developers will call from within an app.

App needs the SDK to do something.
App code calls the marshaling layer and delivers a packet
The marshaling layer delivers the request to the SDK (presumably checking it first for legitimacy)
The SDK delivers an answer back to the marshaling service
The marshaling layer completes the loop with the needed data or functionality for the app

An important point: this could be asynchronous. As Google has currently defined the process, the “SDK asynchronously satisfies the requests and responds using the callbacks.” That could potentially mess with functionality that requires instant response, which is a little confusing: pretty much everything in an app requires instant response as the app needs to present options for users and then deliver responses based on their decisions and input.

However, this is all pre-beta at the moment, so there’s no need to get too worried about that just yet.

Also: Google is building in functionality for SDK-to-SDK communication for scenarios like mediation and bidding. That’s a massive part of the adtech ecosystem on mobile with SDK networks that offer mediation services like the new titans of adtech: ironSource, Liftoff+Vungle, AppLovin, Digital Turbine, and Unity. There will be the ability, Google is saying, for SDKs to offer ad impressions or run ad auctions by communicating with other SDKs, whether they’re inside or outside of the SDK runtime environment.

However, there’s clearly open questions here: notice the language Google uses like “should” and “investigation.”

“The coordinating SDK, RE [runtime-enabled] or not, should be able to access all RE and non-RE SDKs for normal operation. Rendering in this context is an active area of investigation.”

SDK makers: get ready to submit

In some sense, SDK makers have gotten a free pass. While apps themselves have to go through an App Store approval process on iOS or Google Play, SDKs have just kind of glided through on their customers’ or developers’ efforts.

Not any more, likely.

Given the unique sandboxed runtime environment SDKs will now exist in, Google is proposing that SDK makers submit their SDKs to Google Play and then become available for use by apps via Google Play itself. Google says this will ensure quality and consistency, streamline publication, and make minor SDK updates — that don’t require app code changes to function — quicker and cleaner.

Google’s ideas here are quite nebulous, however, and it’s not at this point saying explicitly that this is the future of distribution for all SDKs.

However, software developers can read the tea leaves as well as anyone else, and once this mechanism is in place and available, it’s not hard to imagine that it will become the preferred — and over time likely the mandatory — method of SDK distribution.

Much more to dig into

As I mentioned up top, there’s a lot more to dig into here. Sign up for updates on our blog newsletter to be notified when we publish more.

Also, I’m doing a live stream with Singular CEO Gadi Eliashiv on this topic on Thursday, February 24. Sign up for that here.

Первый взгляд на «песочницу конфиденциальности» Google и ее влияние на SDK

Я протестировал предварительную версию SDK Runtime — в этой статье я делюсь тем, что узнал, а также некоторыми мыслями о том, что нам следует ожидать.

Ранее в этом году Google анонсировал свою песочницу конфиденциальности для Android, целью которой является создание технологии, которая фундаментальным образом улучшает конфиденциальность пользователей, поддерживая при этом критически важные варианты использования экосистемы.

Это было сделано в рамках более широкой инициативы, которую Google начал несколько лет назад в отношении Chrome. Эта инициатива окажет глубокое влияние на индустрию мобильной рекламы в целом. Компания заявила, что API-интерфейсы Privacy Sandbox будут создаваться в течение нескольких лет. В течении них компания будет выпускать предварительные версии для разработчиков, чтобы участники экосистемы Android могли узнать, как это повлияет на их продукты, и предоставить Google отзывы.

Первая предварительная версия для разработчиков, выпущенная пару недель назад, дает представление о том, как будут работать два из четырех компонентов в конструкции песочницы конфиденциальности — SDK Runtime и Topics API.

Я протестировал предварительную версию SDK Runtime — в этой статье я делюсь тем, что узнал, а также некоторыми мыслями о том, что нам следует ожидать. Конечно, поскольку это первая предварительная версия для разработчиков, все может измениться по мере того, как Google будет развивать инициативу.

Немного предыстории SDK Runtime

Исторически Android создавался как открытая платформа, позволяющая разработчикам создавать приложения, которые делают на устройстве практически все, что они хотят. Хотя этот подход создал множество возможностей, он также вызвал множество проблем с безопасностью, конфиденциальностью и взаимодействием с пользователем. По мере взросления платформы Google ограничивал все больше и больше возможностей приложений с помощью устаревания API, защиты разрешений и различных политик. Однако SDK, размещенные в APK, по-прежнему имеют множество возможностей, которые не являются критически важными для поддержки их основных вариантов использования. Например, если приложению предоставлено пользователем разрешение на доступ к списку контактов, все SDK, размещенные в этом приложении, будут иметь такую же возможность.

Предложения по системному дизайну SDK Runtime, который изначально предназначался для использования рекламными платформами, направлены на сокращение скрытого доступа к пользовательским данным и позволяет SDK делать только то, что им нужно — ни больше, ни меньше. Такие SDK называются SDK с поддержкой среды выполнения (Runtime Enabled SDK, RE SDK).

Имея это в виду, я настроил рабочую тестовую среду, чтобы поиграть с этой новой технологией.

Запуск тестового проекта

Google предоставил отличные руководства по настройке среды разработки и загрузке образа устройства или эмулятора. Важно отметить, что эта предварительная версия Privacy Sandbox Developer Preview не является частью Android 13 Beta 1, выпущенной 26 апреля, поэтому я настроил свой эмулятор на использование уровня API «TiramisuPrivacySandbox» (а не «Tiramisu»).