Cenários de solução de problemas de atividades comuns ao vivo troubleshoot-mobile-live

Você pode usar o Assurance para verificar o registro do token:

1. No Assurance, na lista Eventos, filtre ou pesquise eventos eventType = "liveActivity.pushToStart".
2. Selecione o Evento e inspecione a carga.
3. Verifique se os valores token, appId e attributeType estão presentes.
4. Confirme se o evento foi enviado com êxito.

Também é possível fazer check-in do perfil do Adobe Experience Platform.

1. No Adobe Experience Platform, em seu Perfil, acesse a guia Eventos.
2. Pesquisar liveActivity.pushToStart eventos.
3. Verifique o carimbo de data e hora e a carga do evento.

Se nenhum evento for encontrado, o aplicativo não está chamando Messaging.registerLiveActivities corretamente. Corrija a integração do SDK.

1. Em seu Perfil, acesse a guia Atributos.

2. Localizar liveActivityPushNotificationDetails.

3. Verifique a configuração do token:

   code language-json
   { "liveActivityPushNotificationDetails": [ { "appId": "com.example.myapp", "token": "abc123def456...", "platform": "apns", "denylisted": false, "attributeType": "OrderTrackingAttributes", "identity": {} } ] }

Validar cada campo:

Se algum campo estiver incorreto, atualize o aplicativo móvel, registre-se novamente usando Messaging.registerLiveActivities, aguarde de 5 a 10 minutos e verifique novamente.

Se liveActivityPushNotificationDetails estiver ausente, o token ainda não foi sincronizado. Aguarde de 5 a 10 minutos após ver o evento liveActivity.pushToStart no Assurance e verifique novamente.

O Android usa o token de registro FCM padrão para atividades Live. Não há nenhum token de push de evento liveActivity.pushToStart ou atividade online separada.

1. No Assurance, abra a lista Eventos e localize o evento de registro de token de push padrão.
2. Selecione o evento e inspecione sua carga para verificar se o token de registro FCM está presente.
3. Confirme se o evento de registro foi enviado com êxito.
4. No Adobe Experience Platform, abra a guia Atributos do seu perfil e confirme se o token está presente em pushNotificationDetails, conforme descrito na etapa 2.

Se o evento de registro ou o token de perfil estiver ausente, verifique se o aplicativo encaminha o token de registro FCM para a SDK usando MobileCore.setPushIdentifier(token).

1. Em seu perfil, acesse a guia Atributos.

2. Localizar pushNotificationDetails. O Android usa este objeto em vez de liveActivityPushNotificationDetails e não requer um campo attributeType.

3. Verifique se a configuração do token segue essa estrutura:

   code language-json
   { "pushNotificationDetails": [ { "appId": "com.adobe.marketing.mobile.liveupdatessample", "token": "fcm-registration-token...", "platform": "fcm", "denylisted": false, "identity": {} } ] }

Validar cada campo:

Se algum campo estiver incorreto, corrija a configuração do aplicativo conforme necessário. Encaminhe o token FCM novamente usando MobileCore.setPushIdentifier(token), aguarde de 5 a 10 minutos e verifique o perfil novamente.

Se pushNotificationDetails estiver ausente, o token ainda não foi sincronizado. Depois de confirmar o registro do token no Assurance, aguarde de de 5 a 10 minutos e verifique novamente o perfil.

1. No Journey Optimizer, abra a Campanha e navegue até o menu Ações.
2. Verifique sua configuração de atividade do Live. A superfície deve ser configurada para o aplicativo iOS com um identificador de conjunto que corresponda a appId no liveActivityPushNotificationDetails do seu perfil. Por exemplo, se o seu perfil tem "appId": "com.example.myapp", a superfície deve ter como alvo o mesmo aplicativo.
3. Verifique se o Tipo de atividade na configuração da campanha corresponde exatamente ao attributeType no liveActivityPushNotificationDetails do seu perfil. Por exemplo, se o seu perfil tiver "attributeType": "FoodDeliveryLiveActivityAttributes", a campanha deverá especificar esse mesmo tipo de Atividade.

