Mit dem nativen Anzeigenformat kann der Publisher eine Anzeige anpassen, die einem Nutzer präsentiert wird. Nachdem eine Anzeige aus dem SDK abgerufen wurde, können Publisher das Layout und das Erscheinungsbild der Anzeige ändern, damit sie besser zur Benutzeroberfläche der App passt. Dazu können sie einen Farbfilter hinzufügen, die Typografie ändern und benutzerdefinierte Overlays hinzufügen. Um die Leistung oder Nutzerfreundlichkeit von nativen Anzeigen zu optimieren, legen Publisher häufig Auslieferungslimits fest oder übergeben die Videowiedergabe an das SDK. Außerdem können Publisher Listener für Anzeigenklicks anpassen, um zusätzliche Ereignisse wie Wischen nach oben zu erfassen.
Für das native Anzeigenformat ist ein höheres Maß an Vertrauen in den Publisher erforderlich als für die Auslieferung anderer Anzeigenformate. Mit SDKs sollen in der Regel Richtlinienverstöße erkannt und überprüft werden, ob die dem Publisher bereitgestellten Anzeigeninhalte dem Nutzer präsentiert wurden.
Die Unterstützung von Banneranzeigen in der SDK-Laufzeit erfolgt über die SurfaceControlViewHost API. So kann das SDK Benutzeroberflächenelemente aus dem SDK-Laufzeitprozess anzeigen, ohne dass sie von der Clientanwendung manipuliert werden. Mit den Modi „SurfaceView Z above“ oder „SurfaceView Z below“ können Sie festlegen, ob die Oberfläche, auf der die SDK-Benutzeroberfläche gerendert wird, über oder unter dem Fenster der Clientanwendung angezeigt wird. Wenn eine Anzeige mit dem Modus „Z oben“ gerendert wird, erhält das SDK MotionEvents durch die Nutzerinteraktion, aber die Ansichten der Clientanwendung sind nicht über der Anzeige zu sehen. Wenn eine Anzeige im Modus „Z darunter“ gerendert wird, zeigt die App eigene Ansichten über der Anzeige an. MotionEvents Interaktionen der Nutzer mit der Anzeige werden jedoch an die App 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.
Von der App gehosteter Anzeigencontainer
Wir haben einen Prototyp erstellt, bei dem dem SDK alle Ansichten zugewiesen wurden, die eine native Anzeige enthalten (einschließlich der Overlays der Anwendung). Dabei haben wir festgestellt, dass dies zwar möglich ist, aber einige Einschränkungen für die Benutzeroberfläche mit sich bringt und die Integration mit dem SDK erschwert. Ein pragmatischerer Ansatz besteht darin, der Anwendung die meisten Ansichten zuzuweisen. Das SDK kann weiterhin einige UI-Elemente wie die Anzeigenansicht mithilfe von 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: Mit diesem Ansatz kann der App-Entwickler Anzeigenkomponenten nach Bedarf verschieben und stylen. Das SDK behält dabei die Inhaberschaft des Videoplayers bei, sofern gewünscht, und den Zugriff auf die Mediensteuerung.
Benachrichtigungen zum Anzeigenstatus
Unterschiedliche SDKs prüfen unterschiedliche Eigenschaften von Anzeigenaufrufen, um Betrug und Richtlinienverstöße zu erkennen. Wir möchten diese Funktion unterstützen, ohne vorschreiben zu müssen, welche Properties verwendet werden sollen, oder das SDK zum Engpass zu machen, wenn die abgefragten Properties geändert werden. Wir empfehlen, eine Darstellung des Anzeigencontainers und seiner untergeordneten Ansichten mit NativeAdContainerInfo zu erstellen. Es handelt sich dabei um ein teilbares Objekt mit verschiedenen Gettern, die Informationen nur zum Anzeigencontainer und seinem Inhalt offenlegen. Diese Informationen sind datenschutzfreundlich und die Berechnung ist nicht teuer. Über das SDK können Kategorien von Signalen aktiviert werden, die in NativeAdContainerInfo enthalten sind. Das SDK empfängt dieses Objekt immer dann, wenn sich der Anzeigenstatus auf eine für das SDK relevante 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. Damit kann das SDK erkennen, welchem Anzeigen-Asset jedes untergeordnete Element entspricht.
Wenn der Nutzer auf vom SDK verwaltete Ansichten klickt, leitet die UI-Bibliothek die MotionEvent mit Eigenschaften, die in den Koordinatenraum des SDKs übersetzt wurden, zusammen mit dem ursprünglichen MotionEvent an das SDK weiter. Für zukünftige Versionen von Android prüfen wir, ob die Clientanwendung den Touch-Eingabefokus für alle Nutzergesten auf die SDK-eigenen Teile dieser nativen Anzeige übertragen kann, damit sie vom SDK verarbeitet werden.
Bestätigung
Für das SDK sind die folgenden Attestationen verfügbar, um die Anzeigenbereitstellung noch sicherer zu machen:
- Attestierung der Geräteintegrität: Verwenden Sie Plattform-APIs wie die Schlüsselattestierung, um die Geräteintegrität zu bestimmen.
- APK-Identität: Verwenden Sie SdkSandbox APIs wie
SdkSandboxController.getClientPackageNameund PackageManager APIs wierequestChecksum, um die APK-Identität zu überprüfen. VerifiedMotionEvents: In zukünftigen Android-Versionen prüfen wir, ob die Clientanwendung den Touch-Eingabefokus für alle Nutzergesten auf die SDK-eigenen Teile dieser nativen Anzeige übertragen kann, damit sie vom SDK verarbeitet werden.MotionEventskann mithilfe von System-APIs inVerifiedMotionEventsumgewandelt werden. Das SDK kann auf Nutzerinteraktionen reagieren und eine eigene Benutzeroberfläche anzeigen.
Offene Fragen
- Sollte das SDK
VerifiedMotionEventsselbst generieren oder sollte das über die Anbieter-UI-Bibliothek für das SDK geschehen? - Sollten die Aufrufe mit Video dem Publisher gehören oder dem SDK?
- Welche Properties sollen im
AppOwnedAdContainerInfo-Objekt enthalten sein? - Wie viele Anzeigen oder Anzeigenkomponenten, die dem SDK gehören, werden voraussichtlich gleichzeitig auf dem Bildschirm eingeblendet?