Обзор среды выполнения SDK

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

Как и в большинстве операционных систем, в Android SDK выполняются в изолированной среде приложения-хоста и наследуют те же привилегии и разрешения, что и приложение-хост, а также доступ к памяти и хранилищу приложения-хоста. Хотя такая архитектура позволяет гибко интегрировать SDK и приложения, она также создает потенциал для сбора и обмена скрытыми пользовательскими данными. Более того, разработчики приложений могут не быть полностью осведомлены о функциональности стороннего SDK и данных, к которым он обращается, что затрудняет учет методов сбора и обмена данными в их приложении.

В Android 14 мы добавили новую функцию платформы, которая позволяет сторонним SDK работать в выделенной среде выполнения, называемой SDK Runtime . SDK Runtime обеспечивает следующие более надежные меры защиты и гарантии в отношении сбора и обмена пользовательскими данными:

• Модифицированная среда выполнения
• Четко определенные разрешения и права доступа к данным для SDK.

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

Цели

Данное предложение направлено на достижение следующих целей:

• Сократите несанкционированный доступ и обмен данными приложения пользователя со стороны сторонних SDK за счет изоляции процессов и четко определенного контроля доступа к API и данным. Подробнее об изоляции процессов см. в отдельном разделе этого документа.
• Сократите скрытое отслеживание использования приложения пользователем сторонними SDK, ограничив доступ SDK к уникальным постоянным идентификаторам.
• Обеспечьте безопасное и быстрое распространение обновлений SDK для приложений, снизив нагрузку на разработчиков приложений и конечных пользователей. Подробнее о предлагаемой модели доверенного распространения SDK можно узнать в другом разделе этого документа.
• Помогите разработчикам приложений лучше учитывать методы доступа к данным и их совместного использования в своих приложениях.
• Помогите разработчикам SDK предотвратить несанкционированное изменение кода другими SDK путем ограничения использования определенных небезопасных языковых конструкций, таких как код JNI.
• SDK для работы с рекламой помогают обнаруживать и предотвращать недействительный трафик и мошенничество с рекламой, обеспечивая полный контроль над удаленными представлениями, отображающими медиаконтент.
• Сведите к минимуму нежелательные последствия для разработчиков приложений и SDK.

SDK выполняются в изолированном процессе.

Предлагаемая среда выполнения SDK позволяет совместимым SDK — далее в этом документе именуемым SDK с поддержкой среды выполнения (RE SDK) — работать в отдельном процессе от приложения. Платформа обеспечивает двустороннюю связь между процессом приложения и средой выполнения SDK. Подробности см. в разделе «Связь» этого документа. SDK без поддержки среды выполнения останутся в процессе приложения, как и сейчас. Следующие диаграммы иллюстрируют эти изменения:

Новая модель доверенного распространения SDK

Предлагаемое разделение SDK и приложения мотивирует другую концепцию разделения — для распространения SDK и приложения. Это требует наличия надежного механизма распространения и установки, гарантирующего установку правильных SDK в среду выполнения SDK приложения.

Этот механизм помогает защитить пользователей и разработчиков приложений от загрузки некорректных SDK, а также позволяет магазинам приложений значительно снизить нагрузку на разработчиков приложений, связанную с распространением SDK.

Теперь SDK больше не нужно статически связывать и упаковывать вместе с приложениями перед загрузкой в ​​магазин приложений для распространения.

Процесс включает в себя следующие этапы:

1. Разработчики SDK загружают свои версионированные SDK в магазины приложений отдельно от самих приложений.
2. Разработчики приложений указывают зависимости своего SDK по версии, собирают и загружают релиз приложения, который не включает фактические зависимости SDK.
3. Когда пользователь загружает это приложение, процесс установки использует указанные зависимости SDK приложения для последующей загрузки из магазина приложений.

Этот новый механизм распространения позволяет осуществлять независимые обновления SDK при следующих условиях:

