Com google android sdk sandbox что это
Перейти к содержимому

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.

  1. App needs the SDK to do something.
  2. App code calls the marshaling layer and delivers a packet
  3. The marshaling layer delivers the request to the SDK (presumably checking it first for legitimacy)
  4. The SDK delivers an answer back to the marshaling service
  5. 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»).

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

Выбор правильного образа системы в Android Studio

Кроме того, Google предоставил примеры проектов, которые работают «из коробки». Я импортировал проект PrivacySandboxKotlin в Android Studio и воспользовался файлом, в котором есть пошаговое руководство по правильному запуску проекта. Я внимательно следовал инструкциям, поскольку для успешной установки приложений необходимо выполнить определенные шаги.

Например, приложение RE SDK — это headless приложение (приложение, у которого нет иконки лаунчера), и для его успешной установки необходимо настроить установку без запуска Activity.

Итак, я выполнил шаги, и вуаля! У нас есть рабочее приложение, которое загружает RE SDK и представляет WebView, которым управляет этот RE SDK.

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

Пример проекта RE SDK

Затем я начал экспериментировать и узнал несколько интересных вещей.

Так как же работает RE SDK?

Общая идея песочницы среды выполнения SDK с технической точки зрения заключается в том, чтобы RE SDK и их хост-приложения выполнялись в отдельных процессах. Таким образом, эти RE SDK работают отдельно с ограниченными ресурсами, разрешениями и возможностями. То, как это делается, довольно интересно. Есть системное приложение с именем пакета «». Это приложение запускает процесс, когда приложение загружает RE SDK:

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

Если приложение использует два RE SDK, оба этих SDK загружаются в один и тот же процесс:

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

Если другое приложение использует тот же RE SDK, приложение загружает этот SDK в новом процессе:

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

  • Когда я внес изменение в RE SDK #1, оно вступило в силу как в приложении #1, так и в приложении #2 без необходимости перестраивать эти приложения. Представьте как это работает со многими приложениями, которые используют один и тот же SDK.
  • Когда я внес изменения в RE SDK #1 во время работы приложения #1, приложение #1 было уничтожено, что логично, поскольку это приложение зависит от этого SDK. Я предполагаю, что магазины приложений Android будут нести ответственность за то, чтобы избежать ситуации, когда они обновляют SDK, который используется в настоящее время.
  • Хотя RE SDK представляют собой APK-файлы, установленные также, как и любое другое приложение, их нельзя найти в разделе Настройки > Приложения на устройстве. Я нашел следующий путь в логах, где, как я предполагаю, установлены RE SDK:

Финальные мысли

Способ работы RE SDK действительно инновационный. Он решает многие проблемы, представляя совершенно новый способ работы с SDK на Android, поэтому при чтении предложений по дизайну и работе с первой предварительной версией на ум приходит много идей и вопросов.

Я упомяну некоторые, которые я нахожу интересными:

  • В своем руководстве по настройке тестового устройства Google пишет: «Песочница конфиденциальности на образе системы Android требует определения устройства с помощью Play Store…». Однако «песочница конфиденциальности» — это функция AOSP, поэтому пока неясно, зачем потребуются Google Play или сервисы Google Play. Более того, я отключил на эмуляторе и Google Play, и Google Play Services, и проект SDK Runtime отлично работал. Это может быть просто то, как Google настроил все для работы developer preview версии, и будет интересно увидеть изменения в будущих релизах.
  • Тот факт, что RE SDK разрабатываются и создаются как приложения, интересен с трех разных точек зрения:
    • Разработчики RE SDK (на данный момент рекламные платформы) теперь имеют новый способ создания своих артефактов и управления ими. Возможно, можно будет отправлять небольшие обновления, не беспокоя разработчиков приложений.
    • Разработчики приложений, использующие RE SDK, больше не используют зависимости Gradle. Вместо этого они объявляют SDK в файле AndroidManifest.xml своего приложения.
    • Магазин приложений еще до скачивания приложения должен будет убедиться, что RE SDK, необходимые для продукта, установлены в целевой системе (в противном случае установка завершится ошибкой). Будет интересно посмотреть, какие инструменты Google предоставит, чтобы помочь всем сторонам адаптироваться к этому совершенно новому способу интеграции с SDK на платформе Android.

    Такие изменения, как RE SDK, важны и демонстрируют зрелость экосистемы Android. Их сложно реализовать, и будет очень интересно посмотреть, как Google будет развивать платформу вместе со всей экосистемой.

    ��How SDKs-gone-wild will be reined in with SDK Runtime: Google’s Privacy Sandbox for Android explained ��

    What happens to naughty SDKs that do what they aren’t supposed to do?

    In the second episode of our “Google’s Privacy Sandbox for Android explained” series, we talk about SDK Runtime – Google’s proposed solution to SDKs-gone-wild.

    SDKs are a convenient feature for most app developers. However, some SDKs tend to gather user data in ways that app developers aren’t privy to. SDK runtime is expected to be a step towards limiting the power of SDKs.

    Check out this episode where our CEO Shamanth throws more light on this subject.

    Note: We had two BIG launches last month!

    1. The Mobile Growth Handbook 2022 is packed with incredible insights along with tried and tested strategies, this book is the perfect tool to learn from and hone your growth plans for this year. We feature hand-selected insights from the smartest mobile growth marketers.

    We have over 100 pages of insights that can be accessed at all times (as soon as you sign up). Download the book now and get a head start on your growth strategies.

    Download the book now and get a head start on your growth strategies.

    2. The Mobile Growth Lab Slack: A community that was a part of our workshop series – The Mobile Growth Lab, is now open to the general public. Join over 150 mobile marketers to discuss challenges and share your expertise. More details are available here:

    If you’re ready to join the growing community, fill this form:

    iTunes, Overcast, Spotify or wherever you get your podcast fix. This podcast is very much a labor of love – and each episode takes many many hours to put together. When you write a review, it will not only be a great deal of encouragement to us, but it will also support getting the word out about the Mobile User Acquisition Show.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *