Sobre as mensagens do FCM

O Firebase Cloud Messaging (FCM) oferece uma ampla gama de opções e recursos de mensagens. As informações nesta página têm o objetivo de ajudar você a entender os diferentes tipos de mensagem do FCM e o que você pode fazer com elas.

Tipos de mensagem

Com o FCM, você pode enviar dois tipos de mensagens aos clientes:

  • Mensagens de notificação, às vezes conhecidas como "mensagens de exibição". Elas são processadas automaticamente pelo SDK do FCM.
  • Mensagens de dados, que são tratadas pelo app cliente.

As mensagens de notificação contêm um conjunto predefinido de chaves visíveis pelo usuário. As mensagens de dados, por outro lado, contêm somente pares de chave-valor personalizados definidos pelo usuário. As mensagens de notificação podem conter um payload de dados opcional. O payload máximo para ambos os tipos de mensagem é de 4000 bytes, exceto ao enviar mensagens do Console do Firebase, que impõe um limite de 1.024 caracteres.

Cenário de uso Como enviar
Mensagem de notificação O SDK do FCM exibe a mensagem para os dispositivos dos usuários finais em nome do app cliente quando ele está sendo executado em segundo plano. Se o app estiver sendo executado em primeiro plano quando a notificação for recebida, o código do aplicativo vai determinar o comportamento. As mensagens de notificação têm um conjunto predefinido de chaves visíveis para os usuários e um payload de dados opcional de pares de chave-valor personalizados.
  1. Em um ambiente confiável, como o Cloud Functions ou o servidor do app, use o SDK Admin ou os protocolos de servidor do FCM: configure a chave notification. Pode ter payload de dados opcional. Sempre é recolhível.

    Veja alguns exemplos de notificações de exibição e envie payloads de solicitações.

  2. Use o Editor do Notificações: insira o texto da mensagem, o título etc. e envie. Adicione payload de dados opcional fornecendo dados personalizados.
Mensagem de dados O app cliente é responsável pelo processamento de mensagens de dados. As mensagens de dados têm apenas pares de chave-valor personalizados sem nomes de chave reservados (veja abaixo). Em um ambiente confiável, como o Cloud Functions ou o servidor do app, use o SDK Admin ou os protocolos de servidor do FCM: configure somente a chave data.

Use mensagens de notificação quando quiser que o SDK do FCM processe a exibição de uma notificação automaticamente quando seu app estiver sendo executado em segundo plano. Use mensagens de dados quando quiser processar as mensagens com seu próprio código de app cliente.

O FCM pode enviar uma mensagem de notificação que inclui um payload de dados opcional. Nesses casos, o FCM processa a exibição do payload da notificação e o app cliente processa o payload de dados.

Mensagens de notificação

Para fazer testes ou marketing e atrair novamente o usuário, envie mensagens de notificação por meio do Console do Firebase. O Console do Firebase fornece testes A/B com base em análise para ajudar a refinar e melhorar as mensagens de marketing.

Para enviar mensagens de notificação programaticamente usando o SDK Admin ou os protocolos do FCM, defina a chave notification com o conjunto predefinido necessário de opções de chave-valor para a parte visível pelo usuário da mensagem de notificação. Por exemplo, esta é uma mensagem de notificação formatada em JSON em um aplicativo de mensagens instantâneas. O usuário verá uma mensagem com o título "Portugal x Dinamarca" e o texto "ótima partida!" no dispositivo:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

As mensagens de notificação são entregues na bandeja de notificação quando o app está em segundo plano. Para apps em primeiro plano, as mensagens são processadas por uma função de retorno de chamada.

Consulte a documentação de referência para ver a lista completa de chaves predefinidas disponíveis para criar mensagens de notificação:

Mensagens de dados

Defina a chave adequada com seus pares de chave-valor personalizados para enviar um payload de dados para o app cliente.

Por exemplo, aqui está uma mensagem formatada em JSON no mesmo app de mensagens instantâneas, em que as informações estão encapsuladas na chave data comum e espera-se que o app cliente interprete o conteúdo:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

O exemplo acima mostra o uso do campo data de nível superior ou comum, que é interpretado por clientes em todas as plataformas que recebem a mensagem. Em cada plataforma, o app cliente recebe o payload dos dados em uma função de retorno de chamada.

Criptografia para mensagens de dados

