Annunci nativi su Android

Il formato degli annunci nativi consente al publisher di personalizzare un annuncio mostrato a un utente. Dopo aver recuperato un annuncio dall'SDK, i publisher possono modificare il layout e l'aspetto dell'annuncio in modo che sia più in linea con l'interfaccia utente dell'applicazione: aggiungendo un filtro di colore, modificando la tipografia e aggiungendo overlay personalizzati. Per ottimizzare il rendimento o l'esperienza utente degli annunci nativi, i publisher spesso impostano limiti di visualizzazione o scaricano la riproduzione video sull'SDK. Infine, gli editori possono personalizzare i listener dei clic sugli annunci per monitorare eventi aggiuntivi come i gesti verso l'alto.

Il formato degli annunci nativi richiede un livello di attendibilità del publisher superiore rispetto a quello necessario per la visualizzazione di altri formati degli annunci. In genere, gli SDK vogliono rilevare violazioni delle norme e verificare che i contenuti dell'annuncio forniti all'editore siano stati mostrati all'utente.

Il supporto degli annunci banner in SDK Runtime viene ottenuto tramite l'API SurfaceControlViewHost. In questo modo l'SDK può mostrare gli elementi dell'interfaccia utente del processo SDK Runtime senza che vengano manomessi dall'applicazione client. Utilizza le modalità Z sopra o Z sotto di SurfaceView per determinare se la superficie in cui viene visualizzata l'interfaccia utente dell'SDK si trova sopra o sotto la finestra dell'applicazione client. Quando un annuncio viene visualizzato utilizzando la modalità Z sopra, l'SDK riceve MotionEvents dall'interazione dell'utente, ma le visualizzazioni dell'applicazione client non sono visibili sull'annuncio. Quando un annuncio viene visualizzato in modalità Z sotto, l'applicazione mostra le proprie visualizzazioni sopra l'annuncio, ma MotionEvents dall'interazione dell'utente con l'annuncio vanno all'applicazione, non all'SDK.

Le librerie Jetpack privacysandbox.ui possono essere utilizzate dall'SDK e dal publisher per stabilire e mantenere una sessione dell'interfaccia utente.

Container degli annunci di proprietà dell'app

Abbiamo creato un prototipo che consentiva all'SDK di possedere tutte le visualizzazioni che compongono un annuncio nativo (inclusi gli overlay dell'applicazione) e abbiamo riscontrato che, sebbene fattibile, imponeva alcune limitazioni all'interfaccia utente e aumentava la complessità dell'integrazione con l'SDK. Un approccio più pragmatico è lasciare che l'applicazione possieda la maggior parte delle visualizzazioni. L'SDK può comunque scegliere di mostrare autonomamente alcune UI, come la visualizzazione dell'annuncio, utilizzando SandboxedSdkView da privacysandbox.ui. Questo approccio offre la massima flessibilità per quanto riguarda il supporto dei casi d'uso esistenti e futuri per questo formato dell'annuncio: con questo approccio, lo sviluppatore di app può spostare i componenti dell'annuncio e personalizzarli in base alle esigenze, mentre l'SDK mantiene la proprietà del video player, se preferisci, e l'accesso ai controlli multimediali.

Diagramma che mostra il flusso di dati tra il publisher e l'SDK.
Flusso di controllo degli annunci nativi proposto.

Notifiche sullo stato degli annunci

SDK diversi esaminano proprietà diverse delle visualizzazioni degli annunci per il rilevamento delle attività fraudolente e delle violazioni delle norme. Vorremmo supportare questa funzionalità senza prescrivere quali proprietà utilizzare o diventare il collo di bottiglia per l'SDK modificando l'insieme di proprietà sottoposte a query. Proponiamo di creare una rappresentazione del contenitore dell'annuncio e delle relative visualizzazioni secondarie utilizzando NativeAdContainerInfo. Si tratta di un oggetto parcellabile con vari getter che espongono informazioni limitate al contenitore dell'annuncio e ai suoi contenuti, in cui queste informazioni rispettano la privacy e non sono costose da calcolare. L'SDK potrà attivare le categorie di indicatori inclusi in NativeAdContainerInfo. L'SDK riceve questo oggetto ogni volta che lo stato dell'annuncio cambia in modo pertinente per l'SDK, ad esempio in caso di eventi fatturabili come le impressioni degli annunci e i clic degli utenti.

Inoltre, il publisher potrà aggiungere tag specifici per la visualizzazione (stringhe) a ogni elemento secondario aggiunto a NativeAdContainer, che possono essere utilizzati per comunicare all'SDK a quale asset annuncio corrisponde ogni elemento secondario.

Quando l'utente fa clic sulle visualizzazioni di proprietà dell'SDK, la libreria UI inoltra all'SDK il MotionEvent con le proprietà tradotte nello spazio delle coordinate dell'SDK, insieme al MotionEvent originale. Per le versioni future di Android, stiamo esplorando la possibilità di aggiungere modi per consentire all'applicazione client di trasferire l'attenzione tocco per tutti i gesti dell'utente sulle parti di questo annuncio nativo di proprietà dell'SDK in modo che vengano gestite dall'SDK.

Attestazione

Per l'SDK saranno disponibili le seguenti attestazioni per garantire maggiore sicurezza sulla presentazione degli annunci:

  1. Attestazione dell'integrità del dispositivo: utilizza le API di piattaforma come Attestazione di chiavi per determinare l'integrità del dispositivo.
  2. Identità APK: utilizza le API SdkSandbox come SdkSandboxController.getClientPackageName e le API PackageManager come requestChecksum per verificare l'identità dell'APK.
  3. VerifiedMotionEvents: nelle versioni future di Android, stiamo valutando la possibilità di consentire all'applicazione client di trasferire l'attenzione tocco per tutti i gesti dell'utente sulle parti di proprietà dell'SDK di questo annuncio nativo in modo che vengano gestite dall'SDK. MotionEvents può essere convertito in VerifiedMotionEvents utilizzando le API di sistema. L'SDK può mostrare la propria UI in risposta all'interazione dell'utente, se lo sceglie.

Domande aperte

  1. È preferibile che l'SDK generi VerifiedMotionEvents autonomamente o che sia la libreria UI del provider a farlo per l'SDK?
  2. È preferibile che l'SDK consenta al publisher di possedere le visualizzazioni contenenti video o di possedere queste visualizzazioni?
  3. Quali proprietà vuoi includere nell'oggetto AppOwnedAdContainerInfo?
  4. Quanti annunci o componenti dell'annuncio di proprietà dell'SDK prevedi di mostrare contemporaneamente sullo schermo?