Annonces natives sur Android

Le format d'annonce native permet à l'éditeur de personnaliser une annonce présentée à un utilisateur. Après avoir récupéré une annonce à partir du SDK, les éditeurs peuvent modifier la mise en page et l'apparence de l'annonce pour mieux l'adapter à l'interface utilisateur de l'application : ajout d'un filtre de couleur, modification de la typographie et ajout de superpositions personnalisées. Pour optimiser les performances ou l'expérience utilisateur des annonces natives, les éditeurs définissent souvent des limites d'affichage ou déchargent la lecture des vidéos dans le SDK. Enfin, les éditeurs peuvent personnaliser les écouteurs de clics pour surveiller d'autres événements tels que les balayages vers le haut.

Le format d'annonce native nécessite un niveau de confiance plus élevé de la part de l'éditeur que ce qui est nécessaire pour afficher d'autres formats d'annonces. Les SDK souhaitent généralement détecter les cas de non-respect des règles et vérifier que le contenu d'annonce fourni à l'éditeur a été présenté à l'utilisateur.

Les bannières sont prises en charge dans le SDK Runtime via l'API SurfaceControlViewHost. Cela permet au SDK d'afficher les éléments d'interface utilisateur du processus du SDK Runtime sans que celui-ci ne soit altéré par l'application cliente. Utilisez les modes Z above (Au-dessus de l'axe Z) ou Z below (En dessous de l'axe Z) de SurfaceView pour déterminer si la surface où l'interface utilisateur du SDK est affichée se trouve au-dessus ou en dessous de la fenêtre de l'application cliente. Lorsqu'une annonce est affichée à l'aide du mode Z above (Au-dessus de l'axe Z), le SDK reçoit MotionEvents de l'interaction utilisateur, mais les vues de l'application cliente ne sont pas visibles par-dessus l'annonce. Lorsqu'une annonce est affichée à l'aide du mode Z below (En dessous de l'axe Z), l'application affiche ses propres vues au-dessus de l'annonce. Toutefois, l'élément MotionEvents de l'interaction utilisateur sur l'annonce est envoyé à l'application, et non au SDK.

Les bibliothèques Jetpack privacysandbox.ui peuvent être utilisées par le SDK et l'éditeur pour établir et maintenir une session d'interface utilisateur.

Conteneur d'annonces appartenant à l'application

Nous avons créé un prototype permettant au SDK de posséder toutes les vues comprenant une annonce native (y compris les superpositions de l'application) et nous avons constaté que même si cela était faisable, certaines restrictions s'appliquaient à l'interface utilisateur et l'intégration avec le SDK était plus complexe. Une approche plus pragmatique consiste à laisser l'application posséder la plupart des vues. Le SDK peut toujours afficher certains éléments de l'interface utilisateur, comme le visionnage de l'annonce, à l'aide de SandboxedSdkView depuis privacysandbox.ui. Cette approche offre une flexibilité optimale pour la prise en charge des cas d'utilisation existants et futurs de ce format d'annonce : avec cette approche, le développeur d'applications peut déplacer les composants d'annonce et en paramétrer le style selon les besoins, tandis que le SDK reste propriétaire du lecteur vidéo, s'il est privilégié, et conserve l'accès aux commandes multimédias.

Schéma illustrant la circulation des données entre l'éditeur et le SDK.
Suggestion de flux de contrôle des annonces natives

Notifications sur l'état des annonces

Les différents SDK examinent les différentes propriétés des visionnages d'annonces pour détecter les fraudes et les cas de non-respect des règles. Nous souhaitons faciliter ce processus sans indiquer au préalable les propriétés à utiliser ni devenir le goulot d'étranglement pour que le SDK modifie l'ensemble de propriétés interrogé. Nous proposons de créer une représentation du conteneur d'annonces et de ses vues enfants à l'aide de NativeAdContainerInfo. Il s'agira d'un objet parcelable avec plusieurs getters exposant des informations limitées au conteneur d'annonces et à son contenu, lorsque ces informations préservent la confidentialité et ne sont pas coûteuses à calculer. Le SDK pourra activer les catégories de signaux inclus dans NativeAdContainerInfo. Le SDK reçoit cet objet chaque fois que l'état de l'annonce change de manière pertinente pour le SDK, par exemple en cas d'événements facturables tels que les impressions d'annonces et les clics d'utilisateurs.

En outre, l'éditeur pourra ajouter des balises spécifiques à la vue (chaînes) à chaque enfant ajouté à NativeAdContainer, ce qui permettra d'indiquer au SDK à quel composant d'annonce correspond chaque enfant.

Lorsque l'utilisateur clique sur des vues appartenant au SDK, la bibliothèque d'UI transmet MotionEvent avec les propriétés traduites dans l'espace de coordonnées du SDK au SDK, avec l'élément MotionEvent d'origine. Pour les futures versions d'Android, nous étudions l'ajout de moyens permettant à l'application cliente de transférer le ciblage tactile de tous les gestes des utilisateurs sur les parties de cette annonce native appartenant au SDK qui seront gérées par le SDK.

Attestations

Les attestations suivantes seront disponibles pour le SDK afin de renforcer la présentation des annonces:

  1. Attestation d'intégrité de l'appareil : utilisez les API de la plate-forme, telles que Attestation de clé, pour déterminer l'intégrité de l'appareil.
  2. Identité des APK : vérifiez l'identité des APK à l'aide des API SdkSandbox comme SdkSandboxController.getClientPackageName et des API PackageManager comme requestChecksum.
  3. VerifiedMotionEvents : dans les futures versions d'Android, nous cherchons à permettre à l'application cliente de transférer le ciblage tactile de tous les gestes des utilisateurs sur les parties de cette annonce native appartenant au SDK qui seront gérées par le SDK. MotionEvents peut être converti en VerifiedMotionEvents à l'aide des API système. Le SDK peut afficher sa propre interface utilisateur en réponse à une interaction utilisateur s'il le souhaite.

Questions ouvertes

Nous vous invitons à nous envoyer vos commentaires sur les points suivants :

  1. Est-il préférable que le SDK génère lui-même VerifiedMotionEvents ou que la bibliothèque d'UI du fournisseur le fasse pour le SDK ?
  2. Est-il préférable que le SDK laisse l'éditeur posséder des vues contenant des vidéos ou qu'il les gère lui-même ?
  3. Quelles propriétés aimeriez-vous voir incluses dans l'objet AppOwnedAdContainerInfo ?
  4. Combien d'annonces ou de composants d'annonce appartenant au SDK prévoyez-vous d'afficher à l'écran en même temps ?