• Исправления ошибок, обеспечивающие обратную совместимость и не добавляющие новых функций, новых API, не изменяющие существующие API и не вносящие изменений в поведение.
• Улучшения, обеспечивающие обратную совместимость возможностей обнаружения или оценки мошенничества.

Реализация этих возможностей зависит от типа хранилища данных.

Следующие диаграммы иллюстрируют предлагаемые изменения в дистрибутиве SDK:

Изменения в способах создания, запуска и распространения SDK и приложений.

Это первоначальное предложение по гибкой среде выполнения и технологии распространения SDK. В следующих разделах предлагается ряд изменений в следующих широких категориях:

• Доступ : права доступа, память, хранилище
• Выполнение : языки программирования, изменения во время выполнения, жизненный цикл, рендеринг мультимедиа.
• Коммуникации : приложение-SDK и SDK-SDK
• Разработка : Как создавать, отлаживать и тестировать в этой модели.
• Распространение : Как распространять, обновлять и откатывать изменения между разными версиями Android, приложений и SDK.

В этот документ также включен раздел часто задаваемых вопросов (FAQ) , который поможет ответить на распространенные вопросы.

Это первоначальное проектное предложение, и мы понимаем, что для некоторых участников экосистемы это может быть существенным изменением. Именно поэтому мы активно запрашиваем ваши отзывы и просим вас делать это через систему отслеживания проблем .

Доступ

Управление конфиденциальностью системы подразумевает управление доступом различных сторон к различным ресурсам. Для реализации нашего предложения по обеспечению конфиденциальности мы предлагаем обновить модель доступа к приложениям, SDK и пользовательским данным, чтобы она следовала принципу минимальных привилегий и предотвращала несанкционированный доступ к потенциально конфиденциальным данным.

Разрешения SDK

В качестве отдельного процесса среда выполнения SDK будет иметь свой собственный четко определенный набор разрешений, а не наследовать те, которые пользователь предоставил приложению. Основываясь на предварительных исследованиях разрешений, используемых SDK, связанными с рекламой, мы предлагаем, чтобы следующие разрешения были доступны SDK в среде выполнения SDK по умолчанию:

• INTERNET : Доступ к интернету для возможности взаимодействия с веб-сервисом.
• ACCESS_NETWORK_STATE : Доступ к информации о сетях.
• READ_BASIC_PHONE_STATE : Доступ к информации о состоянии телефона, например, о типе мобильной сети.
• Разрешения на доступ к API, обеспечивающим конфиденциальность и предоставляющим основные рекламные возможности без необходимости доступа к межприложенийным идентификаторам.
• AD_ID : Возможность запросить рекламный идентификатор. Доступ к этому разрешению также будет ограничен доступом приложения.

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

Память

Среда выполнения SDK будет иметь собственное изолированное пространство памяти благодаря наличию собственного процесса. По умолчанию такая структура запретит SDK доступ к пространству памяти приложения, и приложение, в свою очередь, не сможет получить доступ к пространству памяти SDK. Мы предлагаем сохранить это поведение по умолчанию, чтобы соответствовать принципу минимальных привилегий.

Хранилище

Данное предложение направлено на достижение баланса между необходимостью доступа SDK к хранилищу для их нормальной работы и минимизацией отслеживания данных между приложениями и процессами с использованием постоянного хранилища. Мы предлагаем следующее обновление способа доступа к хранилищу, используемого в настоящее время:

• Приложение не сможет напрямую получить доступ к хранилищу своих SDK, и наоборот.
• Внешнее хранилище устройства не будет доступно для SDK.
• В каждой среде выполнения SDK будет как хранилище, доступное для всех SDK, так и хранилище, являющееся частным для конкретного SDK.

Как и в текущей модели хранения, само хранилище не будет иметь произвольных ограничений по размеру. SDK может использовать хранилище для кэширования ресурсов. Это хранилище периодически очищается, когда SDK не запущен активно.

Исполнение

