Anúncios nativos no Android

Com o formato de anúncios nativos, o editor pode personalizar um anúncio que será exibido a um usuário. Depois de buscar um anúncio no SDK, os editores podem mudar o layout e a aparência dele para se alinhar melhor à interface do usuário do aplicativo: é possível adicionar um filtro de cores, mudar a tipografia e adicionar sobreposições personalizadas. Para otimizar a performance ou a experiência do usuário com anúncios nativos, os editores costumam definir limites de exibição ou descarregar a reprodução de vídeo no SDK. Por fim, os editores podem personalizar os listeners de clique no anúncio para monitorar outros eventos, como quando o usuário desliza para cima.

O formato de anúncios nativos requer um nível de confiança maior no editor do que o necessário para exibir outros formatos de anúncio. Normalmente, os SDKs buscam detectar violações de política e verificar se o conteúdo do anúncio fornecido ao editor foi exibido ao usuário.

O suporte para anúncios de banner no SDK Runtime é alcançado por meio da API SurfaceControlViewHost. Isso permite que o SDK mostre elementos da interface do usuário do processo do SDK Runtime sem que ele seja adulterado pelo aplicativo cliente. Use os modos "Z acima" ou "Z abaixo" de SurfaceView para determinar se a superfície em que a interface do SDK é renderizada está acima ou abaixo da janela do app cliente. Quando um anúncio é renderizado usando o modo Z acima, o SDK recebe MotionEvents da interação do usuário, mas as visualizações do aplicativo cliente não ficam visíveis sobre o anúncio. Quando um anúncio é renderizado no modo Z abaixo, o aplicativo mostra as próprias visualizações sobre o anúncio, mas MotionEvents da interação do usuário com o anúncio vai para o aplicativo, não para o SDK.

As bibliotecas do Jetpack privacysandbox.ui podem ser usadas pelo SDK e pelo editor para estabelecer e manter uma sessão da interface.

Contêiner de anúncios do app

Desenvolvemos um protótipo para permitir que o SDK tenha todas as visualizações do anúncio nativo (incluindo as sobreposições do aplicativo) e descobrimos que, embora viável, isso gerou algumas restrições na interface e aumentou a complexidade da integração com o SDK. Uma abordagem mais pragmática é permitir que o aplicativo tenha mais visualizações. O SDK ainda pode optar por mostrar alguma interface, como a visualização do anúncio, usando SandboxedSdkView de privacysandbox.ui. Essa abordagem oferece mais flexibilidade no suporte a casos de uso existentes e futuros para esse formato de anúncio. Com essa abordagem, o desenvolvedor de apps pode mover os componentes do anúncio e estilizá-los conforme necessário, enquanto o SDK mantém a propriedade do player de vídeo, se preferir, e o acesso aos controles de mídia.

Diagrama que mostra como os dados fluem entre o editor e o SDK.
Fluxo de controle proposto para anúncios nativos.

Notificações sobre o estado do anúncio

Diferentes SDKs verificam propriedades distintas das visualizações de anúncios para detectar fraudes e violações da política. Gostaríamos de oferecer esse suporte sem a necessidade de prescrever quais propriedades usar, ou criar um gargalo para o SDK mudar o conjunto de propriedades consultadas. Propomos a criação de uma representação do contêiner de anúncios e das visualizações filhas dele, usando NativeAdContainerInfo. Esse será um objeto fracionável com vários getters expondo informações limitadas ao contêiner de anúncios e ao conteúdo dele, em que essas informações preservam a privacidade e não têm um custo de cálculo alto. O SDK poderá ativar as categorias de indicadores incluídos em NativeAdContainerInfo. O SDK recebe esse objeto sempre que o estado do anúncio muda de maneira relevante, por exemplo, em eventos faturáveis, como impressões de anúncios e cliques do usuário.

Além disso, o editor poderá adicionar tags específicas da visualização (strings) a cada filho adicionado a NativeAdContainer. Elas podem ser usadas para permitir que o SDK saiba a que recurso de anúncio cada filho corresponde.

Quando o usuário clica em visualizações do SDK, a biblioteca da interface encaminha o MotionEvent com propriedades convertidas para o espaço de coordenadas do SDK, junto com o MotionEvent original. Em versões futuras do Android, estamos cogitando adicionar maneiras de permitir que o aplicativo cliente transfira o foco de toque de todos os gestos do usuário nas partes pertencentes ao SDK desse anúncio nativo a serem gerenciadas pelo SDK.

Declarações

As declarações a seguir vão estar disponíveis para o SDK para que você tenha garantias mais sólidas sobre a apresentação de anúncios:

  1. Declaração de integridade do dispositivo: use APIs da plataforma, como a Key Attestation, para determinar a integridade do dispositivo.
  2. Identidade do APK: use APIs do SdkSandbox, como SdkSandboxController.getClientPackageName, e APIs do PackageManager, como requestChecksum, para verificar a identidade do APK.
  3. VerifiedMotionEvents: em versões futuras do Android, estamos considerando permitir que o app cliente transfira o foco de toque de todos os gestos do usuário nas partes pertencentes ao SDK desse anúncio nativo a serem gerenciadas pelo SDK. MotionEvents podem ser convertidos em VerifiedMotionEvents usando APIs do sistema. Se preferir, o SDK pode mostrar a própria interface em resposta à interação do usuário.

Perguntas

  1. É preferível que o SDK gere VerifiedMotionEvents por conta própria ou que a biblioteca da interface do provedor faça isso para o SDK?
  2. É melhor que o SDK permita que o editor seja proprietário do vídeo que contém as visualizações ou das visualizações em si?
  3. Na sua opinião, quais propriedades deveriam ser incluídas no objeto AppOwnedAdContainerInfo?
  4. Quantos anúncios ou componentes de anúncio do SDK você espera mostrar ao mesmo tempo na tela?