Native Anzeigen auf Android-Geräten

Mit dem Format „Native Anzeigen“ kann der Publisher eine Anzeige anpassen, die einem Nutzer präsentiert wird. Nachdem Publisher eine Anzeige aus dem SDK abgerufen haben, können sie das Layout und die Darstellung der Anzeige ändern, um sie besser an die Benutzeroberfläche der Anwendung anzupassen. Dazu können sie beispielsweise einen Farbfilter hinzufügen, die Typografie ändern und benutzerdefinierte Overlays einfügen. Um die Leistung oder Nutzerfreundlichkeit von nativen Anzeigen zu optimieren, legen Publisher häufig Anzeigelimits fest oder lagern die Videowiedergabe an das SDK aus. Schließlich können Publisher Ad-Click-Listener anpassen, um zusätzliche Ereignisse wie Aufwärtsswipes zu erfassen.

Für das Format „Native Anzeigen“ ist ein höheres Maß an Vertrauen in den Publisher erforderlich als für andere Anzeigenformate. SDKs sollen in der Regel Richtlinienverstöße erkennen und überprüfen, ob die dem Publisher bereitgestellten Anzeigeninhalte dem Nutzer präsentiert wurden.

Die Unterstützung von Banneranzeigen in der SDK-Laufzeit wird über die SurfaceControlViewHost API erreicht. So kann das SDK Benutzeroberflächenelemente aus dem SDK-Laufzeitprozess anzeigen, ohne dass sie von der Clientanwendung manipuliert werden. Verwenden Sie die SurfaceView-Modi „Z above“ oder „Z below“, um festzulegen, ob sich die Oberfläche, auf der die SDK-Benutzeroberfläche gerendert wird, über oder unter dem Fenster der Clientanwendung befindet. Wenn eine Anzeige im Z-above-Modus gerendert wird, empfängt das SDK MotionEvents durch Nutzerinteraktionen, aber die Ansichten der Clientanwendung sind nicht über der Anzeige sichtbar. Wenn eine Anzeige im Z-Below-Modus gerendert wird, zeigt die Anwendung ihre eigenen Ansichten über der Anzeige an. MotionEvents von Nutzerinteraktionen mit der Anzeige werden jedoch an die Anwendung und nicht an das SDK gesendet.

Die Jetpack-Bibliotheken privacysandbox.ui können vom SDK und vom Publisher verwendet werden, um eine UI-Sitzung einzurichten und aufrechtzuerhalten.

Anzeigencontainer der App

Wir haben einen Prototyp entwickelt, bei dem das SDK alle Ansichten einer nativen Anzeige (einschließlich der Overlays der Anwendung) verwaltet. Das war zwar möglich, führte aber zu Einschränkungen bei der Benutzeroberfläche und erhöhte die Komplexität der Integration mit dem SDK. Ein pragmatischerer Ansatz besteht darin, die meisten Ansichten der Anwendung zu überlassen. Das SDK kann weiterhin selbst bestimmte UI-Elemente wie die Anzeigenansicht mit SandboxedSdkView aus privacysandbox.ui anzeigen. Dieser Ansatz bietet die größte Flexibilität bei der Unterstützung bestehender und zukünftiger Anwendungsfälle für dieses Anzeigenformat: Der App-Entwickler kann Anzeigenkomponenten verschieben und nach Bedarf gestalten, während das SDK bei Bedarf den Videoplayer behält und weiterhin auf die Media-Steuerelemente zugreifen kann.

Benachrichtigungen zum Anzeigenstatus

Verschiedene SDKs untersuchen unterschiedliche Eigenschaften von Anzeigenaufrufen, um Betrug und Richtlinienverstöße zu erkennen. Wir möchten dies unterstützen, ohne vorzuschreiben, welche Eigenschaften verwendet werden sollen, und ohne zum Engpass für das SDK zu werden, wenn sich die Menge der abgefragten Eigenschaften ändert. Wir schlagen vor, eine Darstellung des Anzeigencontainers und seiner untergeordneten Ansichten mit NativeAdContainerInfo zu erstellen. Dies ist ein parcelable-Objekt mit verschiedenen Gettern, die Informationen zum Anzeigencontainer und dessen Inhalt bereitstellen, sofern diese Informationen datenschutzfreundlich und nicht rechenintensiv sind. Das SDK kann Kategorien von Signalen aktivieren, die in NativeAdContainerInfo enthalten sind. Das SDK empfängt dieses Objekt immer dann, wenn sich der Anzeigenstatus in einer für das SDK relevanten Weise ändert, z. B. bei abrechenbaren Ereignissen wie Anzeigenimpressionen und Nutzerklicks.`

Außerdem kann der Publisher jedem untergeordneten Element, das NativeAdContainer hinzugefügt wird, ansichtsspezifische Tags (Strings) hinzufügen. So kann dem SDK mitgeteilt werden, zu welchem Anzeigen-Asset das jeweilige untergeordnete Element gehört.

Wenn der Nutzer auf Ansichten klickt, die zum SDK gehören, leitet die UI-Bibliothek das MotionEvent mit Eigenschaften, die in den Koordinatenraum des SDK übersetzt wurden, zusammen mit dem ursprünglichen MotionEvent an das SDK weiter. Für zukünftige Android-Versionen prüfen wir, ob wir die Möglichkeit hinzufügen können, dass die Clientanwendung den Fokus für alle Nutzeraktionen in den SDK-eigenen Teilen dieser nativen Anzeige an das SDK überträgt.

Bestätigung

Die folgenden Attestierungen sind für das SDK verfügbar, um die Zusicherung der Anzeigenpräsentation zu verbessern:

1. Geräteintegritätsattestierung: Verwenden Sie Plattform-APIs wie Key Attestation, um die Geräteintegrität zu ermitteln.
2. APK-Identität: Verwenden Sie SdkSandbox-APIs wie SdkSandboxController.getClientPackageName und PackageManager-APIs wie requestChecksum, um die APK-Identität zu bestätigen.
3. VerifiedMotionEvents: In zukünftigen Android-Versionen wird untersucht, ob die Clientanwendung den Touch-Fokus für alle Nutzergesten in den SDK-eigenen Teilen dieser nativen Anzeige an das SDK übertragen kann. MotionEvents kann mithilfe von System-APIs in VerifiedMotionEvents umgewandelt werden. Das SDK kann als Reaktion auf Nutzerinteraktionen eine eigene Benutzeroberfläche anzeigen, wenn es so konfiguriert ist.

Offene Fragen

1. Ist es besser, wenn das SDK VerifiedMotionEvents selbst generiert oder wenn die UI-Bibliothek des Anbieters dies für das SDK übernimmt?
2. Ist es besser, wenn der Publisher Ansichten mit Videoinhalten besitzt oder wenn das SDK diese Ansichten besitzt?
3. Welche Eigenschaften sollen in das AppOwnedAdContainerInfo-Objekt aufgenommen werden?
4. Wie viele SDK-eigene Anzeigen oder Anzeigenkomponenten werden voraussichtlich gleichzeitig auf dem Bildschirm angezeigt?