Для обеспечения конфиденциальности между приложениями, SDK и пользователями, сам контекст выполнения (форматы кода, языковые конструкции, доступные API и системные данные) должен укреплять эти границы конфиденциальности или, по крайней мере, не создавать возможностей для их обхода. В то же время мы хотим сохранить доступ к богатой платформе и большинству возможностей среды выполнения, которыми в настоящее время обладают SDK. Здесь мы предлагаем ряд обновлений среды выполнения для достижения этого баланса.

Код

Код Android (приложения и SDK) преимущественно интерпретируется средой выполнения Android (ART), независимо от того, написан ли код на Kotlin или Java. Богатство возможностей ART и предлагаемые ею языковые конструкции, в сочетании с возможностью проверки по сравнению с альтернативами — в частности, с нативным кодом — обеспечивают оптимальный баланс между функциональностью и конфиденциальностью. Мы предлагаем, чтобы код SDK, поддерживающий среду выполнения, состоял исключительно из байт-кода Dex, а не поддерживал доступ через JNI.

Мы понимаем, что существуют сценарии использования, например, использование специально упакованной версии SQLite, которую, учитывая использование нативного кода, необходимо будет заменить альтернативой, такой как встроенная в Android SDK версия SQLite.

SELinux

На Android каждый процесс (включая те, которые выполняются от имени root) работает в определенном контексте SELinux, что позволяет ядру управлять доступом к системным службам, файлам, устройствам и другим процессам. Стремясь сохранить большинство вариантов использования SDK, минимизируя при этом обход мер защиты конфиденциальности, которые мы пытаемся внедрить, мы предлагаем следующие обновления из контекста SELinux несистемного приложения для среды выполнения SDK:

• Доступен будет ограниченный набор системных сервисов ( в рамках активного проектирования ).
• SDK смогут загружать и выполнять код только из APK-файла.
• Доступ к ограниченному набору свойств системы будет возможен ( в режиме активного проектирования ).

API

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

Кроме того, в последних версиях платформы Android все чаще ограничивается доступ к постоянным идентификаторам в целях повышения конфиденциальности. Для среды выполнения SDK мы предлагаем дополнительно ограничить доступ к идентификаторам, которые могут использоваться для отслеживания действий пользователей в разных приложениях.

Доступ к API среды выполнения SDK возможен только из приложений, работающих в фоновом режиме. Попытка доступа к API SdkSandboxManager из приложений, работающих в фоновом режиме, приводит к возникновению исключения SecurityException .

Наконец, RE-SDK не могут использовать API уведомлений для отправки пользовательских уведомлений в любое время.

Жизненный цикл

В настоящее время SDK приложений следуют жизненному циклу своего хост-приложения, то есть, когда приложение переходит в активный режим или покидает его, завершает работу или принудительно останавливается операционной системой из-за нехватки памяти, SDK приложения также делают то же самое. Наше предложение выделить SDK приложения в отдельный процесс подразумевает следующие изменения в жизненном цикле:

• Приложение может быть закрыто пользователем или операционной системой. В этом случае среда выполнения SDK автоматически завершит работу сразу же после этого.