Ao executar a campanha via API, verifique se a carga segue a estrutura correta.

Carga unitária:

{
   "campaignId": "your-campaign-id",
   "recipients": [{
      "type": "aep",
      "userId": "user@example.com",
      "namespace": "email",
      "context": {
         "requestPayload": {
            "aps": {
               "content-available": 1,
               "timestamp": 1756984054,
               "event": "start",
               "attributes-type": "FoodDeliveryLiveActivityAttributes",
               "content-state": { ... },
               "attributes": { ... }
            }
         }
      }
   }]
}

Problemas comuns de carga:

Crítico: sempre usar um carimbo de data/hora novo

• Defina timestamp para o tempo de época Unix atual (em segundos) no momento em que você faz cada chamada de API. Isso se aplica a todos os tipos de evento: start, update e end.
• Um carimbo de data e hora obsoleto ou reutilizado faz com que as solicitações de atualização e encerramento falhem ou sejam ignoradas pelo dispositivo. não reutilize carimbos de data/hora de solicitações anteriores ou valores em cache.

Campos opcionais (todos os tipos de evento):

• requestId: Identificador exclusivo para rastreamento (recomendado).
• alert: Objeto com title e body para a notificação. Útil para chamar a atenção para atualizações.

Sobre dismissal-date:

• Opcional. Tempo da época Unix em segundos. Relevante somente quando event é "end".
• Especifica quando a atividade Live é removida automaticamente do dispositivo. Se você a omitir, a atividade Live permanecerá visível até que o usuário a ignore.
• Deve ser um carimbo de data/hora futuro posterior a timestamp.

Verifique se a carga da API corresponde à implementação ActivityAttributes do aplicativo iOS. O protocolo LiveActivityAttributes do Adobe SDK estende o iOS ActivityAttributes e requer uma propriedade liveActivityData.

Validar o mapeamento:

1. Seu ActivityAttributes deve implementar o protocolo LiveActivityAttributes da Adobe. Exemplo:

   code language-swift
   struct FoodDeliveryLiveActivityAttributes: LiveActivityAttributes { public struct ContentState: Codable, Hashable { var orderStatus: String var estimatedDeliveryTime: String } // Adobe SDK requirement var liveActivityData: LiveActivityData // Your custom attributes var restaurantName: String }

   Observe que o campo liveActivityData é exigido pelo Adobe SDK e deve ser incluído em todas as implementações.

2. A carga da API deve refletir a estrutura do iOS:

   code language-json
   { "aps": { "event": "start", "timestamp": 1756984054, "attributes-type": "FoodDeliveryLiveActivityAttributes", "content-state": { "orderStatus": "Preparing", "estimatedDeliveryTime": "20 mins" }, "attributes": { "liveActivityData": { "liveActivityID": "order-12345" }, "restaurantName": "Pizza Palace" } } }

Lista de verificação de validação:

• Incluir todos os campos ContentState em content-state (obrigatório para todos os tipos de evento).

• Incluir todos os campos LiveActivityAttributes em attributes (somente eventos iniciais), incluindo:

  • liveActivityData (obrigatório; geralmente contém liveActivityID ou identificador semelhante)
  • Todos os campos personalizados da estrutura

• Corresponder nomes de campo exatamente (diferencia maiúsculas de minúsculas).

• Corresponder tipos de dados (String, Int, Bool, objetos aninhados).

• Preserva a estrutura do objeto aninhado.

Erros comuns:

Para obter mais exemplos, consulte Criar página de atividade ao vivo.

Verifique a execução da API e o delivery de carga usando o Assurance:

1. Abra sua sessão do Assurance.

2. Execute a chamada de API para acionar a atividade Live.

3. Na Lista de Eventos, verifique se:

   • Eventos de execução de campanha.
   • Eventos de entrega de atividades online.
   • Eventos de erro de validação de carga.

4. Revise as cargas do evento para verificar:

   • A carga foi processada corretamente.
   • Não ocorreram erros de validação.
   • A atividade online foi enviada para APNs.

1. No Journey Optimizer, abra a Campanha e navegue até o menu Ações.
2. Verifique sua configuração de atividade do Live. A superfície deve direcionar o aplicativo Android com um nome de pacote que corresponda a appId no pushNotificationDetails do perfil.
3. Verifique se a superfície usa as credenciais do FCM para esse aplicativo. A plataforma de token do perfil deve ser "fcm".
4. Confirme se notification_channel_id na carga corresponde a um canal de notificação criado pelo aplicativo.

Coloque os campos de atividade do Android Live em context.requestPayload.fcm.

Carga de início unitário:

{
   "requestId": "your-request-id",
   "campaignId": "your-campaign-id",
   "recipients": [
      {
         "type": "aep",
         "userId": "your-device-ECID",
         "namespace": "ECID",
         "context": {
            "requestPayload": {
               "fcm": {
                  "notification_id": "flight-DL-321",
                  "timestamp": 1756984054,
                  "notification_channel_id": "live_updates_channel",
                  "priority": "PRIORITY_HIGH",
                  "event_type": "start",
                  "title": "Flight DL-321",
                  "body": "Boarding starts shortly",
                  "critical_text": "25 min",
                  "content_state": {
                     "custom_key_template_type": "progress",
                     "custom_key_journey_start": "DEL",
                     "custom_key_journey_progress": 10,
                     "custom_key_journey_end": "MUM"
                  }
               }
            }
         }
      }
   ]
}

Substitua o carimbo de data e hora de amostra pelo tempo da época Unix atual em segundos. As chaves content_state são exemplos e devem corresponder ao provedor de estilos do seu aplicativo.

Para transmissões, use uma campanha de Marketing acionada por API com audience.id e coloque o objeto fcm em context.requestPayload. Defina topic_name como o tópico FCM ao qual os dispositivos de destino fizeram assinatura. Mantenha o tópico e notification_id inalterados nos eventos de início, atualização e término. Veja os exemplos de carga de transmissão do Android.

Problemas comuns de carga:

Verificações de carimbo de data/hora e ciclo de vida:

• Use um novo timestamp em segundos da época para cada evento de início, atualização e término. Certifique-se de que ele seja maior que o valor anterior do mesmo notification_id (ou topic_name para transmissões), mesmo quando as solicitações forem feitas no mesmo segundo.
• Carimbos de data e hora mais antigos ou iguais são ignorados. Não reutilize carimbos de data e hora em cache.
• O campo when opcional controla a hora exibida da notificação, não a ordenação de mensagens. Mantenha-o razoavelmente atualizado e expresse-o em segundos da época.
• Para atualizar ou encerrar uma atividade, altere event_type mantendo notification_id inalterado. O Android usa o mesmo token de registro FCM para todos os três eventos do ciclo de vida; nenhum token de atualização separado é necessário.

Descarte de evento de fim:

Para event_type: "end", opcionalmente defina dismiss_after para o número de segundos que a atividade concluída em tempo real deve permanecer visível antes da remoção. Essa é uma duração, não um carimbo de data e hora de época.

O provedor de estilos do aplicativo determina como content_state valores são renderizados na notificação de atividade ao vivo.

1. Confirme se as Mensagens e a extensão Atividades ativas estão integradas no aplicativo.
2. Verifique se cada campo em content_state corresponde a uma chave manipulada pelo provedor de estilo, incluindo seu tipo de valor esperado.
3. Verifique se title, body e critical_text contêm o texto de exibição pretendido. critical_text é usado para o chip da barra de status.
4. Confirme se as permissões de notificação foram concedidas e se o canal identificado por notification_channel_id existe.

Erros comuns:

Para obter mais exemplos, consulte Criar atividades ao vivo.

Use o Assurance em um dispositivo de teste conectado do Android.

1. Abra uma sessão do Assurance e confirme se o registro do token FCM está visível.
2. Execute a chamada de API para iniciar a atividade Live e envie eventos de atualização e término com o mesmo notification_id e carimbos de data e hora crescentes.
3. Revise os eventos e as cargas do SDK disponíveis para erros de processamento ou validação. Confirme se a carga do Android usa fcm e os valores do ciclo de vida pretendidos.
4. Na guia Eventos do perfil, inspecione os message.feedback eventos correspondentes. Verifique se serviceProvider é fcm e confira feedbackStatus, errorCode e errorMessage as falhas de entrega.
5. Se a entrega for bem-sucedida, mas a atividade Live não for renderizada, inspecione os logs do aplicativo, os mapeamentos do provedor de estilo, as permissões de notificação e a configuração do canal no dispositivo.

Pule esta etapa se o relatório de campanha não mostrar erros de envio. Caso contrário, associe o erro da tabela Motivos de Erro aos seguintes erros comuns de APNs:

1. Navegue até Cliente > Perfis na Journey Optimizer.

2. Procure e abra o perfil.

3. Selecione a guia Eventos.

4. Filtrar ou pesquisar eventos com eventType = "message.feedback".

5. Procure eventos de feedback que correspondam aos tipos liveActivityID e event da atividade Ativa.

6. Revise os seguintes campos principais:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   Campo	Valores possíveis	O que significa
   feedbackStatus	sent, error, denylist	Resultado da entrega do provedor de serviços
   serviceProvider	apns/apnsSandbox	Deve ser APNs para atividades do iOS Live
   errorCode	Código numérico ou null	Código de erro específico de APNs em caso de falha
   errorMessage	Descrição de erro ou null	Mensagem de erro legível

7. Se feedbackStatus: "error":

   • Verifique se há erros de APNs específicos em errorCode e errorMessage.
   • Erros comuns de APNs incluem token expirado, certificado inválido, ID de pacote incorreta.

8. Se nenhum evento de comentários for encontrado:

   • A notificação por push pode não ter sido tentada.
   • Verifique se o perfil foi excluído no relatório de campanha.

Se feedbackStatus for sent: a Journey Optimizer enviou a notificação para APNs. Isso não confirma a renderização do dispositivo. Continue com as verificações do lado do dispositivo na etapa 4.

1. Abra sua sessão do Assurance e mantenha-a ativa durante a chamada de API.

2. Execute a chamada de API (start, update ou end).

3. Na Lista de Eventos, procure por eventos de entrega de atividades online.

4. Procure eventos relacionados à entrega por push de APNs.

5. Verifique os seguintes indicadores:

   • Solicitação de push para APNs: confirma que a Adobe enviou o push para os servidores da Apple
   • Resposta APNs: mostra se APNs aceitaram ou rejeitaram o push
   • Status da entrega: indicação de êxito ou falha

6. Se forem encontrados problemas, consulte os seguintes problemas comuns de delivery de APNs:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3
   Problema	Sintoma no Assurance	Resolução
   Certificado APNs expirado	Erro de autenticação	Renovar e carregar novo certificado APNs
   Ambiente errado (desenvolvimento vs. produção)	Erro de incompatibilidade de token	Verifique se o certificado corresponde ao tipo de build do aplicativo
   Incompatibilidade de ID do pacote	Identificador de conjunto inválido	Verificar se a ID do conjunto de certificados corresponde ao aplicativo
   Token expirado	Erro InvalidToken de APNs	Registrar tokens de atividade ao vivo novamente
   Limitação de taxa	Solicitações demais	Reduzir a frequência de chamada da API

Se o Adobe mostrar a entrega bem-sucedida, mas o dispositivo não mostrar a atividade Live:

• Verifique se há erros de atividade ao vivo nos logs de dispositivos do iOS.
• Verifique se o aplicativo está em primeiro ou segundo plano (não finalizado).
• Confirme se o dispositivo tem conectividade de rede.
• Teste em vários dispositivos para descartar problemas específicos do dispositivo.
• Verifique se a versão do iOS é 16.1 ou posterior.

Se você concluiu todas as etapas e o problema permanece não resolvido, entre em contato com o Atendimento ao cliente da Adobe com:

Informações necessárias:

• ID e nome da campanha
• Namespace e ID do perfil
• liveActivityID da carga da API
• Carimbos de data e hora de chamadas de API
• Capturas de tela do relatório de campanha que mostram estatísticas de envio, motivos de erro e motivos excluídos
• Eventos de perfil relevantes (liveActivity.updateToken para problemas unitários de atualização/encerramento e message.feedback)
• Detalhes da sessão do Assurance e capturas de tela de eventos relevantes
• Carga e resposta da solicitação de API, com credenciais e tokens de dispositivo redigidos
• Detalhes do certificado APNs (expiração, ambiente, ID do pacote)

Pule esta etapa se o relatório de campanha não mostrar erros de envio. Caso contrário, associe o erro da tabela Motivos do erro aos seguintes erros comuns do FCM:

1. Navegue até Cliente > Perfis na Journey Optimizer.

2. Procure e abra o perfil.

3. Selecione a guia Eventos.

4. Filtrar ou pesquisar eventos com eventType = "message.feedback".

5. Localize eventos de feedback para os carimbos de data e hora da campanha e da chamada de API que você está investigando.

6. Revise os seguintes campos principais:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   Campo	Valores possíveis	O que significa
   feedbackStatus	sent, error, denylist	Resultado da entrega do provedor de serviços
   serviceProvider	fcm	O FCM lidou com a entrega por push do Android
   errorCode	Código de erro do provedor ou null	Código de erro específico do FCM se a entrega falhar
   errorMessage	Descrição de erro ou null	Mensagem de erro legível

7. Se feedbackStatus: "error":

   • Inspecione errorCode e errorMessage e aplique a resolução FCM correspondente da etapa 1.

8. Se nenhum evento de comentários for encontrado:

   • A notificação por push pode não ter sido tentada ou o feedback pode ainda não estar disponível.
   • Verifique se o perfil foi excluído no relatório de campanha.

Se feedbackStatus for sent: o FCM aceitou a notificação. Isso não confirma se o dispositivo renderizou a atividade Live. Continue com as verificações do lado do dispositivo na etapa 4.

Use o Assurance em um dispositivo de teste conectado do Android.

1. Abra uma sessão do Assurance e mantenha-a ativa durante a chamada de API.
2. Executar a chamada de API com event_type definido como start, update ou end.
3. Na lista Eventos, inspecione os eventos de entrega por push disponíveis para verificar a solicitação para o FCM e sua resposta.
4. Verifique se o FCM aceitou ou rejeitou a solicitação e inspecione todos os detalhes de erro relatados.
5. Para solicitações rejeitadas, use os erros do FCM na etapa 1 para verificar o token, as credenciais do projeto do Firebase e a carga. Se os eventos do provedor não estiverem disponíveis na sessão, use message.feedback eventos e relatórios de campanha.

Se o Adobe exibir um delivery bem-sucedido, mas o dispositivo não exibir ou atualizar a atividade Live:

• Inspecione os logs do aplicativo do Android para verificar se há erros de processamento de atividades de push e Live.
• Confirme se as notificações são permitidas e se as notificações promovidas são permitidas usando canPostPromotedNotifications().
• Verifique se as permissões POST_NOTIFICATIONS e POST_PROMOTED_NOTIFICATIONS foram concedidas e se o canal identificado por notification_channel_id existe.
• Verifique se timestamp é mais recente que o último evento processado e se notification_id não foi alterado. Para transmissões, verifique também a assinatura do dispositivo para topic_name.
• Confirme se o aplicativo não foi interrompido à força.
• Confirme se o dispositivo tem conectividade de rede.
• Teste em vários dispositivos para descartar problemas específicos do dispositivo.
• Verifique se o dispositivo executa o Android 16.1 (nível de API 36.1) ou posterior e se o aplicativo usa targetSdk 36.
• Verifique se content_state chaves e tipos de valor correspondem ao provedor de estilo do aplicativo.

Se você concluiu todas as etapas e o problema permanece não resolvido, entre em contato com o Atendimento ao cliente da Adobe com:

Informações necessárias:

• ID e nome da campanha
• Namespace e ID do perfil
• notification_id e event_type da carga da API; para transmissões, também inclua topic_name e a ID de público
• Carimbos de data e hora de chamadas de API
• Capturas de tela do relatório de campanha que mostram estatísticas de envio, motivos de erro e motivos excluídos
• Eventos message.feedback de perfil relevantes, incluindo mensagens e códigos de erro do FCM
• Detalhes da sessão do Assurance e capturas de tela de eventos relevantes
• Carga e resposta da solicitação de API, com credenciais e tokens de dispositivo redigidos
• O nome do pacote do Android, o projeto Firebase, a ID do remetente e os detalhes de configuração da credencial do FCM; não inclua chaves privadas
• Versão do sistema operacional do Android, modelo do dispositivo, status de permissão de notificação e logs relevantes do aplicativo

1. Abra sua Campanha de Marketing Acionado pela API na Journey Optimizer.

2. Navegue até a seção Público-alvo e verifique:

   • Um público é selecionado para a campanha.
   • A ID de público-alvo corresponde à ID usada na carga da API.
   • O público-alvo contém os perfis esperados.

3. Navegue até a seção Ações.

4. Verifique a configuração da atividade online:

   • A configuração deve ser definida para o aplicativo iOS com o identificador de pacote correto.
   • O tipo de atividade deve corresponder ao attributes-type na carga da API. Por exemplo, se sua carga contém "attributes-type": "AirplaneTrackingAttributes", a campanha deve especificar esse mesmo tipo de Atividade.

A estrutura de carga da transmissão é diferente das campanhas unitárias. Verifique se a carga segue o formato de transmissão correto.

Campos obrigatórios para difusão:

{
   "campaignId": "878a11d4-b519-47bd-8313-fecfee19857b",
   "audience": {
      "id": "8c3dbdea-2957-401f-acf0-3966fba1601e"
   },
   "context": {
      "requestPayload": {
         "aps": {
            "input-push-channel": "FEt0NgvLEfEAAOqA6AXdIQ==",
            "content-available": 1,
            "timestamp": 1771829292,
            "event": "start",
            "attributes-type": "AirplaneTrackingAttributes",
            "content-state": { ... },
            "attributes": { ... }
         }
      }
   }
}

Problemas comuns de carga:

Campos críticos específicos da difusão:

• input-push-channel:

  • Obrigatório para todas as atividades de transmissão ao vivo.
  • Atua como um identificador exclusivo para essa instância de transmissão específica.
  • Todos os perfis no público-alvo recebem atividades ao vivo vinculadas a este canal.
  • Deve corresponder a channelID em liveActivityData.channelID (consulte a etapa 3).
  • Deve ser criado para o appID no Portal do Desenvolvedor do Apple pela sua equipe.
  • Somente os canais criados para o appID específico podem ser usados para transmitir a atividade em tempo real nesse aplicativo.

• audience.id:

  • Deve fazer referência a um segmento de público-alvo válido criado no Adobe Experience Platform.
  • Todos os perfis neste público-alvo são direcionados para a atividade Live.
  • O público deve ser ativado e conter perfis com liveActivityPushNotificationDetails válido.

Sempre usar o carimbo de data/hora mais recente:

• O campo timestamp deve ser sempre o tempo da época Unix atual (em segundos) para cada chamada de API.
• Este requisito se aplica a todos os tipos de evento: start, update e end.
• Crítico para atualizações/fim: usar carimbos de data/hora obsoletos faz com que as solicitações de atualização e término falhem.
• Gere um carimbo de data e hora novo para cada chamada de API de transmissão.

Campos opcionais:

• dismissal-date: Tempo de época Unix para descarte automático (relevante somente para end eventos)
• alert: Objeto com title e body para notificação

Consulte a documentação da API de Mensagens do Adobe Journey Optimizer para obter as especificações completas da API.

Verifique se os campos de carga correspondem à implementação ActivityAttributes do aplicativo iOS e se input-push-channel corresponde a channelID em liveActivityData.

1. Revise sua definição de Atributos da atividade do iOS.

Sua estrutura ActivityAttributes personalizada deve implementar o protocolo LiveActivityAttributes da Adobe:

struct AirplaneTrackingAttributes: LiveActivityAttributes {
   public struct ContentState: Codable, Hashable {
      var journeyProgress: Int
   }

   // Adobe SDK requirement
   var liveActivityData: LiveActivityData

   // Your custom attributes
   var arrivalAirport: String
   var departureAirport: String
   var arrivalTerminal: String
}

1. Mapeie os campos do iOS para a carga da API de transmissão.

Incluir content-state para todos os tipos de evento. Incluir attributes, incluindo liveActivityData.channelID, somente para eventos de início:

{
   "aps": {
      "input-push-channel": "FEt0NgvLEfEAAOqA6AXdIQ==",
      "event": "start",
      "timestamp": 1771829292,
      "attributes-type": "AirplaneTrackingAttributes",
      "content-state": {
         "journeyProgress": 0
      },
      "attributes": {
         "arrivalAirport": "DEL",
         "departureAirport": "MUM",
         "arrivalTerminal": "T1",
         "liveActivityData": {
            "channelID": "FEt0NgvLEfEAAOqA6AXdIQ=="
         }
      }
   }
}

Crítico: input-push-channel deve corresponder achannelID

• O valor input-push-channel na raiz de aps deve corresponder exatamente a channelID em liveActivityData.
• No exemplo acima, ambos os valores são "FEt0NgvLEfEAAOqA6AXdIQ==".
• Isso vincula a instância de transmissão aos dados de atividade Live.
• Uma incompatibilidade causa falhas de delivery.

Pontos principais de validação:

• Incluir todos os campos ContentState em content-state para todos os tipos de evento.
• Incluir todos os campos personalizados LiveActivityAttributes em attributes somente para eventos iniciais.
• Para eventos de início, liveActivityData.channelID deve corresponder a input-push-channel.
• Os nomes de campos diferenciam maiúsculas de minúsculas e devem corresponder exatamente.
• Os tipos de dados devem corresponder (String, Int, Bool, objetos aninhados etc.).
• Para eventos de atualização/encerramento, use o mesmo input-push-channel que o evento inicial original.

Erros comuns:

Verifique a execução da API e o delivery de carga usando o Assurance:

1. Abra a sessão do Assurance em um dispositivo de teste que faça parte do público-alvo.

2. Execute a chamada de API de transmissão.

3. Na Lista de Eventos, procure:

   • Eventos de execução de campanha.
   • Eventos de entrega de atividades online.
   • Eventos de erro que indicam falhas de validação de carga.

4. Inspecione as cargas do evento para confirmar:

   • A carga foi processada corretamente.
   • O input-push-channel está presente.
   • Não ocorreram erros de validação.
   • As atividades ativas foram enviadas para APNs para membros do público-alvo.

1. Abra sua campanha de Marketing acionada por API na Journey Optimizer.

2. Navegue até a seção Público-alvo e verifique:

   • Um público é selecionado para a campanha.
   • A ID de público-alvo corresponde à ID usada na carga da API.
   • O público-alvo contém os perfis esperados.

3. Navegue até a seção Ações.

4. Verifique se a Configuração da atividade online está direcionada ao pacote correto do Android e se usa as credenciais FCM correspondentes. A Android não usa um tipo de atividade ou campo attributes-type.

As transmissões do Android usam um tópico FCM. Inclua audience.id e coloque o objeto fcm em context.requestPayload, em vez de em um destinatário individual.

Exemplo de carga de início de transmissão:

{
   "requestId": "your-request-id",
   "campaignId": "your-marketing-campaign-id",
   "audience": {
      "id": "your-audience-id"
   },
   "context": {
      "requestPayload": {
         "fcm": {
            "topic_name": "flight_DL321",
            "notification_id": "flight-DL-321",
            "notification_channel_id": "live_updates_channel",
            "timestamp": 1771829292,
            "priority": "PRIORITY_HIGH",
            "event_type": "start",
            "title": "Flight DL-321",
            "body": "Boarding starts shortly",
            "critical_text": "25 min",
            "content_state": {
               "custom_key_template_type": "progress",
               "custom_key_journey_start": "DEL",
               "custom_key_journey_progress": 10,
               "custom_key_journey_end": "MUM"
            }
         }
      }
   }
}

Substitua o carimbo de data e hora de amostra pelo tempo da época Unix atual em segundos. Adapte as chaves do content_state ao provedor de estilos do seu aplicativo.

Problemas comuns de carga:

Campos críticos específicos da difusão:

• topic_name: Identifica o tópico FCM ao qual os dispositivos de destino fizeram assinatura. Inclua o mesmo valor não vazio em cada solicitação de início, atualização e término.
• audience.id: Identifica o público da campanha no Adobe Experience Platform. Verifique sua associação e perfis de exemplo para pushNotificationDetails válido.

Carimbo de data/hora e campos opcionais:

• Gere um novo timestamp em segundos de época para cada evento e verifique se ele é estritamente maior que o último valor para o mesmo tópico. Valores mais antigos ou iguais são ignorados.
• when opcionalmente define o tempo de exibição da notificação em segundos da época. Ela não controla a ordenação de mensagens.
• Para event_type: "end", dismiss_after especifica opcionalmente quantos segundos a atividade concluída permanece visível antes da remoção. É uma duração, não um carimbo de data e hora de época.

Consulte a documentação da API de Mensagens do Adobe Journey Optimizer para obter as especificações completas da API.

1. Confirme se o dispositivo de teste se inscreve no tópico exato especificado em topic_name, usando FirebaseMessaging.getInstance().subscribeToTopic(topic).
2. Verifique se a assinatura foi bem-sucedida e se o aplicativo a relata por meio da API de rastreamento topic-subscription compatível com sua extensão de Atividades do Adobe Live instalada.
3. Manter topic_name e notification_id inalterados em eventos de início, atualização e término.
4. Verifique se content_state chaves e tipos de valor correspondem ao provedor de estilo do aplicativo.
5. Verifique se as permissões de notificação são concedidas e se notification_channel_id corresponde a um canal criado pelo aplicativo.

Erros comuns:

Consulte o exemplo de carga de transmissão do Android para obter campos e exemplos adicionais.

Use o Assurance em um dispositivo de teste conectado do Android que faça parte do público-alvo e assine o tópico de transmissão.

1. Abra a sessão do Assurance antes de executar a chamada de API de transmissão.
2. Enviar solicitações de início, atualização e término com os mesmos topic_name e notification_id, aumentando os carimbos de data e hora.
3. Na lista Eventos, verifique se há erros de processamento de carga nos SDK e eventos de entrega disponíveis.
4. Confirme se a carga contém o objeto fcm, topic_name e event_type valores pretendidos.
5. Revise os relatórios da campanha e os eventos message.feedback disponíveis para confirmar os resultados da entrega do FCM. O valor serviceProvider do Android é fcm.
6. Se o FCM aceitar a mensagem, mas o dispositivo não renderizar a atividade, inspecione a assinatura do tópico, as permissões de notificação, a configuração do canal e os logs do aplicativo. A aceitação do provedor não confirma a renderização do dispositivo.