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

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

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

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

Реализация этих возможностей зависит от магазина.

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

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

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

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

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

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

Доступ

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

Разрешения SDK

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

• 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 Runtime (ART), независимо от того, написан ли код на Kotlin или Java. Богатство ART и языковых конструкций, которые он предлагает, в сочетании с проверяемостью, которую он предлагает по сравнению с альтернативами, в частности, с нативным кодом, кажется, надлежащим образом уравновешивают функциональность и конфиденциальность. Мы предлагаем, чтобы код SDK с поддержкой среды выполнения состоял исключительно из байт-кода Dex, а не поддерживал доступ JNI.

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

SELinux

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

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

API-интерфейсы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Медиа-рендеринг

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

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

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

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

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

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

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

Приложение-в-SDK

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

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

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

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

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

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

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

График на предыдущем рисунке демонстрирует взаимодействие приложения с 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, обсуждавшейся выше, в слое «shim», чтобы снизить нагрузку на разработчиков приложений.

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 в среде выполнения SDK (доступна в последней версии Developer Preview)
• Связь SDK-SDK между приложением и средой выполнения SDK (доступна в последней версии Developer Preview)
• Как должны работать представления и удаленная визуализация для посредничества (предложение в разработке)

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

1. Медиация и торги . Многие рекламные SDK предлагают возможность медиации или торгов, посредством которой SDK вызывает различные другие SDK для показа рекламы (медиация) или для сбора сигналов для проведения аукциона (торги). Обычно координирующий SDK вызывает другие SDK через адаптер, предоставленный координирующим SDK. Учитывая примитивы выше, координирующий SDK, RE или нет, должен иметь возможность доступа ко всем RE и не-RE 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 Runtime. Теги, которые не приводят к сбою установки, но молча игнорируются, могут поддерживаться в будущих версиях Android.

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

Поддержка деятельности

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

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

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

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

Разработка

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

Авторство

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

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

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

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

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

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

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

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

• Имя: Имя пакета SDK или библиотеки.
• Основная версия: Основной код версии SDK.
• Второстепенная версия: Код второстепенной версии SDK.

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

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

Строит

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

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

Несмотря на то, что мы ожидаем, что сборка отладки должна будет включать в себя все код и символы, которые будут присутствовать в сборке отладки для отказа, сборки выпуска, при желании, будут иметь все приложения, распределенные SDK (RE или нет), снятые из окончательного артефакта.

Мы находимся ранее на нашем этапе дизайна здесь и будем делиться больше, поскольку он материализуется.

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

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

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

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

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

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

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

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

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

Отделение приложения от ее SDK создало возможность распределения SDKS App Store. Это функция платформы, не специфичная для любого канала дистрибуции.

Это предлагает следующие преимущества:

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

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

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

Развивающиеся ограничения с течением времени

Мы ожидаем, что ограничения, с которыми сталкивается код во время выполнения SDK, для развития с более поздними версиями Android. Чтобы обеспечить совместимость приложений, мы не изменим эти ограничения с помощью обновлений модулей Mainline для данного уровня SDK. Поведение, связанное с данной targetSdkVersion сохраняется до тех пор, пока поддержка этого targetSdkVersion не будет устанавливается в результате политики App Store, и на более высокой частоте может произойти снижение targetSdkVersion , чем для APP. Ожидайте, что ограничения часто изменяются в версиях Android SDK, особенно в первых нескольких выпусках.

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

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

1. Что такое SDK, связанный с рекламой?

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

2. Может ли какой -нибудь SDK работать во время выполнения SDK?

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

3. Зачем выбирать изоляцию процесса вместо изоляции в рамках выполнения на основе Java на основе Java?

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

4. Будет ли перемещение SDK в процесс выполнения SDK обеспечить размер загрузки или экономия пространства?

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

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

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