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

Обеспечить обратную связь

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

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

В Android 13 мы добавили новую возможность платформы, которая позволяет сторонним 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 приложения. Это помогает защитить пользователей и разработчиков приложений от загрузки недействительных SDK, а также позволяет магазинам приложений значительно снизить нагрузку на распространение SDK со стороны разработчиков приложений.

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

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

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

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

---

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

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

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

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

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

Доступ

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

Разрешения SDK

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

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

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

Память

Среда выполнения 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, который, учитывая использование собственного кода, необходимо будет заменить альтернативой, такой как встроенная версия SQLite в Android SDK.

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 13, когда приложение находится на переднем плане, среда выполнения SDK работает с высоким приоритетом и вряд ли будет прекращена. Когда приложение переходит в фоновый режим, приоритет процесса среды выполнения SDK снижается, и оно становится доступным для завершения. Приоритет процесса среды выполнения SDK остается низким, даже если приложение возвращается на передний план. Следовательно, весьма вероятно, что оно будет прекращено из-за нехватки памяти по сравнению с приложением.

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

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

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

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

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

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

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

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

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

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

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

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

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

Состояние системы

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

Связь

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

Приложение в 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, с помощью следующих шагов:

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

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

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 может запускать активность, принадлежащую другому приложению, но с ограничениями на то, что можно отправлять в намерении. Например, к этому намерению нельзя добавить никакие дополнительные или пользовательские действия.
• 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 не могут добавлять тег действия в свой файл манифеста и не могут запускать собственные действия с помощью Context.startActivity . Вместо этого платформа создает действия для SDK по запросу и передает их SDK.

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

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

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

Разработка

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

Авторская работа

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

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

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

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

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

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

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

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

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

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

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

Строит

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

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

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

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

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

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

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

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

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

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

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

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

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

Наше проектное предложение о отделении приложения от SDKS создало возможность для распространения SDKS App Store. Это общая возможность, не уникальная для какого -либо конкретного магазина приложений. Преимущества ясны:

• Обеспечить качество и последовательность 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 на событиях жизненного цикла на уровне приложений о его клиентском приложении (например, приложение, входящее в фон, приложение, заходящее на передний план). Дизайн и пример кода будут переданы в предстоящий предварительный просмотр разработчика.

{ % Vorbatim %} { % endverbatim %}

Рекомендуется для вас

• Примечание. Текст ссылки отображается, когда JavaScript выключен
• Руководство разработчика среды выполнения SDK

{ % Vorbatim %} { % endverbatim %}