Beim Format „Native Anzeigen“ kann der Publisher eine Anzeige anpassen, die einem Nutzer. Nachdem eine Anzeige vom SDK abgerufen wurde, 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. SDKs möchten in der Regel Richtlinien erkennen und zu überprüfen, ob die dem Publisher zur Verfügung gestellten Anzeigeninhalte Nutzenden.
Die Unterstützung von Banneranzeigen während der SDK-Laufzeit erfolgt über die
SurfaceControlViewHost-API. So kann das SDK die Benutzeroberfläche
aus dem SDK-Laufzeitprozess, ohne dass diese durch den
Client-Anwendung. 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. Wird eine Anzeige im Z-oben-Modus gerendert,
empfängt MotionEvents aus Nutzerinteraktion, aber die Clientanwendung
Über der Anzeige sind keine Aufrufe zu sehen. Wenn eine Anzeige im Z-Unter-Modus gerendert wird,
App zeigt seine eigenen Aufrufe über der Anzeige an, aber MotionEvents durch den Nutzer
Interaktionen mit der Anzeige werden an die App und nicht an das SDK weitergeleitet.
Die Jetpack-Bibliotheken privacysandbox.ui können vom SDK und vom eine UI-Sitzung einzurichten und zu pflegen.
App-eigener 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 weiterer
Der pragmatische Ansatz besteht darin, der Anwendung die meisten Aufrufe zu überlassen. Das SDK kann immer noch
mit SandboxedSdkView bestimmte UI-Elemente selbst einblenden, z. B. die Anzeigenansicht
von privacysandbox.ui. Dieser Ansatz bietet die größte Flexibilität,
Vorhandene und zukünftige Anwendungsfälle für dieses Anzeigenformat werden unterstützt:
kann der App-Entwickler Anzeigenkomponenten verschieben und so gestalten,
erforderlich, während das SDK gegebenenfalls die Eigentumsrechte am Videoplayer behält, und
hat weiterhin Zugriff auf die Mediensteuerung.
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 schlagen vor, eine Darstellung des Anzeigencontainers zu erstellen,
und die zugehörigen untergeordneten Ansichten mit NativeAdContainerInfo. 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 ansichtsspezifische Tags (Strings) zu
Jedes untergeordnete Element, das „NativeAdContainer“ hinzugefügt wird, was verwendet werden kann, um das SDK zu informieren
welches Anzeigen-Asset die einzelnen untergeordneten Elemente haben.
Wenn der Nutzer auf SDK-eigene Ansichten klickt, leitet die UI-Bibliothek den
MotionEvent durch Attribute, die in den Koordinatenraum des SDKs für den
SDK zusammen mit dem ursprünglichen MotionEvent an. Für zukünftige Android-Versionen
Erkundigen Sie sich, wie Sie es der Client-Anwendung ermöglichen, Touch-Fokus
alle Nutzergesten auf die SDK-eigenen Teile dieser nativen Anzeige werden vom
SDK.
Bestätigung
Die folgenden Attestierungen werden dem SDK zur Verfügung gestellt, um stärker zu werden. Zusicherungen in Bezug auf die Anzeigenpräsentation:
- Geräteintegritätsattestierung: Verwenden Sie Plattform-APIs wie Key Attestierung zur Bestimmung der Geräteintegrität.
- APK-Identität: Verwenden Sie SdkSandbox-APIs wie
SdkSandboxController.getClientPackageNameund PackageManager APIs wierequestChecksum, um die APK-Identität zu bestätigen. 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.MotionEventskann mithilfe von System-APIs inVerifiedMotionEventskonvertiert werden. Das SDK kann als Reaktion auf die Nutzerinteraktion eine eigene UI anzeigen, wenn sie auswählen.
Offene Fragen
Wir freuen uns über Feedback zu den folgenden Punkten:
- Soll das SDK
VerifiedMotionEventslieber selbst generieren? oder die UI-Bibliothek des Anbieters für das SDK verwenden müssen? - Ist es besser, wenn das SDK dem Publisher eigene Ansichten mit oder selbst Inhaber dieser Aufrufe sind?
- Welche Unterkünfte sollten in der
AppOwnedAdContainerInfoObjekt? - Wie viele SDK-eigene Anzeigen oder Anzeigenkomponenten erwarten Sie, gleichzeitig zu erscheinen? Zeit auf dem Bildschirm?