• Операционная система может завершить работу среды выполнения SDK из-за нехватки памяти или необработанного исключения, например, в самом SDK.

  В Android 14, когда приложение находится на переднем плане, среда выполнения SDK работает с высоким приоритетом и вряд ли будет завершена. Когда приложение переходит в фоновый режим, приоритет процесса среды выполнения SDK снижается, и он становится доступным для завершения. Приоритет процесса среды выполнения SDK остается низким даже после возвращения приложения на передний план. Следовательно, вероятность его завершения из-за нехватки памяти значительно выше, чем у самого приложения.

  В Android 14 и более поздних версиях приоритеты процессов приложения и среды выполнения SDK совпадают. Приоритеты процессов для ActivityManager.RunningAppProcessInfo.importance для приложения и среды выполнения SDK должны быть примерно одинаковыми.

  В случае завершения работы среды выполнения SDK во время работы приложения — например, при возникновении необработанного исключения в SDK — состояние среды выполнения SDK, включая все ранее загруженные SDK и удаленные представления, теряется. Разработчик приложения может справиться с завершением работы среды выполнения SDK, используя любой из следующих методов:

  • Предложение предусматривает использование связанных методов обратного вызова жизненного цикла для разработчиков приложений, позволяющих определять момент завершения работы среды выполнения SDK.
  • Если среда выполнения SDK завершает работу во время показа рекламы, реклама может работать некорректно. Например, рекламные блоки могут застыть на экране и перестать быть интерактивными. Приложение может удалить рекламный блок, если это не влияет на пользовательский опыт.
  • Приложение может предпринять еще одну попытку загрузить SDK и запросить рекламу.
  • В Android 14, если среда выполнения SDK завершает работу, пока SDK загружены, и если разработчик приложения не зарегистрировал вышеупомянутые методы обратного вызова жизненного цикла, приложение завершает работу по умолчанию. Завершаются и выходят из строя только те процессы приложения, у которых загружены SDK.
  • Объекты-связыватели, возвращаемые SDK для взаимодействия с ним (например, SandboxedSdk ), вызывают исключение DeadObjectException если используются приложением.

  Данная модель жизненного цикла может быть изменена в будущих обновлениях.

  В случае постоянных сбоев разработчик приложения должен предусмотреть плавную деградацию без SDK или уведомить пользователя, если SDK имеет решающее значение для основной функциональности приложения. Более подробную информацию о взаимодействии приложения с SDK см. в разделе «Коммуникации» данного документа.

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

Особые случаи

Следующие случаи не поддерживаются и могут привести к неожиданному поведению:

• Если несколько приложений используют один и тот же UID, среда выполнения SDK может работать некорректно. Поддержка общих UID может быть добавлена ​​в будущем.
• Для многопроцессных приложений загрузка SDK должна выполняться в основном процессе.

Визуализация медиафайлов

Существуют SDK, которые отображают контент, такой как текст, изображения и видео, в представлении, заданном приложением. Для этого мы предлагаем подход удаленного рендеринга, при котором SDK будет отображать медиафайлы из среды выполнения SDK, но использовать API SurfaceControlViewHost , чтобы обеспечить отображение медиафайлов в представлении, заданном приложением. Это дает SDK возможность отображать эти медиафайлы таким образом, чтобы это было конфиденциально для пользователя, одновременно помогая предотвратить и обнаружить недопустимые или мошеннические взаимодействия пользователя с отображаемыми медиафайлами.

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

Видеореклама, воспроизводимая непосредственно в потоке, — это реклама, которая показывается в плеере внутри приложения. Поскольку видео воспроизводится в плеере приложения, а не в плеере или представлении в SDK, модель рендеринга отличается от других форматов рекламы. Мы активно изучаем механизмы поддержки как серверной, так и SDK-ориентированной вставки рекламы.

Здоровье системы

Мы стремимся минимизировать влияние среды выполнения SDK на работоспособность конечных устройств и разрабатываем способы достижения этой цели. Однако, скорее всего, некоторые устройства Android 14 начального уровня с очень ограниченными системными ресурсами, такие как Android (Go edition) , не будут поддерживать среду выполнения SDK из-за её влияния на работоспособность системы. Вскоре мы опубликуем минимальные требования, необходимые для успешного использования среды выполнения SDK.

Коммуникации

Поскольку приложения и SDK в настоящее время работают в одном процессе, обмен данными между ними происходит беспрепятственно и без посредников. Кроме того, Android позволяет осуществлять обмен данными между приложениями, даже если этот обмен начинается и заканчивается SDK. Эта модель свободного обмена данными открывает возможности для различных сценариев использования, одновременно предоставляя возможность обмена нераскрытыми данными между приложениями и между SDK внутри приложений и между ними. Мы предлагаем следующие обновления этой модели обмена данными, стремясь найти баланс между ценностью такого обмена и достижением поставленных целей.

App-to-SDK

