Native Anzeigen auf Android-Geräten

Hinweis: Die Privacy Sandbox für Android ist ein fortlaufendes Projekt. Dieses Dokument spiegelt das aktuelle Design wider. Ihr Feedback ist wichtig für die Weiterentwicklung und Verbesserung der Funktionen.

Mit dem nativen Anzeigenformat kann der Publisher eine Anzeige anpassen, die einem Nutzer präsentiert wird. Nach dem Abrufen einer Anzeige aus dem SDK können Publisher das Layout ändern. und Aussehen der Anzeige an die Benutzeroberfläche der App anpassen: Farbfilter ändern, Typografie ändern und benutzerdefinierte Overlays hinzufügen. Zur Optimierung der Leistung oder Nutzererfahrung nativer Anzeigen zu verbessern, legen Publisher oft fest, beschränkt oder verlagert die Videowiedergabe in das SDK. Schließlich können Verlage und Webpublisher Anzeigenklick-Listener zur Überwachung auf zusätzliche Ereignisse wie Nach-oben-Wischen.

Das Format nativer Anzeigen erfordert ein größeres Vertrauen beim Publisher als die für die Schaltung anderer Anzeigenformate benötigt werden. 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 während 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 oben oder Z unten lässt sich bestimmen, Ob sich die Oberfläche, auf der die SDK-UI gerendert wird, über oder unter dem Client befindet Anwendungsfensters öffnen. Wenn eine Anzeige mit dem Modus „Z über“ gerendert wird, erhält das SDK MotionEvents von der Nutzerinteraktion, aber die Ansichten der Clientanwendung sind nicht über der Anzeige sichtbar. 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 herzustellen und aufrechtzuerhalten.

Von der App gehosteter Anzeigencontainer

Wir haben einen Prototyp entwickelt, über den das SDK Inhaber aller Aufrufe einer nativen Anzeige (einschließlich der Overlays der Anwendung) und fanden heraus, dass sie zwar durchführbar, Einschränkungen in der Benutzeroberfläche und die Integration des SDK wurde vereinfacht. Ein pragmatischer 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 gestalten. Das SDK behält dabei die Inhaberschaft des Videoplayers bei, sofern gewünscht, und den Zugriff auf die Mediensteuerung.

Vorgeschlagener Ablauf für die Steuerung nativer Anzeigen

.

Benachrichtigungen zum Anzeigenstatus

Verschiedene SDKs analysieren verschiedene Eigenschaften von Anzeigenaufrufen, Richtlinienverstöße. Wir würden dies gerne unterstützen, ohne zu verschreiben, oder zum Engpass für das SDK führen, abgefragten Eigenschaften. Wir empfehlen, eine Darstellung des Anzeigencontainers und seiner untergeordneten Ansichten mit NativeAdContainerInfo zu erstellen. Dies ist ein parzellell -Objekt, bei dem verschiedene Getter Informationen offenlegen, die auf den Anzeigencontainer beschränkt sind enthalten, wo diese Informationen datenschutzfreundlich sind Compute: Das SDK kann Kategorien von Signalen aktivieren, die in NativeAdContainerInfo Das SDK empfängt dieses Objekt, wenn der Anzeigenstatus Änderungen in einer Weise, die für das SDK relevant ist, z. B. abrechenbare Ereignisse 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 es Möglichkeiten geben sollte, dass die Clientanwendung den Touch-Eingabefokus für alle Nutzergesten auf die SDK-eigenen Teile dieser nativen Anzeige überträgt, damit sie vom SDK verarbeitet werden.

Bestätigung

Für das SDK sind die folgenden Attestierungen verfügbar, um die Anzeigenbereitstellung noch sicherer zu machen:

1. Attestierung der Geräteintegrität: Verwenden Sie Plattform-APIs wie die Schlüsselattestierung, um die Geräteintegrität zu bestimmen.
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: Auf zukünftigen Android-Versionen Ermöglicht der Clientanwendung, Touchfokus für alle Nutzer zu übertragen Bewegungen für die SDK-eigenen Teile dieser nativen Anzeige, die vom SDK verarbeitet werden sollen. MotionEvents kann mithilfe von System-APIs in VerifiedMotionEvents konvertiert werden. Das SDK kann als Reaktion auf die Nutzerinteraktion eine eigene UI anzeigen, wenn sie auswählen.

Offene Fragen

Wir freuen uns auf Ihr Feedback zu den folgenden Punkten:

1. Sollte VerifiedMotionEvents vom SDK selbst generiert werden oder sollte das über die UI-Bibliothek des Anbieters für das SDK geschehen?
2. Sollten die Aufrufe mit Video dem Publisher gehören oder dem SDK?
3. Welche Properties sollen im AppOwnedAdContainerInfo-Objekt enthalten sein?
4. Wie viele SDK-eigene Anzeigen oder Anzeigenkomponenten erwarten Sie, gleichzeitig zu erscheinen? Zeit auf dem Bildschirm?