A Camada de transporte do Android (consulte Arquitetura do FCM) usa criptografia de ponta a ponta. Dependendo da sua necessidade, é possível adicionar esse tipo de criptografia às mensagens de dados. O FCM não oferece uma solução completa. No entanto, há soluções externas disponíveis, como Capillary ou DTLS.

Mensagens de notificação com payload de dados opcional

Seja programaticamente ou por meio do Console do Firebase, você pode enviar mensagens de notificação que contenham um payload opcional de pares de chave-valor personalizados. No Editor do Notificações (em inglês), use os campos Dados personalizados nas Opções avançadas.

O comportamento do app que recebe mensagens com payloads de notificação e dados depende de o app estar em primeiro ou segundo plano. Ou seja, se está ou não ativo quando recebe as mensagens.

  • Quando estão em segundo plano, os apps recebem o payload de notificação na bandeja de notificações e processam apenas o payload de dados quando o usuário toca na notificação.
  • Quando estão em primeiro plano, os apps recebem um objeto de mensagem com os dois payloads disponíveis.

Esta é uma mensagem com formatação JSON que contém as chaves notification e data:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

Como personalizar uma mensagem entre plataformas

O SDK Admin do Firebase e o protocolo HTTP v1 do FCM permitem que as solicitações de mensagens configurem todos os campos disponíveis no objeto message. Incluindo:

  • Um conjunto comum de campos a serem interpretados por todas as instâncias do app que recebem a mensagem.
  • Conjuntos de campos específicos da plataforma, como AndroidConfig e WebpushConfig, interpretados apenas pelas instâncias do app em execução na plataforma especificada.

Os blocos específicos da plataforma oferecem flexibilidade para personalizar mensagens em plataformas diferentes, garantindo, assim, que elas sejam gerenciadas corretamente quando recebidas. O back-end do FCM considerará todos os parâmetros especificados e personalizará a mensagem para cada plataforma.

Quando usar campos comuns

Use campos comuns ao:

  • segmentar instâncias de aplicativos em todas as plataformas: Apple, Android e Web;
  • enviar mensagens para tópicos.

Todas as instâncias do app, independentemente da plataforma, podem interpretar os seguintes campos comuns:

Quando usar campos específicos da plataforma

Use campos específicos da plataforma quando quiser:

  • enviar campos apenas para plataformas específicas;
  • enviar campos específicos da plataforma, além dos campos comuns.

Sempre que você quiser enviar valores apenas para plataformas específicas, não use campos comuns. Em vez disso, use campos específicos da plataforma. Por exemplo, para enviar uma notificação apenas para as plataformas Apple e Web, mas não para o Android, use dois conjuntos de campos separados, um para a Apple e outro para a Web.

Ao enviar mensagens com opções de entrega específicas, use os campos específicos da plataforma para configurá-las. É possível especificar valores diferentes por plataforma, se você quiser. No entanto, mesmo quando você quiser definir essencialmente o mesmo valor em todas as plataformas, é necessário usar campos específicos da plataforma. Isso ocorre porque o valor pode ser interpretado de maneira ligeiramente diferente dependendo da plataforma. Por exemplo, no Android, a vida útil é definida como um prazo de validade em segundos, enquanto que, na Apple, é definida como uma data de validade.

Exemplo: mensagem de notificação com opções de entrega específicas da plataforma

A solicitação de envio v1 a seguir envia o título e o conteúdo de uma notificação comum para todas as plataformas, mas também envia algumas modificações específicas da plataforma. Especificamente, a solicitação:

  • define uma vida útil longa para as plataformas Android e Web, ao mesmo tempo que define a prioridade das mensagens dos APNs (plataformas Apple) com uma configuração baixa;
  • indica as chaves adequadas para definir o resultado de um toque do usuário na notificação no Android e na Apple: click_action ecategory, respectivamente.
{
  "message":{
     "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
     "notification":{
       "title":"Match update",
       "body":"Arsenal goal in added time, score is now 3-0"
     },
     "android":{
       "ttl":"86400s",
       "notification"{
         "click_action":"OPEN_ACTIVITY_1"
       }
     },
     "apns": {
       "headers": {
         "apns-priority": "5",
       },
       "payload": {
         "aps": {
           "category": "NEW_MESSAGE_CATEGORY"
         }
       }
     },
     "webpush":{
       "headers":{
         "TTL":"86400"
       }
     }
   }
 }

Consulte a documentação de referência HTTP v1 para ver mais detalhes sobre as chaves disponíveis em blocos específicos da plataforma no corpo da mensagem. Para mais informações sobre como criar solicitações de envio que contenham o corpo da mensagem, consulte Criar solicitações de envio.