Наиболее распространенный путь взаимодействия между приложением и SDK — это интерфейс между приложением и SDK, а API SDK — это то место, где сосредоточена большая часть пользовательских различий и инноваций. Мы стремимся сохранить способность SDK к инновациям и дифференциации именно в этом аспекте. Следовательно, наше предложение позволяет SDK предоставлять приложениям доступ к своим API и гарантировать, что приложения смогут извлечь выгоду из всех этих инноваций.

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

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

Общая модель взаимодействия будет выглядеть следующим образом:

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

Следствием новой кросс-процессной структуры данного предложения является необходимость управления двумя жизненными циклами процессов: одним для самого приложения и другим для среды выполнения SDK. Наше предложение направлено на автоматизацию как можно большей части этого процесса, минимизируя влияние на разработчиков приложений и SDK. На следующей диаграмме показан подход, который мы рассматриваем:

Платформа предоставит приложениям новые API для динамической загрузки SDK в процесс выполнения SDK, получения уведомлений об изменениях состояния процесса и взаимодействия с SDK, загруженными в среду выполнения SDK.

График на предыдущем рисунке демонстрирует взаимодействие приложения с SDK на более низком уровне, без слоя маршалинга.

Приложение взаимодействует с SDK, работающим в процессе SDK Runtime, посредством следующих шагов:

1. Прежде чем приложение сможет взаимодействовать с SDK, оно должно запросить у платформы загрузку этого SDK. Для обеспечения целостности системы приложения указывают в своем манифесте, какие SDK они намерены загрузить, и только эти SDK разрешается загружать.

   Приведённый ниже фрагмент кода демонстрирует пример использования API:

   SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
       OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
   

2. SDK получает уведомление о загрузке и возвращает свой интерфейс. Этот интерфейс предназначен для использования процессом приложения. Для совместного использования интерфейса за пределами процесса его необходимо вернуть в виде объекта IBinder .

   В руководстве по связанным сервисам представлены различные способы предоставления IBinder . Какой бы способ вы ни выбрали, он должен быть согласованным между SDK и вызывающим приложением. На диаграммах в качестве примера используется AIDL.

3. SdkSandboxManager получает интерфейс IBinder и возвращает его приложению.

4. Приложение получает объект IBinder и преобразует его в интерфейс SDK, вызывая его функции:

   IBinder binder = sandboxSdk.getInterface();
   ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
   mySdkInterface.something();
   

Приложение также может воспроизводить медиафайлы из SDK, выполнив следующие действия:

1. Как поясняется в разделе этого документа, посвященном рендерингу мультимедиа , для того чтобы приложение могло получить SDK для рендеринга мультимедиа в представлении, оно может вызвать метод requestSurfacePackage() и получить соответствующий объект SurfaceControlViewHost.SurfacePackage .

   Приведённый ниже фрагмент кода демонстрирует пример использования API:

   SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
           Executor executor,
           OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
   

2. Затем приложение может встроить возвращенный SurfacePackage в SurfaceView с помощью API setChildSurfacePackage в SurfaceView .

   Приведённый ниже фрагмент кода демонстрирует пример использования API:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

Наше предложение состоит в том, чтобы API-интерфейсы IBinder и requestSurfacePackage() были универсальными и не предназначались для прямого вызова приложениями. Вместо этого эти API-интерфейсы будут вызываться с помощью сгенерированного справочника API, описанного выше, в «прослойке», чтобы снизить нагрузку на разработчиков приложений.

SDK-to-SDK

Два SDK в одном приложении часто нуждаются в обмене данными. Это может происходить, когда архитектура данного SDK состоит из нескольких отдельных SDK, а также когда двум SDK от разных разработчиков необходимо взаимодействовать для выполнения запроса от вызывающего приложения.

Следует рассмотреть два ключевых случая:

