借助原生广告格式，发布商可以自定义要向用户展示的广告。从 SDK 提取广告后，发布商可更改广告的布局和外观，使其与应用的界面更相配：添加色彩滤镜、更改排版和添加自定义叠加层。为了优化原生广告的效果或用户体验，发布商通常会设置显示限制或将视频播放任务分流到 SDK。最后，发布商可以自定义广告点击监听器以监听其他事件，例如向上滑动。
相较于其他广告格式，展示原生广告需要对发布商有更高的信任度。SDK 通常需要检测违反政策的情况，并验证提供给发布商的广告内容是否向用户展示。
SDK 运行时中的横幅广告支持是通过 SurfaceControlViewHost API 实现的。这样 SDK 就可以显示来自 SDK 运行时进程的界面元素，而不会遭到客户端应用的篡改。使用 SurfaceView 的 Z above 或 Z below 模式 确定呈现 SDK 界面的 Surface 是位于客户端应用窗口上方还是下方。使用 Z above 模式呈现广告时，SDK 会收到来自用户互动的 MotionEvents，但客户端应用视图不会在广告上显示。使用 Z below 模式呈现广告时，应用会在广告层之上显示自身视图，但来自广告上用户互动中的 MotionEvents 会传给应用，而不是 SDK。
SDK 和发布商可以使用 privacysandbox.ui Jetpack 库建立和保持界面会话。
应用自有广告容器
我们进行了原型设计，让 SDK 自己拥有构成原生广告（包括应用叠加层）的所有视图；我们发现该做法虽然可行，但会导致界面存在一些限制，并会增加与 SDK 集成的复杂性。更实用的方式是让应用拥有大多数视图。SDK 仍可以使用 privacysandbox.ui 中的 SandboxedSdkView 选择是否自行显示某界面，例如广告视图。在现有和未来的使用情形中，就如何使此广告格式受支持方面，此方法可提供最大程度的灵活性：采用此方法，应用开发者可视需要移动广告组件并调整样式，而 SDK 会保留视频播放器的所有权（视您的偏好而定），并保有对媒体控件的访问权限。
关于广告状态的通知
不同的 SDK 通过广告视图的不同属性来检测欺诈和违反政策行为。我们愿意支持此功能，但不希望规定要使用哪些属性，或在 SDK 变更查询的属性集时造成瓶颈。我们提议使用 NativeAdContainerInfo 创建广告容器及其子视图的表示法。这将是一个 Parcelable 对象，其中包含各种用于展示仅限广告容器及其内容相关信息的 getter，在 getter 中，此类信息可保护隐私，而且计算费用不高。SDK 将能够选择启用 NativeAdContainerInfo 中包含的信号类别。每当广告状态以涉及 SDK 的方式更改（例如广告展示和用户点击等可计费事件）时，SDK 都将收到此对象。
此外，发布商将能够向添加到 NativeAdContainer 的每个子项添加针对特定视图的标记（字符串），标记可用于告知 SDK 每个子项与哪个广告素材资源相对应。
当用户点击 SDK 自有视图时，界面库会将 MotionEvent（具有转换为 SDK 坐标空间的属性）连同原始的 MotionEvent 一起转发给 SDK。在未来的 Android 版本中，我们将探索添加相关方法，让客户端应用针对 SDK 自有部分（位于 SDK 所处理的这个原生广告内）中的所有用户手势转移触碰焦点。
证明
系统会向 SDK 提供以下证明，以更有力地保证广告展示效果：
- 设备完整性证明：使用密钥认证等平台 API 来确定设备完整性。
- APK 身份：使用 SdkSandbox API（如
SdkSandboxController.getClientPackageName）和 PackageManager API（如requestChecksum）验证 APK 身份。 VerifiedMotionEvents：在未来的 Android 版本中，我们将探索添加相关方法，让客户端应用针对 SDK 自有部分（位于 SDK 所处理的这个原生广告内）中的所有用户手势转移触碰焦点。您可通过系统 API 将MotionEvents转换为VerifiedMotionEvents。SDK 可以选择是否显示自有界面来响应用户互动。
开放性问题
我们诚邀您就以下几点提供反馈：
- 让 SDK 自行生成
VerifiedMotionEvents，或使用提供方界面库为 SDK 执行此操作，哪种方式更好？ - SDK 让发布商拥有包含视频的视图，或 SDK 自己拥有这些视图，哪种方式更好？
- 您希望看到
AppOwnedAdContainerInfo对象中包含哪些属性？ - 您希望在屏幕上同时显示多少个 SDK 自有广告或广告组件？