Opções de envio

O FCM fornece um conjunto específico de opções de entrega para mensagens enviadas para dispositivos Android e permite opções semelhantes nas plataformas Apple e Web. Por exemplo, o comportamento de mensagem "recolhível" é aceito no Android com o collapse_key do FCM, na Apple com o apns-collapse-id e em JavaScript/Web com o Topic. Para mais detalhes, veja as descrições nesta seção e a documentação de referência relacionada.

Mensagens recolhíveis e não recolhíveis

Uma mensagem não recolhível indica que cada mensagem individual é entregue ao dispositivo. Uma mensagem não recolhível entrega conteúdo útil, ao contrário de uma mensagem recolhível, que dá um ping sem conteúdo ao aplicativo para dispositivos móveis para entrar em contato com o servidor e recuperar dados.

Alguns casos de uso típicos de mensagens não recolhíveis são as mensagens de bate-papo ou críticas. Por exemplo, em um app de mensagens instantâneas, é possível que você queira enviar todas as mensagens, porque cada mensagem tem conteúdo diferente.

No Android, há um limite de 100 mensagens que podem ser armazenadas sem serem recolhidas. Se o limite for atingido, todas as mensagens armazenadas serão descartadas. Quando o dispositivo está de volta on-line, recebe uma mensagem especial indicando que o limite foi atingido. O app pode então processar a situação da maneira correta, normalmente solicitando uma sincronização completa com o servidor do app.

Uma mensagem recolhível é uma mensagem que pode ser substituída por uma nova mensagem se ainda não tiver sido entregue ao dispositivo.

Um caso de uso comum das mensagens recolhíveis são as mensagens usadas para informar um aplicativo para dispositivos móveis que é preciso sincronizar dados do servidor. Um exemplo seria um app de esportes que atualiza os usuários com a pontuação mais recente. Somente a mensagem mais recente é relevante.

Para marcar uma mensagem como recolhível no Android, inclua o parâmetro collapse_key no payload dela. Por padrão, a chave de recolhimento é o nome do pacote do app registrado no Console do Firebase. O servidor do FCM pode armazenar simultaneamente quatro mensagens recolhíveis diferentes por dispositivo, cada uma com uma chave de recolhimento diferente. Se você exceder esse número, o FCM manterá somente quatro chaves de recolhimento, sem garantias de quais serão mantidas.

Por padrão, as mensagens de tópicos sem payload são recolhíveis. As mensagens de notificação são sempre recolhíveis e ignoram o parâmetro collapse_key.

Qual devo usar?

As mensagens recolhíveis são uma escolha melhor do ponto de vista de desempenho, desde que o app não precise usar mensagens não recolhíveis. No entanto, se você usar mensagens recolhíveis, lembre-se de que o FCM só permite que no máximo quatro chaves de recolhimento diferentes sejam usadas pelo FCM por token de registro em qualquer momento. Não exceda esse número ou poderá causar consequências imprevisíveis.

Cenário de uso Como enviar
Não recolhível Toda mensagem é importante para o app cliente e precisa ser entregue. Com exceção das mensagens de notificação, todas as mensagens são não recolhíveis por padrão.
Recolhível Quando há uma mensagem mais recente que torna uma mensagem mais antiga e relacionada irrelevante para o app cliente, o FCM substitui a mensagem mais antiga. Por exemplo: mensagens usadas para iniciar uma sincronização de dados do servidor ou mensagens de notificação desatualizadas. Defina o parâmetro apropriado na sua solicitação de mensagem:
  • collapseKey no Android
  • apns-collapse-id na Apple
  • Topic na Web
  • collapse_key em protocolos legados (todas as plataformas)

Como definir a prioridade de uma mensagem

Você tem duas opções para atribuir a prioridade de entrega para mensagens downstream: prioridade normal e alta. Embora o comportamento seja um pouco diferente entre as plataformas, a entrega de mensagens de prioridade normal e alta funciona assim:

  • Prioridade normal. As mensagens com prioridade normal são entregues imediatamente quando o app está em primeiro plano. Para apps em segundo plano, a entrega pode ser adiada. Para mensagens menos afetadas pelo tempo, como enviar notificações de novos e-mails, manter a sincronização da sua IU ou sincronizar os dados do app em segundo plano, escolha a prioridade normal de entrega.

  • Prioridade alta. O FCM tenta enviar mensagens de prioridade alta imediatamente, mesmo quando o dispositivo está no modo Soneca. As mensagens de prioridade alta são voltadas para conteúdo visível ao usuário e urgente.