• Когда оба SDK поддерживают работу в среде выполнения , оба SDK работают в среде выполнения SDK со всеми её средствами защиты. SDK не могут взаимодействовать так, как это происходит внутри современного приложения. Следовательно, в SdkSandboxController был добавлен API, позволяющий получать объекты SandboxedSdk для всех загруженных RE-SDK. Это позволяет RE-SDK взаимодействовать с другими SDK, загруженными в среду выполнения SDK.
• Когда включена поддержка только одного SDK в качестве среды выполнения .
  • Если вызывающий SDK запущен в приложении , это работает так же, как и вызов второго SDK самим приложением внутри среды выполнения SDK.
  • Если вызывающий SDK работает внутри среды выполнения SDK , в этом предложении рекомендуется предоставить метод с использованием IBinder , описанного в разделе «Приложение-SDK», который код приложения будет отслеживать, обрабатывать и отправлять в ответ предоставленные обратные вызовы.
  • SDK для рекламы, не поддерживающие режим выполнения, могут быть не в состоянии зарегистрироваться. Мы предлагаем создать SDK-посредник, который будет включать любые SDK партнеров или приложений в качестве прямых зависимостей приложения и обрабатывать регистрацию. Этот SDK-посредник устанавливает связь между SDK, не поддерживающими режим выполнения, или другими зависимостями приложения и посредником, поддерживающим режим выполнения, который выступает в качестве адаптера.

Функционал для взаимодействия между SDK разделен на следующие категории:

• Взаимодействие между SDK внутри среды выполнения SDK (доступно в последней версии для разработчиков)
• Взаимодействие между приложениями и средой выполнения SDK (доступно в последней версии для разработчиков)
• Как должны работать представления и удалённый рендеринг для посредничества (предложение находится в разработке)

В процессе проектирования примитивов рассматриваются следующие варианты использования:

1. Посредничество и торги . Многие рекламные SDK предлагают возможность посредничества или торгов, при которой SDK вызывает различные другие SDK для показа рекламы (посредничество) или для сбора сигналов для проведения аукциона (торги). Как правило, координирующий SDK вызывает другие SDK через адаптер, предоставляемый координирующим SDK. Учитывая описанные выше примитивы, координирующий SDK, независимо от того, является ли он рендеринговым или нет, должен иметь доступ ко всем рендеринговым и не-рендеринговым SDK для нормальной работы. Рендеринг в этом контексте является активной областью исследований.
2. Обнаружение функций . Некоторые продукты SDK состоят из более мелких SDK, которые посредством процесса обнаружения между SDK определяют окончательный набор функций, доступных разработчику приложения. Предполагается, что примитивы регистрации и обнаружения позволят реализовать этот сценарий использования.
3. Модели издателя-подписки . Некоторые SDK разработаны таким образом, чтобы иметь центрального издателя событий, на который другие SDK или приложения могут подписаться для получения уведомлений через обратные вызовы. Приведенные выше примитивы должны поддерживать этот вариант использования.

Приложение к приложению

Взаимодействие между приложениями — это процесс, в котором как минимум один из двух взаимодействующих процессов является SDK с поддержкой среды выполнения, и это потенциальный канал для обмена скрытыми данными. Следовательно, среда выполнения SDK не может установить прямой канал связи ни с каким приложением, кроме клиентского приложения, или с SDK в другой среде выполнения SDK, созданной для другого приложения. Это достигается следующими способами:

• SDK не может определять такие компоненты, как <service> , <contentprovider> или <activity> , в своем манифесте.
• SDK не может публиковать ContentProvider или отправлять широковещательные сообщения.
• SDK может запускать активность, принадлежащую другому приложению, но с ограничениями на то, что можно отправить в Intent. Например, в этот Intent нельзя добавить дополнительные функции или пользовательские действия.
• SDK может запускать или подключаться только к разрешенному списку служб.
• SDK имеет доступ только к подмножеству системного ContentProvider (например, com.android.providers.settings.SettingsProvider ), где полученные данные не содержат идентификаторов и не могут быть использованы для создания отпечатка пользователя. Эти проверки также применяются к доступу к ContentProvider с помощью ContentResolver .
• SDK имеет доступ только к ограниченному набору защищенных широковещательных приемников (таких как android.intent.action.AIRPLANE_MODE ).

