Формат нативной рекламы позволяет издателю настраивать объявление, показываемое пользователю. После загрузки объявления из SDK издатели могут изменить макет и внешний вид объявления, чтобы оно лучше соответствовало пользовательскому интерфейсу приложения: добавить цветовой фильтр, изменить типографику и добавить пользовательские наложения. Для оптимизации производительности или удобства использования нативной рекламы издатели часто устанавливают ограничения на количество показов или переносят воспроизведение видео в SDK. Наконец, издатели могут настраивать обработчики кликов по объявлениям для отслеживания дополнительных событий, таких как свайпы вверх.
Формат нативной рекламы требует от издателя более высокого уровня доверия, чем для показа других форматов рекламы. SDK обычно стремятся выявлять нарушения правил и проверять, был ли показан пользователю рекламный контент, предоставленный издателю.
Поддержка баннерной рекламы в среде выполнения SDK реализуется через API SurfaceControlViewHost . Это позволяет SDK отображать элементы пользовательского интерфейса из процесса среды выполнения SDK без вмешательства со стороны клиентского приложения. Используйте режимы SurfaceView Z above или Z below, чтобы определить, находится ли поверхность, на которой отображается пользовательский интерфейс SDK, выше или ниже окна клиентского приложения. Когда реклама отображается в режиме Z above, SDK получает MotionEvents от взаимодействия с пользователем, но представления клиентского приложения не отображаются поверх рекламы. Когда реклама отображается в режиме Z below, приложение отображает свои собственные представления поверх рекламы, но MotionEvents от взаимодействия пользователя с рекламой поступают в приложение, а не в SDK.
Библиотеки Jetpack privacysandbox.ui могут использоваться SDK и издателем для установления и поддержания сессии пользовательского интерфейса.
Контейнер рекламы, принадлежащий приложению
Мы разработали прототип, в котором SDK владел всеми элементами, составляющими нативную рекламу (включая наложения приложения), и обнаружили, что, хотя это и осуществимо, это накладывает некоторые ограничения на пользовательский интерфейс и увеличивает сложность интеграции с SDK. Более прагматичный подход заключается в том, чтобы позволить приложению владеть большинством элементов интерфейса. SDK по-прежнему может самостоятельно отображать некоторые элементы интерфейса, например, рекламное окно, используя SandboxedSdkView из privacysandbox.ui . Этот подход обеспечивает наибольшую гибкость в поддержке существующих и будущих вариантов использования этого формата рекламы: при таком подходе разработчик приложения может перемещать компоненты рекламы и стилизовать их по своему усмотрению, в то время как SDK сохраняет право собственности на видеоплеер, если это необходимо, и поддерживает доступ к элементам управления воспроизведением.
Уведомления о состоянии рекламы
Различные SDK анализируют разные свойства рекламных представлений для обнаружения мошенничества и нарушений политики. Мы хотели бы поддерживать это без предписания того, какие свойства использовать, и без превращения SDK в узкое место, заставляющее его изменять набор запрашиваемых свойств. Мы предлагаем создать представление рекламного контейнера и его дочерних представлений с помощью NativeAdContainerInfo . Это будет объект, допускающий последовательность действий, с различными геттерами, предоставляющими информацию, ограниченную рекламным контейнером и его содержимым, при этом такая информация должна обеспечивать конфиденциальность и не требовать больших вычислительных затрат . SDK сможет выбирать категории сигналов, включенных в NativeAdContainerInfo . SDK будет получать этот объект всякий раз, когда состояние объявления изменяется способами, имеющими отношение к SDK, такими как события, подлежащие оплате, например, показ объявления и клики пользователей.
Кроме того, издатель сможет добавлять к каждому дочернему элементу, добавленному в NativeAdContainer , специфичные для представления теги (строки), которые можно использовать, чтобы сообщить SDK, какому рекламному ресурсу соответствует каждый дочерний элемент.
Когда пользователь щелкает по элементам интерфейса, принадлежащим SDK, библиотека пользовательского интерфейса пересылает в MotionEvent со свойствами, преобразованными в координатное пространство SDK, вместе с исходным событием MotionEvent. В будущих версиях Android мы изучаем возможность добавления способов, позволяющих клиентскому приложению передавать фокус касания для всех жестов пользователя на принадлежащие SDK части этой нативной рекламы, чтобы эти действия обрабатывались SDK.
Свидетельства
Для повышения надежности отображения рекламы SDK будут доступны следующие подтверждения:
- Проверка целостности устройства : используйте API платформы, такие как проверка ключей, для определения целостности устройства.
- Проверка подлинности APK : используйте API SDK Sandbox, такие как
SdkSandboxController.getClientPackageName, и API PackageManager, такие какrequestChecksumдля проверки подлинности APK. -
VerifiedMotionEvents: В будущих версиях Android мы изучаем возможность предоставления клиентскому приложению возможности передавать фокус касания для всех жестов пользователя в частях этой нативной рекламы, принадлежащих SDK, для обработки самим SDK.MotionEventsможно преобразовать вVerifiedMotionEventsс помощью системных API. При желании SDK может отображать собственный пользовательский интерфейс в ответ на взаимодействие с пользователем.
Открытые вопросы
- Предпочтительнее ли, чтобы SDK генерировал
VerifiedMotionEventsсамостоятельно, или чтобы это делала библиотека пользовательского интерфейса поставщика для SDK? - Предпочтительнее ли для SDK позволять издателю владеть представлениями, содержащими видео, или же владеть этими представлениями самостоятельно?
- Какие свойства вы хотели бы видеть в объекте
AppOwnedAdContainerInfo? - Сколько рекламных объявлений или компонентов, принадлежащих SDK, вы планируете отображать одновременно на экране?