Veja um exemplo de uma mensagem de prioridade normal enviada por meio do protocolo HTTP v1 do FCM para notificar um assinante de revista que um novo conteúdo está disponível para download:

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

Para ver mais detalhes específicos da plataforma na definição da prioridade da mensagem:

Definir a vida útil de uma mensagem

O FCM geralmente entrega mensagens imediatamente após elas terem sido enviadas. No entanto, isso nem sempre é possível. Por exemplo, se a plataforma for Android, o dispositivo poderá estar desligado, desconectado ou de alguma forma indisponível. O FCM pode atrasar mensagens intencionalmente para evitar que um app consuma recursos excessivos, o que prejudica a duração da bateria.

Quando isso acontece, o FCM armazena a mensagem e a entrega o quanto antes. Embora isso não seja um problema na maioria dos casos, em alguns apps é possível que as mensagens atrasadas não sejam entregues. Por exemplo, se a mensagem for uma notificação de chat por vídeo ou uma chamada recebida, ela só vai ser relevante por um breve período até o encerramento da chamada. Se a mensagem for um convite para um evento, ela será inútil se for recebida após o término do evento.

No Android e na Web/em JavaScript, é possível especificar a vida útil máxima de uma mensagem. O valor precisa ter a duração de 0 a 2.419.200 segundos (28 dias) e corresponde ao período máximo pelo qual o FCM armazena e tenta entregar a mensagem. Para as solicitações que não tiverem esse campo preenchido, será usado o valor padrão do período máximo de quatro semanas.

Veja aqui alguns usos possíveis para este recurso:

  • Chamadas de bate-papo por vídeo recebidas
  • Eventos de convite expirando
  • Eventos da agenda

Outra vantagem de especificar a vida útil de uma mensagem é que o FCM nunca limita mensagens com um valor de vida útil de 0 segundos. Em outras palavras, o FCM garante a máxima atenção para as mensagens que precisam ser entregues sem atraso. Tenha em mente que um valor time_to_live de 0 significa que mensagens que não podem ser entregues imediatamente são descartadas. No entanto, como essas mensagens nunca são armazenadas, isso gera a melhor latência para o envio de mensagens de notificação.

Veja um exemplo de solicitação que inclui TTL:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    },
    "apns":{
      "headers":{
        "apns-expiration":"1604750400"
      }
    },
    "android":{
      "ttl":"4500s"
    },
    "webpush":{
      "headers":{
        "TTL":"4500"
      }
    }
  }
}

Vida útil de uma mensagem

Quando um servidor do app publica uma mensagem para o FCM e recebe um ID de mensagem de volta, isso não significa que a mensagem já foi entregue ao dispositivo. Na verdade, significa que ela foi aceita para a entrega. O que acontece com a mensagem após a aceitação depende de muitos fatores.

Em uma situação ideal, se o dispositivo estiver conectado ao FCM, a tela estiver ativada e não houver restrições de limite, a mensagem será entregue imediatamente.

Se o dispositivo estiver conectado, mas no modo Soneca, uma mensagem de prioridade baixa é armazenada pelo FCM até o dispositivo sair desse modo. É nesse momento que a sinalização collapse_key desempenha um papel: se já houver uma mensagem com a mesma chave de recolhimento (e token de registro) armazenada e aguardando a entrega, a mensagem antiga será descartada e a nova tomará o lugar dela. Ou seja, a mensagem antiga será recolhida pela nova. No entanto, se a chave de recolhimento não estiver definida, as mensagens novas e antigas serão armazenadas para entrega posterior.

Se o dispositivo não estiver conectado ao FCM, a mensagem será armazenada até que uma conexão seja estabelecida (novamente respeitando as regras da chave de recolhimento). Quando uma conexão é estabelecida, o FCM entrega todas as mensagens pendentes ao dispositivo. Se o dispositivo não se reconectar (por exemplo, se for redefinido para os padrões de fábrica), a mensagem acabará expirando e será descartada do armazenamento do FCM. O tempo limite padrão é de quatro semanas, a menos que a sinalização time_to_live seja definida.

Para mais informações sobre a entrega de uma mensagem:

    Saiba mais sobre a entrega de mensagens nas plataformas Android ou Apple no painel de geração de relatórios do FCM, que registra o número de mensagens enviadas e abertas em dispositivos Apple e Android, além de dados para "impressões" (notificações vistas pelos usuários) para apps Android.