Теги манифеста

После установки SDK PackageManager анализирует манифест SDK и не может установить SDK, если в манифесте присутствуют запрещенные теги. Например, SDK не может определять такие компоненты, как <service>, <activity>, <provider> или <receiver> , и не может объявлять <permission> в манифесте. Теги, которые приводят к сбою установки, не поддерживаются в среде выполнения SDK. Теги, которые не приводят к сбою установки, но молча игнорируются, могут быть поддержаны в будущих версиях Android.

Эти проверки также могут применяться любыми инструментами сборки, которые SDK использует для создания пакета SDK, а также во время загрузки в магазин приложений.

Поддержка мероприятий

В среде выполнения SDK SDK не могут добавлять тег activity в свой файл манифеста и не могут запускать собственные действия с помощью Context.startActivity . Вместо этого платформа создает действия для SDK по запросу и предоставляет к ним доступ.

Активность платформы имеет тип android.app.Activity . Активность платформы запускается из одной из активностей приложения и является частью задачи приложения. FLAG_ACTIVITY_NEW_TASK не поддерживается.

Для запуска активности SDK необходимо зарегистрировать экземпляр типа SdkSandboxActivityHandler , который используется для уведомления о создании активности, когда приложение вызывает SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) для запуска активности.

Последовательность запросов на выполнение действия показана на следующем графике.

Разработка

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

Создание контента

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

разработчики приложений

Приложениям потребуется указать зависимости от RE SDK и сертификата SDK в манифесте приложения. В нашем предложении мы рассматриваем это как основной источник достоверной информации от разработчика приложения на протяжении всего процесса. Например:

• Название: Имя пакета SDK или библиотеки.
• Основная версия: Основная версия кода SDK.
• Дайджест сертификата: Дайджест сертификата сборки SDK. Для данной сборки мы предлагаем разработчику SDK получить и зарегистрировать это значение через соответствующий магазин приложений.

Это относится только к SDK, распространяемым через магазины приложений, независимо от того, являются ли они репозиторием или нет. Приложения, статически связывающие SDK, будут использовать существующие механизмы зависимостей.

Учитывая нашу цель минимизировать воздействие на разработчиков, важно, чтобы после определения целевого уровня API, поддерживающего среду выполнения SDK, разработчикам приложений требовалась только одна сборка, независимо от того, работает ли эта сборка на устройствах, поддерживающих или не поддерживающих среду выполнения SDK.

разработчики SDK

В предлагаемом нами проекте разработчикам RE SDK необходимо явно объявить в манифесте новый элемент, представляющий собой сущность SDK или библиотеки. Кроме того, потребуется указать аналогичный набор значений, как и для зависимости, плюс дополнительную версию:

• Название: Имя пакета SDK или библиотеки.
• Основная версия: Основная версия кода SDK.
• Дополнительная версия: Дополнительная версия кода SDK.

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

Разработчикам SDK для RE, вероятно, потребуется продолжить поддержку устройств без поддержки RE, таких как Android 12 или более ранние версии, а также, как упоминалось в разделе «Состояние системы» документа, устройств Android 14 начального уровня с очень ограниченными системными ресурсами. Мы работаем над подходами, которые позволят разработчикам SDK сохранить единую кодовую базу для поддержки сред RE и без RE.

Строки

разработчики приложений

Мы ожидаем, что разработчики приложений практически не заметят изменений на этапе сборки. Зависимости SDK, независимо от того, распространяются ли они локально или через магазин приложений (RE или нет), должны присутствовать на компьютере для проверки синтаксиса, компиляции и сборки. Мы предлагаем, чтобы Android Studio абстрагировала эти детали от разработчика приложения при обычном использовании и сделала этот процесс максимально прозрачным.

Although we expect a DEBUG build would need to include all the code and symbols to be present in the DEBUG build for debuggability, RELEASE builds would optionally have all the app store-distributed SDKs (RE or not) removed from the final artifact.

