Vorschlag zum Design der SDK-Laufzeitsichtbarkeit

Hinweis :Die Privacy Sandbox für Android ist ein fortlaufendes Projekt und in diesem Dokument wird das aktuelle Design der Anwendung beschrieben. Ihr Feedback ist wichtig für die Weiterentwicklung und Verbesserung der Funktionen.

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 verwenden, die außerhalb der SDK-Laufzeit verwendet werden, um zu bestimmen, ob die Anzeige für den Nutzer sichtbar ist, da der Anzeigen-View nicht am Fenster der Anwendung angehängt ist. Dazu gehören Android View APIs wie getLocationOnScreen, getLocationInWindow oder getVisibility, die nicht den erwarteten Wert zurückgeben. Werte.

Die Unterstützung der Messung der Sichtbarkeit von Anzeigen ist eine grundlegende Anforderung der SDK-Laufzeit. Dieser Designvorschlag zielt darauf ab, offene Analyse und ähnliche Messdienste. Die hier beschriebenen Lösungen können auch für die Attribution Reporting APIs gelten. Wir freuen uns über Ihr Feedback zu diesem Vorschlag.

Leistungsspektrum

Mit diesem Design sollen Anzeigen-SDKs oder Partner für Messungen dabei unterstützt werden, folgende Sichtbarkeitsdaten (Namen sind vorläufig und können sich ändern):

Übersicht über die Sichtbarkeit bei der SDK-Laufzeit

• viewport [Rect]: Stellt je nach den Funktionen der Plattform den Bildschirm des Geräts oder die Geometrie des App-Fensters dar.
• uiContainerGeometry [Rect]: Die Geometrie von SandboxedSdkView, die gerendert.
• alpha [float]: Die Deckkraft der gerenderten SandboxedSdkView.
• onScreenGeometry [Rect]: Die Teilmenge von uiContainerGeometry, die nicht durch Aufrufe der Eltern abgeschnitten, bis einschließlich viewport).
• occludedGeometry [Rect]: Die Teile des onScreenGeometry, die von Ansichten in der Hierarchie der Anwendung verdeckt werden. Enthält eine Rect für jede Okklusion, die null, eine oder mehrere App-Ansichten entspricht, die sich mit der SandboxedSdkView onScreenGeometry überschneiden.

Voraussetzungen

• Die Werte für uiContainerGeometry, onScreenGeometry und occludedGeometry werden im Koordinatenraum des viewport ausgedrückt.
• Berichte zu Sichtbarkeitsänderungen werden mit minimaler Latenz erstellt.
• Die Sichtbarkeit ist über den gesamten Lebenszyklus der Anzeigenansicht messbar, von der ersten bis zu ihrem letzten Aussehen.

Designvorschlag

Dieser Vorschlag basiert auf der Funktionsweise der UI-Darstellung mithilfe der UI-Bibliotheken von Kunden und Anbietern. Wir werden die UI-Bibliotheken erweitern, damit das SDK einen oder mehrere Beobachter der UI-Sitzung registrieren kann. Der Beobachter erhält bei relevanten Ereignissen, die die Datentypen in capabilities erkannt werden. Mess-SDKs in der SDK-Laufzeit (OMID- und MRAID-Implementierungen) können angehängt werden. an die UI-Sitzung senden, damit diese Informationen an ihn gesendet werden können, . Anbieter von Analysetools können Informationen aus UI-Bibliotheken mit Daten zu bereits verfügbaren Inhalten kombinieren (z. B. bei der Verwendung von Analysescripts, die in das Creative eingefügt werden), um JavaScript-Ereignisse zur Sichtbarkeit zu generieren.

Kontrollfluss für die Sichtbarkeit.

Die Clientbibliothek überwacht über Ereignislistener wie ViewTreeObserver Änderungen an der Anzeigen-Benutzeroberfläche. Wenn festgestellt wird, dass die Anzeigen-UI in einem wie sich das auf die Sichtbarkeit auswirken kann, wird in der Clientbibliothek geprüft, an den Beobachter gesendet wurde. Wenn die letzte Aktualisierung länger als die zulässige Latenz ist (über das SDK konfigurierbar, bis zu einem Minimum von 200 ms auf Mobilgeräten), wird ein neues AdContainerInfo-Objekt erstellt und eine Benachrichtigung an den Beobachter gesendet. Dieses ereignisbasierte Modell ist für die Systemintegrität besser als die Abfragen, die bei den meisten OMID-Implementierungen unter Android derzeit durchgeführt werden.

API

Der Bibliothek „privacysandbox.ui.core“ werden die folgenden Elemente hinzugefügt:

• SessionObserver: Normalerweise vom Measurement SDK implementiert, angehängt an die Sitzung, die vom SDK über privacysandbox.ui zurückgegeben wird. Dieses kann das Measurement SDK auch bestimmte Kategorien aktivieren, von Sichtbarkeitssignalen. Dadurch kann die UI-Clientbibliothek Signale erfassen, die für den Beobachter interessieren, Gesundheit im Allgemeinen.
• registerObserver(): Diese Methode wurde der Klasse Session hinzugefügt und ermöglicht es allen Personen mit Zugriff auf die Sitzung, einen Beobachter zu registrieren. Wenn der Beobachter werden nach dem Öffnen der UI-Sitzung registriert, werden sie an die zwischengespeicherte AdContainerInfo sofort. Wenn sie vor Beginn der Sitzung registriert werden, werden sie beim Öffnen der Sitzung an AdContainerInfo gesendet.
• AdContainerInfo: Eine Klasse mit Gettern, über die der Beobachter schreibgeschützte Anzeigencontainerinformationen für die Datentypen abrufen kann, die oben im Abschnitt Funktionen aufgeführt sind. Die Rückgabewerte dieser Getter entsprechen, wo möglich, den parzierbaren Rückgabewerten aus vorhandenen Getter für View und ihre abgeleiteten Klassen. Wurde der Anzeigencontainer erstellt, Jetpack Compose werden dadurch die semantischen Eigenschaften des Containers angezeigt. Dieses können MRAID- und OMID-Ereignisse mit Bezug zur Sichtbarkeit berechnet werden.
• SessionObserverotifyAdContainerChanged(): Wird verwendet, um den Beobachter zu benachrichtigen wenn sich die Sichtbarkeit ändert. Es wird ein AdContainerInfo-Objekt übergeben. Dies ist aufgerufen, wenn Ereignisse erkannt werden, die die in den Abschnitt „Funktionen“. Hinweis: Diese Methode kann zusätzlich zu Methoden auf „Sitzung“ aufgerufen werden. Wenn beispielsweise Session.notifyResized() aufgerufen wird, um das SDK aufzufordern, die Größe der Anzeige zu ändern, wird auch SessionObserver.notifyAdContainerChanged() aufgerufen.
• SessionObserverotifySessionClosed(): Benachrichtigt den Beobachter, dass die Sitzung geschlossen wurde.

Hinweis: Die Lebensdauer von SessionObserver ist an die der Sitzung gebunden. Wenn die Sitzung geschlossen wird, erhält die SessionObserver einen notifySessionClosed()-Aufruf und es werden keine weiteren Methoden an sie gesendet. Da die Sitzung vom UI-Anbieter-SDK geschlossen werden kann oder wenn die SandboxedSdkView vom Fenster der Publisher-App getrennt wird, muss das Analyse-SDK zwischen der UI-Sitzung und der Anzeigensitzung unterscheiden. Möglicherweise gibt es mehrere Sitzungen umfassen, in denen die Anzeige ausgeliefert wird. Wenn der Publisher beispielsweise keine Gerätedrehung verarbeitet, wird die Aktivität jedes Mal neu gestartet, wenn das Gerät gedreht wird. Wenn die Aktivität gelöscht wird, wird der SandboxedSdkView vom Fenster getrennt und die UI-Sitzung wurde geschlossen. Wenn der Publisher den UI-Adapter bei jedem Neustart der Aktivität speichert, kann er denselben Adapter an eine neue SandboxedSdkView anhängen und nach Beginn der Aktivität eine neue Sitzung öffnen. Der Partner für die Messung kann einen Beobachter an die neue Sitzung. Möglicherweise wird der Beobachter wiederverwendet, der mit einer vorherigen Sitzung verknüpft ist. für eine kontinuierliche Messung.

Zukünftige Verbesserungen

Jeder Code, der während des Anwendungsprozesses ausgeführt wird, einschließlich des Codes der privacysandbox.ui.client kann geändert werden, wenn die Anwendung kompromittiert wurden. 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 vor der Verfügbarkeit der Privacy Sandbox bereitgestellt wurde und im Anwendungsvorgang ausgeführt wird. Die Signalerfassung durch die UI-Bibliothek verschlechtert die Sicherheitssituation daher nicht.

Außerdem kann Code in der SDK-Laufzeit eine Plattform-API namens setTrustedPresentationCallback verwenden, die dem Framework stärkere Garantien für die Darstellung der Anzeigen-UI bietet. setTrustedPresentationCallback auf Oberflächenebene und kann dabei helfen, Aussagen die die Anzeigen-UI enthalten, indem Sie Mindestgrenzwerte für die Präsentation festlegen, z. B. Prozentsatz der sichtbaren Pixel, der Zeit auf dem Bildschirm oder der Skalierung. Diese Daten können mit den Daten zur Sichtbarkeit verglichen werden, die von der UI-Clientbibliothek bereitgestellt werden (siehe oben). Da die vom Framework bereitgestellten Daten zuverlässiger sind, werden alle Ereignisse aus dem UI-Bibliothek, deren Daten nicht mit Daten aus dem Framework übereinstimmen, verworfen. Wenn z. B. der Listener für setTrustedPresentationCallback wird mit einer Benachrichtigung aufgerufen, dass keine Pixel vorhanden sind. der Anzeigen-UI auf dem Bildschirm zu sehen sind und die Client-UI-Bibliothek Pixel auf dem Bildschirm nicht null enthalten, können Daten dieser Werte verworfen werden.

Offene Fragen

Wir freuen uns auf Ihr Feedback zu den folgenden Punkten:

1. Welche Sichtbarkeitssignale sind für Sie interessant, die hier nicht erwähnt werden? erklären?
2. Der aktuelle Vorschlag besagt, die Sichtbarkeit nicht seltener als alle 200 Millisekunden, sofern eine relevante Änderung in der Benutzeroberfläche erfolgt. Ist diese Häufigkeit für Sie akzeptabel? Wenn nicht, welche Häufigkeit bevorzugen Sie?
3. Möchten Sie Informationen aus setTrustedPresentationCallback selbst analysieren oder sollen Daten aus der Client-UI-Bibliothek von der Anbieter-UI-Bibliothek gelöscht werden, wenn sie nicht mit setTrustedPresentationCallback-Daten übereinstimmen?
4. Wie werden Sichtbarkeitssignale verwendet? Helfen Sie uns, Ihre Anwendungsfälle zu verstehen, indem Sie Feedback geben, das diese Fragen beantwortet.