Para dispositivos Android com mensagens de canal direto ativadas, se o dispositivo não estiver conectado ao FCM por mais de um mês, o FCM ainda aceitará a mensagem, mas a descartará imediatamente. Se o dispositivo se conectar dentro de quatro semanas a partir da última mensagem de dados enviada a ele, o cliente receberá a callback onDeletedMessages(). O app pode então processar a situação da maneira correta, normalmente solicitando uma sincronização completa do servidor do app.

Por fim, se o FCM tentar entregar uma mensagem ao dispositivo e o app tiver sido desinstalado, o FCM descartará a mensagem imediatamente e invalidará o token de registro. As próximas tentativas de enviar uma mensagem a esse dispositivo resultarão em um erro NotRegistered.

Limitação e escalonamento

Nosso objetivo é sempre entregar todas as mensagens enviadas pelo FCM. No entanto, entregar cada uma delas nem sempre resulta em uma boa experiência para o usuário. Em outros casos, precisamos fornecer limites para garantir que o FCM proporcione um serviço escalonável para todos os remetentes.

Limitação de mensagens recolhíveis

Conforme descrito acima, as mensagens recolhíveis são notificações sem conteúdo projetadas para se sobrepor umas às outras. Caso um desenvolvedor repita a mesma mensagem para um aplicativo com muita frequência, adiaremos as mensagens (limitaremos) para reduzir o impacto na bateria de um usuário.

Por exemplo, se você enviar um grande número de novas solicitações de sincronização de e-mail para um único dispositivo, poderemos adiar a próxima solicitação de sincronização de e-mail por alguns minutos para que o dispositivo possa ser sincronizado com uma taxa média mais baixa. Essa limitação é realizada estritamente para limitar o impacto da bateria presenciado pelo usuário.

Se o caso de uso exigir altos padrões de envio, as mensagens não recolhíveis podem ser a escolha certa. Para essas mensagens, inclua o conteúdo delas para reduzir o custo da bateria.

Limitamos mensagens recolhíveis a uma alta taxa de 20 mensagens por aplicativo por dispositivo, com um novo envio de 1 mensagem a cada 3 minutos.

Limitação do servidor XMPP

Limitamos a taxa que você pode conectar aos servidores XMPP do FCM a 400 conexões por minuto por projeto. Isso não deve ser um problema para a entrega de mensagens, mas é importante para garantir a estabilidade do nosso sistema.

Para cada projeto, o FCM permite 2.500 conexões em paralelo.

Taxa máxima de mensagens para um único dispositivo

No Android, é possível enviar até 240 mensagens/minuto e 5.000 mensagens/hora para um único dispositivo. O objetivo desse alto limite é permitir aumentos de tráfego em curto prazo, como quando os usuários estão interagindo rapidamente no chat. Esse limite evita que erros na lógica de envio esgotem sem querer a bateria de um dispositivo.

No iOS, um erro é retornado quando a taxa excede os limites dos APNs.

Limite de mensagens upstream

Limitamos mensagens upstream a 1.500.000/minuto por projeto para evitar a sobrecarga de servidores de destino upstream.

Limitamos mensagens upstream por dispositivo a 1.000/minuto para proteger contra o consumo de bateria relacionado ao mau comportamento do aplicativo.

Limite de mensagem do tópico

A taxa de adição/remoção de assinatura do tópico é limitada a 3.000 QPS por projeto.

Para taxas de envio de mensagens, consulte Limitação de Fanout.

Limitação de Fanout

O fanout de mensagens é o processo de enviar uma mensagem para vários dispositivos, como quando se segmenta tópicos e grupos ou usa o Editor do Notificações para públicos-alvo ou segmentos de usuários.

O fanout das mensagens não é instantâneo e, de vez em quando, poderão ocorrer várias fanouts em andamento ao mesmo tempo. Limitamos o número de fanouts de mensagens simultâneas por projeto a 1.000. Depois disso, poderemos rejeitar novas solicitações de fanout ou adiar o fanout das solicitações até que alguns dos fanouts em andamento sejam concluídos.

A taxa de fanout real conquistada é influenciada pelo número de projetos que solicitam fanouts ao mesmo tempo. Uma taxa de fanout de 10.000 QPS para um projeto individual não é incomum, mas esse número não é uma garantia. Ele é um resultado da carga total no sistema. A capacidade de fanout disponível é dividida entre os projetos e não entre as solicitações de fanout. Portanto, se o projeto tiver dois fanouts em andamento, cada um verá apenas metade da taxa de fanout disponível. A maneira recomendada de maximizar sua velocidade de fanout é ter apenas um fanout ativo em andamento por vez.

