Vorschlag zum Design der SDK-Laufzeitsichtbarkeit

Anzeigen-SDKs in der SDK-Laufzeit können nicht auf die Ansichtshierarchie eines Publishers zugreifen. Stattdessen haben SDKs in der Laufzeit ihre eigenen Ansichten. Das SDK kann nicht dieselben View APIs wie außerhalb der SDK-Laufzeit verwenden, um zu bestimmen, ob die Anzeige für den Nutzer sichtbar ist, da die Anzeigenansicht nicht an das Anwendungsfenster angehängt ist. Dazu gehören Android View APIs wie getLocationOnScreen, getLocationInWindow oder getVisibility, die nicht die erwarteten Werte zurückgeben.

Die Unterstützung der Sichtbarkeitsmessung von Anzeigen ist eine der Hauptanforderungen an die SDK-Laufzeit. Mit diesem Designvorschlag sollen Open Measurement und ähnliche Messdienste unterstützt werden. Die hier beschriebenen Lösungen können auch für die Attribution Reporting APIs verwendet werden. Wir freuen uns über Ihr Feedback zu diesem Vorschlag.

Leistungsspektrum

Mit diesem Design können Anzeigen-SDKs oder Partner für Messungen die folgenden Sichtbarkeitsdaten berechnen (Namen sind vorläufig und können sich ändern):

Übersicht über die Sichtbarkeit der SDK-Laufzeit.

• viewport [Rect]: Zeigt den Gerätebildschirm oder die Geometrie des App-Fensters an, je nach den Funktionen der Plattform.
• uiContainerGeometry [Rect]: Die Geometrie des zu rendernden SandboxedSdkView.
• alpha [float]: Die Deckkraft des gerenderten SandboxedSdkView.
• onScreenGeometry [Rect]: Die Teilmenge von uiContainerGeometry, die bis einschließlich viewport nicht durch übergeordnete Ansichten abgeschnitten wird.
• occludedGeometry [Rect]: Die Teile von onScreenGeometry, die von Ansichten in der Anwendungshierarchie verdeckt werden. Enthält eine Rect für jede Verdeckung, die null, einer oder mehreren App-Ansichten entspricht, die sich mit SandboxedSdkView onScreenGeometry überschneiden

Voraussetzungen

• Die Werte für uiContainerGeometry, onScreenGeometry und occludedGeometry werden im Koordinatenraum von viewport ausgedrückt.
• Berichte zu Änderungen der Sichtbarkeit werden mit minimaler Latenz erstellt.
• Die Sichtbarkeit ist über den gesamten Lebenszyklus eines Anzeigenaufrufs – vom ersten bis zum letzten Aufruf – messbar.

Designvorschlag

Dieser Vorschlag baut auf der Funktionsweise der UI-Präsentation mit den UI-Bibliotheken von Client und Anbieter auf. Wir erweitern die UI-Bibliotheken, damit das SDK einen oder mehrere Beobachter der UI-Sitzung registrieren kann. Der Beobachter erhält Informationen zur Sichtbarkeit, wenn relevante Ereignisse erkannt werden, durch die die Datentypen im Abschnitt capabilities geändert werden. Mit Measurement SDKs in der SDK-Laufzeit (OMID- und MRAID-Implementierungen) kann dieser Beobachter an die UI-Sitzung angehängt werden, sodass die Informationen direkt an ihn gesendet werden können. Analysepartner können Informationen aus UI-Bibliotheken mit Daten zu Inhalten kombinieren, die bereits verfügbar sind (z. B. wenn Messskripts in das Anzeigen-Creative eingefügt werden), um JavaScript-Sichtbarkeitsereignisse zu generieren.

Ablauf für Sichtbarkeit steuern

Die Clientbibliothek überwacht Änderungen in der Anzeigen-UI mithilfe von Ereignis-Listenern wie ViewTreeObserver. Wird festgestellt, dass sich die Anzeigen-UI auf eine Weise geändert hat, die sich auf die Sichtbarkeitsmessung auswirken könnte, prüft die Clientbibliothek, wann die letzte Benachrichtigung an den Beobachter gesendet wurde. Wenn die letzte Aktualisierung die zulässige Latenz überschreitet (vom SDK konfigurierbar, bis zu mindestens 200 ms auf Mobilgeräten), wird ein neues AdContainerInfo-Objekt erstellt und eine Benachrichtigung an den Beobachter gesendet. Dieses ereignisbasierte Modell eignet sich besser für den Systemzustand als das Abfragen, das derzeit von den meisten OMID-Implementierungen unter Android durchgeführt wird.

API

Der Bibliothek „privacysandbox.ui.core“ wird Folgendes hinzugefügt:

• SessionObserver: Wird normalerweise vom SDK für Messungen implementiert und an die Sitzung angehängt, die vom SDK über privacysandbox.ui zurückgegeben wird. Über diese Schnittstelle können über das Measurement SDK auch bestimmte Kategorien von Sichtbarkeitssignalen aktiviert werden. Dadurch wiederum kann die UI-Clientbibliothek nur Signale erfassen, an denen der Beobachter interessiert ist, was für den Systemzustand insgesamt besser ist.
• registerObserver(): Diese Methode wurde der Klasse Session hinzugefügt und ermöglicht es jedem, der Zugriff auf die Sitzung hat, einen Beobachter zu registrieren. Wenn der Beobachter nach dem Öffnen der UI-Sitzung registriert wird, erhält er sofort das im Cache gespeicherte AdContainerInfo. Wenn sie vor dem Öffnen der Sitzung registriert wurden, werden sie beim Öffnen der Sitzung AdContainerInfo gesendet.
• AdContainerInfo: Eine Klasse mit Getter, mit denen der Beobachter schreibgeschützte Anzeigencontainerinformationen für die im Abschnitt Funktionen oben aufgeführten Datentypen abrufen kann. Die Rückgabewerte dieser Getter entsprechen, sofern möglich, den parcelable Rückgabewerten vorhandener Getter in View und seinen abgeleiteten Klassen. Wenn der Anzeigencontainer mit Jetpack Compose erstellt wurde, werden die semantischen Eigenschaften des Containers angezeigt. Mit dieser Klasse können MRAID- und OMID-Ereignisse im Zusammenhang mit der Sichtbarkeit berechnet werden.
• SessionObserverotifyAdContainerChanged(): Wird verwendet, um den Beobachter zu benachrichtigen, wenn sich die Sichtbarkeit ändert. Sie übergibt ein AdContainerInfo-Objekt. Dies wird immer dann aufgerufen, wenn Ereignisse erkannt werden, die sich auf die im Abschnitt „Funktionen“ aufgeführten Datentypen auswirken. Hinweis: Diese Methode kann zusätzlich zu den Methoden für „Session“ aufgerufen werden. Beispielsweise wird Session.notifyResized() aufgerufen, um das SDK anzufordern, die Größe der Anzeige anzupassen. In diesem Fall wird auch SessionObserver.notifyAdContainerChanged() aufgerufen.
• SessionObserverotifySessionClosed(): Teilt dem Beobachter mit, dass die Sitzung beendet wurde.

Hinweis: Die Lebensdauer von SessionObserver ist an die Sitzung der Sitzung gebunden. Wenn die Sitzung geschlossen ist, empfängt SessionObserver einen notifySessionClosed()-Aufruf und es werden keine weiteren Methoden an ihn gesendet. Da die Sitzung über das SDK des UI-Anbieters oder wenn das SandboxedSdkView vom Fenster der Publisher-App getrennt wird, muss das SDK für die Messung zwischen der UI-Sitzung und der Anzeigensitzung unterscheiden können. Die Anzeige kann bei mehreren Sitzungen erscheinen. Wenn der Publisher beispielsweise keine Geräterotationen vornimmt, wird die Aktivität jedes Mal neu gestartet, wenn sich das Gerät dreht. Beim Löschen der Aktivität wird die SandboxedSdkView vom Fenster getrennt und die UI-Sitzung geschlossen. Wenn der Publisher den UI-Adapter nach Aktivitätsneustarts speichert, kann er denselben Adapter möglicherweise an einen neuen SandboxedSdkView anhängen und eine neue Sitzung öffnen, nachdem die Aktivität begonnen hat. Der Partner für die Messung hängt der neuen Sitzung einen Beobachter an und kann den mit einer vorherigen Sitzung verknüpften Beobachter wiederverwenden, um die Messung weiter fortzusetzen.

Zukünftige Verbesserungen

Jeder Code, der während des Anwendungsprozesses ausgeführt wird, einschließlich des Codes aus der Bibliothek „privacysandbox.ui.client“, kann bei einer Manipulation der Anwendung geändert werden. Daher ist jede Logik zur Signalerfassung, die im Anwendungsprozess ausgeführt wird, anfällig für Manipulationen durch Anwendungscode. Dies gilt auch für SDK-Code, der bereitgestellt wurde, bevor die Privacy Sandbox im Bewerbungsprozess ausgeführt wird. Die Signalerfassung durch die UI-Bibliothek verschlimmert die Sicherheitssituation daher nicht.

Außerdem kann für den Code in der SDK-Laufzeit eine Plattform-API namens setTrustedPresentationCallback verwendet werden, die das Framework für die Darstellung der Anzeigen-UI stärkere Garantien bietet. setTrustedPresentationCallback arbeitet auf Oberflächenebene und kann Angaben zur Oberfläche machen, die die Anzeigen-UI enthält. Dazu werden Mindestgrenzwerte für die Präsentation angegeben, z. B. der Prozentsatz der sichtbaren Pixel, die Zeit auf dem Bildschirm oder die Skalierung. Diese Daten können mit den Sichtbarkeitsdaten abgeglichen werden, die von der UI-Clientbibliothek bereitgestellt werden (siehe oben). Da die vom Framework bereitgestellten Daten zuverlässiger sind, können alle Ereignisse aus der UI-Bibliothek, deren Daten nicht mit Daten aus dem Framework übereinstimmen, verworfen werden. Wenn beispielsweise der für setTrustedPresentationCallback bereitgestellte Listener mit einer Benachrichtigung aufgerufen wird, dass keine Pixel der Anzeigen-UI auf dem Bildschirm zu sehen sind, und die Client-UI-Bibliothek auf dem Bildschirm eine Anzahl von Pixeln ungleich null anzeigt, können die Daten von letzterem verworfen werden.

Offene Fragen

Wir bitten Sie um Feedback zu den folgenden Punkten:

1. Welche Sichtbarkeitssignale interessieren Sie sich, die in dieser Erläuterung nicht erwähnt werden?
2. Der aktuelle Vorschlag sieht vor, die Sichtbarkeit mindestens alle 200 Millisekunden zu aktualisieren, sofern eine relevante Änderung an der Benutzeroberfläche vorgenommen wird. Ist diese Häufigkeit für Sie akzeptabel? Wenn nicht, welche Häufigkeit würden Sie bevorzugen?
3. Bevorzugen Sie es, die Informationen aus setTrustedPresentationCallback selbst zu analysieren oder wenn die UI-Bibliothek des Anbieters Daten aus der Clientbibliothek löscht, wenn sie nicht mit den setTrustedPresentationCallback-Daten übereinstimmen?
4. Wie werden Sichtbarkeitssignale genutzt? Geben Sie uns Feedback, das diese Fragen beantwortet, damit wir Ihre Anwendungsfälle besser verstehen können.