We are earlier in our design phase here and will share more as it materializes.

SDK developers

We are working on a path to ensure that non-RE and RE versions of an SDK can be built into a single artifact for distribution. This would prevent app developers from needing to support separate builds for RE and non-RE versions of an SDK.

Much like for apps, any app store-distributed dependency SDKs would need to exist on the machine for linting, compilation, and builds, and we expect Android Studio should facilitate this seamlessly.

Тестирование

разработчики приложений

As described in our proposal, app developers would be able to test their apps on devices running Android 14 how they normally would. After they've built their app, the app would be able to be installed on an RE device or emulator. This installation process would ensure the correct SDKs get installed into the SDK Runtime for the device or emulator, whether the SDKs were pulled from a remote SDK repository or cache from the build system.

SDK developers

SDK developers generally use in-house test apps on devices and emulators to test their development. Our proposal doesn't change this, and in-app validation would follow the same steps as outlined for app developers above, with a single build artifact for both RE and non-RE apps. SDK developers will be able to step through their code whether it's in the SDK Runtime or not, though there may be some limitations on advanced debugging and profiling tools. This is an active area of investigation.

Распределение

The separation of an app from its SDKs has created the possibility for app store distribution of SDKs. This is a platform feature, not specific to any distribution channel.

This offers the following benefits:

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

To support SDK distribution, a distribution channel would need to support the following capabilities:

• SDK developers can publish their SDKs to the store or platform, and perform maintenance operations.
• Ensure the integrity of SDKs, apps, and resolve their dependencies.
• Deploy SDKs onto devices in a consistently reliable and performant manner.

Evolving restrictions over time

We expect the restrictions faced by code in the SDK runtime to evolve with later versions of Android. To ensure application compatibility, we won't change these restrictions with mainline module updates for a given SDK level. Behavior associated with a given targetSdkVersion is preserved until support for that targetSdkVersion is deprecated through app store policy, and targetSdkVersion deprecation might happen at a faster cadence than for apps. Expect restrictions to change frequently across Android SDK versions, especially in the first few releases.

Additionally, we're building a canary mechanism to allow external and internal testers to join a group that gets the proposed set of restrictions for the next version of Android. This will help us get feedback and confidence on the proposed changes to the set of restrictions.

Часто задаваемые вопросы

1. What is an advertising-related SDK?

   An ad-related SDK is one that facilitates any part of the targeting of users with messages for commercial ends, on apps that are not owned by the advertiser. This includes, but is not limited to, analytics SDKs where user groups can be created for subsequent targeting, ad serving SDKs, anti-abuse and anti-fraud SDKs for ads, engagement SDKs, and attribution SDKs.

2. Can any SDK run in the SDK Runtime?

   Although the initial focus is for ad-related SDKs, developers of non-ad-related SDKs that seek a pro-privacy posture and believe they can operate under the conditions outlined above can share feedback about their SDKs running in the SDK Runtime. The SDK Runtime isn't designed to be compatible with all SDK designs, however. Beyond the documented limitations, the SDK Runtime is likely unsuitable for SDKs that need real-time or high throughput communications with the hosting app.

3. Why choose process isolation instead of isolation within a process's Java-based runtime?

   Currently, the Java-based runtime doesn't readily facilitate the security boundaries necessary for the privacy assurances that are desired for Android users. Attempting to implement something like this would likely require a multi-year effort, without a guarantee of success. Therefore, the Privacy Sandbox uses use process boundaries, a time-tested and well-understood technology.

4. Would moving SDKs into the SDK Runtime process provide download size or space savings?

   If multiple apps are integrated with runtime-enabled SDKs of the same version, then this can reduce download size and disk space.

5. What kind of app lifecycle events such as when the app goes to the background, will SDKs have access to in the SDK Runtime?

   We are actively working on design support for notifying SDK runtime on app-level lifecycle events of its client application (eg app going into background, app going into foreground). Design and sample code will be shared in an upcoming developer preview.