Portas do FCM e seu firewall

Se a sua organização tiver um firewall para restringir o tráfego para ou da Internet, será necessário configurá-lo para permitir que os dispositivos móveis se conectem ao FCM para que eles recebam mensagens. Geralmente, o FCM usa a porta 5228, mas às vezes usa a 443, 5229 e a 5230.

Para dispositivos que se conectam à rede, o FCM não fornece IPs específicos porque nosso intervalo de IPs muda com frequência e suas regras de firewall podem ficar desatualizadas, afetando a experiência dos usuários. O ideal é permitir as portas 5228 a 5230 e 443 sem restrições de IP. No entanto, se você tiver uma restrição de IP, será necessário colocar todos os endereços IP listados em goog.json na lista de permissões. Essa lista grande é atualizada regularmente. Recomendamos que você atualize as regras mensalmente. Problemas causados por restrições de IP do firewall são muitas vezes intermitentes e difíceis de diagnosticar.

Oferecemos um conjunto de nomes de domínios que podem ser incluídos na lista de permissões em vez de endereços IP. Esses nomes de host estão listados abaixo. Se começarmos a usar nomes de host adicionais, vamos atualizar a lista aqui. O uso de nomes de domínio para sua regra de firewall pode ou não ser funcional no dispositivo de firewall.

Portas TCP a serem abertas:

  • 5228
  • 5229
  • 5230
  • 443

Nomes de host a serem abertos:

  • mtalk.google.com
  • mtalk4.google.com
  • mtalk-staging.google.com
  • mtalk-dev.google.com
  • alt1-mtalk.google.com
  • alt2-mtalk.google.com
  • alt3-mtalk.google.com
  • alt4-mtalk.google.com
  • alt5-mtalk.google.com
  • alt6-mtalk.google.com
  • alt7-mtalk.google.com
  • alt8-mtalk.google.com
  • android.apis.google.com
  • device-provisioning.googleapis.com
  • firebaseinstallations.googleapis.com

Firewalls com conversão de endereços de rede e/ou inspeção dos estados dos pacotes:

Caso sua rede implemente Conversão de endereços de rede (NAT, na sigla em inglês) ou Inspeção dos estados dos pacotes (SPI, na sigla em inglês), implemente um tempo limite de 30 minutos ou mais para nossas conexões nas portas 5228 a 5230. Com isso, podemos fornecer uma conectividade confiável, reduzindo o consumo de bateria dos dispositivos móveis dos usuários.

Credenciais

Dependendo dos recursos do FCM implementados, as seguintes credenciais do projeto do Firebase podem ser necessárias:

ID do projeto Um identificador exclusivo do projeto do Firebase usado em solicitações para o endpoint HTTP v1 do FCM. Esse valor está disponível no painel Configurações do Console do Firebase.
Token de registro

Uma string de token exclusiva que identifica cada instância do app cliente. O token de registro é necessário para mensagens para dispositivos únicos e grupos de dispositivos. Observe que os tokens de registro precisam ser mantidos em segredo.

ID do remetente Um valor numérico exclusivo gerado ao criar o projeto do Firebase, disponível na guia Cloud Messaging do painel Configurações do Console do Firebase. O ID do remetente é usado para identificar cada remetente que pode enviar mensagens ao app cliente.
Token de acesso Um token OAuth 2.0 de curta duração que autoriza solicitações para a API HTTP v1. Esse token está associado a uma conta de serviço que pertence ao seu projeto do Firebase. Para criar e alternar tokens de acesso, siga as etapas descritas em Autorizar solicitações de envio.
Chave do servidor (para protocolos legados)

Uma chave do servidor que autoriza o servidor do app para acessar os serviços do Google, inclusive o envio de mensagens pelos protocolos legados do Firebase Cloud Messaging. Você recebe a chave do servidor quando você cria seu projeto do Firebase. Para visualizá-la, acesse a guia Cloud Messaging (em inglês) do painel Configurações do Console do Firebase.

Importante: não inclua a chave do servidor em nenhum lugar do código de cliente. Além disso, use apenas chaves de servidores para autorizar o servidor do app. As chaves das plataformas Android e Apple e do navegador são rejeitadas pelo FCM.