El formato de anuncios nativos permite que el publicador personalice un anuncio que se muestra a un usuario. Después de recuperar un anuncio del SDK, los publicadores pueden cambiar el diseño y el aspecto del anuncio para que se alinee mejor con la interfaz de usuario de la aplicación: pueden agregar un filtro de color, cambiar la tipografía y agregar superposiciones personalizadas. Para optimizar el rendimiento o la experiencia del usuario de los anuncios nativos, los publicadores suelen establecer límites de visualización o descargar la reproducción de video al SDK. Por último, los publicadores pueden personalizar los objetos de escucha de clics en el anuncio para supervisar eventos adicionales, como los deslizamientos hacia arriba.
El formato de anuncios nativos requiere un mayor nivel de confianza en el publicador que el necesario para mostrar otros formatos de anuncios. Por lo general, los SDKs quieren detectar incumplimientos de políticas y verificar que se le mostró el contenido del anuncio al usuario.
La compatibilidad de anuncios de banner en el entorno de ejecución de SDK se logra a través de la API de SurfaceControlViewHost. Esto permite que el SDK muestre los elementos de la interfaz de usuario del proceso del entorno de ejecución de SDK sin que la aplicación cliente los manipule. Usa los modos encima de Z o debajo de Z de SurfaceView para determinar si la superficie en la que se renderiza la IU del SDK está encima o debajo de la ventana de la aplicación cliente. Cuando un anuncio se renderiza con el modo encima de Z, el SDK recibe MotionEvents de la interacción del usuario, pero las vistas de la aplicación cliente no son visibles sobre el anuncio. Cuando un anuncio se renderiza debajo de Z, la aplicación muestra sus propias vistas sobre él, pero los MotionEvents de la interacción del usuario en el anuncio van a la aplicación, no al SDK.
El SDK y el publicador pueden usar las bibliotecas privacysandbox.ui de Jetpack para establecer y mantener una sesión de IU.
Contenedor del anuncio propiedad de la app
Realizamos un prototipo para que el SDK posea todas las vistas compuestas por un anuncio nativo (incluidas las superposiciones de la aplicación) y descubrimos que, si bien es posible, impone algunas restricciones a la IU y aumenta la complejidad de la integración con el SDK. Un enfoque más pragmático es permitir que la aplicación posea la mayoría de las vistas. El SDK podrá elegir mostrar algunas IUs, como la vista de anuncio, usando SandboxedSdkView de privacysandbox.ui. Este enfoque proporciona mayor flexibilidad en cuanto a la compatibilidad con los casos de uso existentes y futuros para este formato de anuncio: con este enfoque, el desarrollador de apps puede mover los componentes de los anuncios y aplicarles ajustes de estilo según sea necesario, mientras que el SDK retiene la propiedad del reproductor de video, si así lo prefieres, y mantiene el acceso a los controles de contenido multimedia.
Notificaciones sobre el estado del anuncio
Distintos SDKs observan diferentes propiedades de las vistas de anuncio en busca incumplimientos de políticas y fraudes. Nos gustaría ofrecer esto sin necesidad de prescribir las propiedades que se deberían usar o de convertirnos en un cuello de botella para el SDK al cambiar el conjunto de propiedades que se consultaron. Proponemos crear una representación del contenedor de anuncios y sus vistas secundarias usando NativeAdContainerInfo, un objeto parcelable con varios métodos get que exponen la información limitada al contenedor de anuncios y su contenido, donde esa información preserva la privacidad y no resulta costosa de procesar. El SDK podrá habilitar las categorías de indicadores incluidas en NativeAdContainerInfo. El SDK recibirá ese objeto cada vez que el estado del anuncio cambie de maneras relevantes para el SDK, por ejemplo en el caso de eventos facturables, como la impresión de anuncios y los clics de los usuarios.
Además, el publicador podrá agregar etiquetas específicas de la vista (Strings) a cada elemento secundario agregado a NativeAdContainer, que se pueden usar para permitir que el SDK sepa a qué recurso del anuncio corresponde cada elemento secundario.
Cuando el usuario haga clic en las vistas que son propiedad del SDK, la biblioteca de la IU reenviará el MotionEvent con propiedades traducidas al espacio de coordenadas del SDK, junto con el MotionEvent original. En versiones futuras de Android, exploraremos la forma de permitir que la aplicación cliente transfiera el enfoque táctil de todos los gestos del usuario en las partes que posea el SDK de este anuncio nativo que controlará el SDK.
Certificaciones
Las siguientes certificaciones estarán disponibles para el SDK para obtener garantías más sólidas sobre la presentación de los anuncios:
- Certificación de integridad del dispositivo: Usa las APIs de la plataforma, como la certificación de claves, para determinar la integridad del dispositivo.
- Identidad del APK: Usa las APIs de SdkSandbox, como
SdkSandboxController.getClientPackageName, y las de PackageManager, comorequestChecksum, para verificar la identidad del APK. VerifiedMotionEvents: En versiones futuras de Android, exploraremos la forma de permitir que la aplicación cliente transfiera el enfoque táctil de todos los gestos del usuario en las partes que posea el SDK de este anuncio nativo que controlará el SDK.MotionEventsse puede convertir enVerifiedMotionEventsusando las APIs del sistema. El SDK puede mostrar su propia IU en respuesta a la interacción del usuario si así lo desean.
Preguntas abiertas
Invitamos a que nos envíes comentarios sobre los siguientes puntos:
- ¿Es preferible que el SDK genere
VerifiedMotionEventspor su cuenta o que la biblioteca de IU del proveedor lo haga por el SDK? - ¿Es preferible que el SDK permita que el publicador posea vistas que contengan video o que sea el SDK el que las posea?
- ¿Qué propiedades deseas que se incluyan en el objeto
AppOwnedAdContainerInfo? - ¿Cuántos anuncios o componentes de anuncios del SDK esperas mostrar al mismo tiempo en la pantalla?