Acompanhe tudo o que foi anunciado no Firebase Summit e saiba como usar o Firebase para acelerar o desenvolvimento de apps e executá-los com confiança. Saiba mais

Sobre as mensagens do FCM

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O Firebase Cloud Messaging (FCM) oferece uma ampla variedade de opções e recursos de mensagens. As informações nesta página destinam-se a ajudá-lo a entender os diferentes tipos de mensagens 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 chamadas de "mensagens de exibição". Eles são tratados pelo SDK do FCM automaticamente.
  • Mensagens de dados, que são tratadas pelo aplicativo cliente.

As mensagens de notificação contêm um conjunto predefinido de chaves visíveis ao usuário. As mensagens de dados, por outro lado, contêm apenas seus pares de valores-chave personalizados definidos pelo usuário. As mensagens de notificação podem conter uma carga útil de dados opcional. A carga útil máxima para ambos os tipos de mensagem é de 4.000 bytes, exceto ao enviar mensagens do console do Firebase, que impõe um limite de 1.024 caracteres.

Usar cenário Como enviar
Mensagem de notificação O FCM exibe automaticamente a mensagem para os dispositivos do usuário final em nome do aplicativo cliente. As mensagens de notificação têm um conjunto predefinido de chaves visíveis ao usuário e uma carga útil de dados opcional de pares de valores-chave personalizados.
  1. Em um ambiente confiável, como o Cloud Functions ou seu servidor de aplicativos, use o SDK Admin ou os protocolos do servidor FCM : defina a chave de notification . Pode ter carga útil de dados opcional. Sempre desmontável.

    Veja alguns exemplos de notificações de exibição e cargas úteis de solicitação de envio.

  2. Use o compositor de notificações : insira o texto da mensagem, o título etc. e envie. Adicione carga útil de dados opcional fornecendo dados personalizados.
Mensagem de dados O aplicativo cliente é responsável pelo processamento de mensagens de dados. As mensagens de dados têm apenas pares de valores-chave personalizados sem nomes de chave reservados (veja abaixo). Em um ambiente confiável, como o Cloud Functions ou seu servidor de aplicativos, use o SDK Admin ou os protocolos do servidor FCM : defina apenas a chave de data .

Use mensagens de notificação quando quiser que o FCM lide com a exibição de uma notificação em nome do seu aplicativo cliente. Use mensagens de dados quando quiser processar as mensagens em seu aplicativo cliente.

O FCM pode enviar uma mensagem de notificação incluindo uma carga útil de dados opcional. Nesses casos, o FCM lida com a exibição da carga de notificação e o aplicativo cliente lida com a carga de dados.

Mensagens de notificação

Para testes ou para marketing e reengajamento do usuário, você pode enviar mensagens de notificação usando o console do Firebase . O console do Firebase oferece testes A/B baseados em análise para ajudar você a refinar e melhorar as mensagens de marketing.

Para enviar mensagens de notificação programaticamente usando o SDK Admin ou os protocolos FCM, defina a chave de notification com o conjunto predefinido necessário de opções de valor-chave para a parte visível do usuário da mensagem de notificação. Por exemplo, aqui está uma mensagem de notificação formatada em JSON em um aplicativo de mensagens instantâneas. O usuário pode esperar ver uma mensagem com o título "Portugal vs. Dinamarca" e o texto "grande 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 aplicativo está em segundo plano. Para aplicativos em primeiro plano, as mensagens são tratadas por uma função de retorno de chamada.

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

Mensagens de dados

Defina a chave apropriada com seus pares de valores-chave personalizados para enviar uma carga útil de dados ao aplicativo cliente.

Por exemplo, aqui está uma mensagem formatada em JSON no mesmo aplicativo de mensagens instantâneas acima, onde as informações são encapsuladas na chave data comum e espera-se que o aplicativo 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 de data de nível superior ou comum, que é interpretado pelos clientes em todas as plataformas que recebem a mensagem. Em cada plataforma, o aplicativo cliente recebe a carga de 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 ponto a ponto. Dependendo de suas necessidades, você pode decidir adicionar criptografia de ponta a ponta às mensagens de dados. O FCM não fornece uma solução de ponta a ponta. No entanto, existem soluções externas disponíveis, como Capilar ou DTLS .

Mensagens de notificação com carga útil de dados opcional

Tanto programaticamente quanto por meio do console do Firebase, você pode enviar mensagens de notificação que contêm uma carga útil opcional de pares de valores-chave personalizados. No compositor de Notificações , use os campos de dados personalizados em Opções avançadas .

O comportamento do aplicativo ao receber mensagens que incluem cargas úteis de notificação e dados depende se o aplicativo está em segundo plano ou em primeiro plano — basicamente, se está ativo ou não no momento do recebimento.

  • Quando em segundo plano , os aplicativos recebem a carga útil da notificação na bandeja de notificações e só lidam com a carga útil de dados quando o usuário toca na notificação.
  • Quando em primeiro plano , seu aplicativo recebe um objeto de mensagem com as duas cargas disponíveis.

Aqui está uma mensagem em formato JSON contendo a chave de notification e a chave de data :

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

Personalizando uma mensagem entre plataformas

O SDK Admin do Firebase e o protocolo HTTP do FCM v1 permitem que suas solicitações de mensagem definam todos os campos disponíveis no objeto de message . Isso inclui:

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

Os blocos específicos da plataforma oferecem flexibilidade para personalizar mensagens para diferentes plataformas para garantir que sejam tratadas corretamente quando recebidas. O back-end do FCM levará em consideração todos os parâmetros especificados e personalizará a mensagem para cada plataforma.

Quando usar campos comuns

Use campos comuns quando estiver:

  • Segmentação de instâncias de aplicativos em todas as plataformas — Apple, Android e Web
  • Enviando mensagens para tópicos

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

Quando usar campos específicos da plataforma

Use campos específicos da plataforma quando quiser:

  • Envie campos apenas para plataformas específicas
  • Envie 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; use campos específicos da plataforma. Por exemplo, para enviar uma notificação apenas para plataformas Apple e web, mas não para Android, você deve usar dois conjuntos separados de campos, um para Apple e outro para web.

Ao enviar mensagens com opções de entrega específicas , use campos específicos da plataforma para defini-las. Você pode especificar valores diferentes por plataforma, se desejar. No entanto, mesmo quando você deseja definir essencialmente o mesmo valor entre plataformas, você deve usar campos específicos da plataforma. Isso ocorre porque cada plataforma pode interpretar o valor de forma ligeiramente diferente – por exemplo, o tempo de vida é definido no Android como um tempo de expiração em segundos, enquanto na Apple é definido como uma data de expiração .

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

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

  • define um longo tempo de vida para plataformas Android e Web, enquanto define a prioridade de mensagem de APNs (plataformas Apple) para uma configuração baixa
  • define as teclas apropriadas para definir o resultado de um toque do usuário na notificação no Android e na Apple — click_action e category , 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 do HTTP v1 para obter detalhes completos sobre as chaves disponíveis em blocos específicos da plataforma no corpo da mensagem. Para obter 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 entrega

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 na web. Por exemplo, o comportamento de mensagem "recolhível" é suportado no Android por meio de FCM's collapse_key , na Apple por meio apns-collapse-id e em JavaScript/Web por meio de Topic . Para obter detalhes, consulte as descrições nesta seção e a documentação de referência relacionada.

Mensagens não recolhíveis e recolhíveis

Uma mensagem não recolhível denota que cada mensagem individual é entregue ao dispositivo. Uma mensagem não recolhível fornece algum conteúdo útil, ao contrário de uma mensagem recolhível, como um "ping" sem conteúdo para o aplicativo móvel para entrar em contato com o servidor para buscar dados.

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

Para Android, há um limite de 100 mensagens que podem ser armazenadas sem colapso. Se o limite for atingido, todas as mensagens armazenadas serão descartadas. Quando o dispositivo estiver online novamente, ele receberá uma mensagem especial indicando que o limite foi atingido. O aplicativo pode lidar com a situação corretamente, normalmente solicitando uma sincronização completa do servidor de aplicativos.

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 de mensagens recolhíveis são mensagens usadas para informar um aplicativo móvel para sincronizar dados do servidor. Um exemplo seria um aplicativo de esportes que atualiza os usuários com a pontuação mais recente. Apenas a mensagem mais recente é relevante.

Para marcar uma mensagem como recolhível no Android, inclua o parâmetro collapse_key na carga útil da mensagem. Por padrão, a chave de recolhimento é o nome do pacote do aplicativo registrado no console do Firebase. O servidor 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á apenas quatro chaves de recolhimento, sem garantias sobre quais serão mantidas.

Mensagens de tópico sem carga útil são recolhíveis por padrão. As mensagens de notificação são sempre recolhíveis e ignorarão o parâmetro collapse_key .

Qual devo usar?

As mensagens recolhíveis são a melhor opção do ponto de vista do desempenho, desde que seu aplicativo 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 um máximo de quatro chaves de recolhimento diferentes sejam usadas pelo FCM por token de registro a qualquer momento. Você não deve exceder esse número, ou isso pode causar consequências imprevisíveis.

Usar cenário Como enviar
Não desmontável Cada mensagem é importante para o aplicativo cliente e precisa ser entregue. Exceto para mensagens de notificação, todas as mensagens não são recolhíveis por padrão.
Dobrável Quando há uma mensagem mais recente que torna uma mensagem mais antiga e relacionada irrelevante para o aplicativo 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 em sua solicitação de mensagem:
  • collapseKey no Android
  • apns-collapse-id na Apple
  • Topic na Web
  • collapse_key em protocolos legados (todas as plataformas)

Definir a prioridade de uma mensagem

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

  • Prioridade normal. As mensagens de prioridade normal são entregues imediatamente quando o aplicativo está em primeiro plano. Para aplicativos em segundo plano, a entrega pode ser atrasada. Para mensagens menos urgentes, como notificações de novos e-mails, manter sua interface do usuário sincronizada ou sincronizar dados de aplicativos em segundo plano, escolha a prioridade de entrega normal.

  • Prioridade máxima. O FCM tenta entregar mensagens de alta prioridade imediatamente, mesmo que o dispositivo esteja no modo Doze. As mensagens de alta prioridade são para conteúdo sensível ao tempo e visível ao usuário.

Aqui está um exemplo de uma mensagem de prioridade normal enviada por meio do protocolo FCM HTTP v1 para notificar um assinante de revista de 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 obter mais detalhes específicos da plataforma sobre como definir a prioridade da mensagem:

Definir a vida útil de uma mensagem

O FCM geralmente entrega as mensagens imediatamente após o envio. No entanto, isso pode nem sempre ser possível. Por exemplo, se a plataforma for Android, o dispositivo pode estar desligado, off-line ou indisponível. Ou o FCM pode atrasar intencionalmente as mensagens para evitar que um aplicativo consuma recursos excessivos e afete negativamente a vida útil da bateria.

Quando isso acontece, o FCM armazena a mensagem e a entrega assim que possível. Embora isso seja bom na maioria dos casos, existem alguns aplicativos para os quais uma mensagem atrasada pode nunca ser entregue. Por exemplo, se a mensagem for uma chamada recebida ou uma notificação de bate-papo por vídeo, ela será significativa apenas por um curto período de tempo antes que a chamada seja encerrada. Ou se a mensagem for um convite para um evento, é inútil se for recebida após o término do evento.

No Android e Web/JavaScript, você pode especificar a vida útil máxima de uma mensagem. O valor deve ter uma duração de 0 a 2.419.200 segundos (28 dias), e corresponde ao período máximo de tempo que o FCM armazena e tenta entregar a mensagem. As solicitações que não contêm esse campo têm como padrão o período máximo de quatro semanas.

Aqui estão alguns usos possíveis para esse recurso:

  • Chamadas recebidas do bate-papo por vídeo
  • Eventos de convite expirando
  • Eventos do calendário

Outra vantagem de especificar a vida útil de uma mensagem é que o FCM nunca limita as mensagens com um valor de tempo de vida de 0 segundos. Em outras palavras, o FCM garante o melhor esforço para mensagens que devem ser entregues "agora ou nunca". Tenha em mente que um valor time_to_live de 0 significa que as mensagens que não podem ser entregues imediatamente são descartadas. No entanto, como essas mensagens nunca são armazenadas, isso fornece a melhor latência para enviar mensagens de notificação.

Aqui está um exemplo de uma 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"
      }
    }
  }
}

Tempo de vida de uma mensagem

Quando um servidor de aplicativos publica uma mensagem no FCM e recebe um ID de mensagem de volta, isso não significa que a mensagem já foi entregue ao dispositivo. Em vez disso, significa que foi aceito para entrega. O que acontece com a mensagem depois que ela é aceita depende de muitos fatores.

Na melhor das hipóteses, se o dispositivo estiver conectado ao FCM, a tela estiver ligada e não houver restrições de limitação, a mensagem será entregue imediatamente.

Se o dispositivo estiver conectado, mas em Doze, uma mensagem de baixa prioridade será armazenada pelo FCM até que o dispositivo saia do Doze. E é aí que o sinalizador de collapse_key desempenha um papel: se já houver uma mensagem com a mesma chave de recolhimento (e token de registro) armazenada e aguardando entrega, a mensagem antiga é descartada e a nova mensagem ocupa seu lugar (ou seja, a antiga mensagem é recolhida pela nova). No entanto, se a chave de recolhimento não for definida, as mensagens novas e antigas serão armazenadas para entrega futura.

Se o dispositivo não estiver conectado ao FCM, a mensagem será armazenada até que uma conexão seja estabelecida (respeitando novamente as regras da chave de recolhimento). Quando uma conexão é estabelecida, o FCM entrega todas as mensagens pendentes ao dispositivo. Se o dispositivo nunca mais for conectado (por exemplo, se foi redefinido de fábrica), a mensagem eventualmente expira e é descartada do armazenamento do FCM. O tempo limite padrão é de quatro semanas, a menos que o sinalizador time_to_live esteja definido.

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

    Para obter mais informações sobre a entrega de mensagens em plataformas Android ou Apple, consulte o painel de relatórios do FCM , que registra o número de mensagens enviadas e abertas em dispositivos Apple e Android, juntamente com dados de "impressões" (notificações vistas pelos usuários) para Aplicativos 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 após a última mensagem de dados que você enviou a ele, seu cliente receberá o retorno de chamada onDeletedMessages() . O aplicativo pode lidar com a situação corretamente, normalmente solicitando uma sincronização completa do servidor de aplicativos.

Por fim, quando o FCM tenta entregar uma mensagem ao dispositivo e o aplicativo foi desinstalado, o FCM descarta essa mensagem imediatamente e invalida o token de registro. Tentativas futuras de enviar uma mensagem para esse dispositivo resultam em um erro NotRegistered .

Estrangulamento e dimensionamento

Nosso objetivo é sempre entregar todas as mensagens enviadas via FCM. No entanto, entregar todas as mensagens às vezes resulta em uma experiência geral ruim para o usuário. Em outros casos, precisamos fornecer limites para garantir que o FCM forneça um serviço escalá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 serem recolhidas umas sobre as outras. Caso um desenvolvedor esteja repetindo a mesma mensagem para um aplicativo com muita frequência, atrasamos (aceleramos) as mensagens para reduzir o impacto na bateria do 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 atrasar a próxima solicitação de sincronização de e-mail alguns minutos para que o dispositivo possa sincronizar a uma taxa média mais baixa. Essa limitação é feita estritamente para limitar o impacto da bateria experimentado pelo usuário.

Se o seu caso de uso exigir padrões de envio de alta rajada, as mensagens não recolhíveis podem ser a escolha certa. Para essas mensagens, certifique-se de incluir o conteúdo em tais mensagens para reduzir o custo da bateria.

Limitamos as mensagens recolhíveis a uma explosão de 20 mensagens por aplicativo por dispositivo, com um reabastecimento de 1 mensagem a cada 3 minutos.

Limitação do servidor XMPP

Limitamos a taxa que você pode conectar aos servidores FCM XMPP 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

Para Android, você pode enviar até 240 mensagens/minuto e 5.000 mensagens/hora para um único dispositivo. Esse limite alto destina-se a permitir rajadas de tráfego de curto prazo, como quando os usuários estão interagindo rapidamente no bate-papo. Esse limite evita que erros no envio de lógica esgotem inadvertidamente a bateria de um dispositivo.

Para iOS, retornamos um erro quando a taxa excede os limites de APNs.

Limite de mensagens upstream

Limitamos as mensagens upstream em 1.500.000/minuto por projeto para evitar sobrecarregar os servidores de destino upstream.

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

Limite de mensagens do tópico

A taxa de adição/remoção de assinatura de 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 mensagem é o processo de envio de uma mensagem para vários dispositivos, como quando você segmenta tópicos e grupos ou quando usa o compositor de notificações para segmentar públicos ou segmentos de usuários.

O fanout da mensagem não é instantâneo e, ocasionalmente, você tem vários fanouts em andamento simultaneamente. Limitamos o número de fanouts de mensagens simultâneas por projeto a 1.000. Depois disso, podemos rejeitar solicitações de fanout adicionais ou adiar o fanout das solicitações até que alguns dos fanouts já em andamento sejam concluídos.

A taxa de fanout real alcançável é 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 e é resultado da carga total no sistema. É importante observar que a capacidade de fanout disponível é dividida entre projetos e não entre solicitações de fanout. Portanto, se seu projeto tiver dois fanout em andamento, cada fanout 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 FCM e seu firewall

Se sua organização tiver um firewall para restringir o tráfego de ou para a Internet, você precisará configurá-lo para permitir que dispositivos móveis se conectem ao FCM para que os dispositivos em sua rede recebam mensagens. O FCM normalmente usa a porta 5228, mas às vezes usa 443, 5229 e 5230.

Para dispositivos que se conectam à sua rede, o FCM não fornece IPs específicos porque nosso intervalo de IP muda com muita frequência e suas regras de firewall podem ficar desatualizadas, afetando a experiência dos usuários. Idealmente, as portas de lista de permissões 5228-5230 e 443 sem restrições de IP. No entanto, se você precisar ter uma restrição de IP, deverá permitir a lista de todos os endereços IP listados em goog.json . Essa grande lista é atualizada regularmente e recomendamos que você atualize suas regras mensalmente. Os problemas causados ​​por restrições de IP do firewall geralmente são intermitentes e difíceis de diagnosticar.

Oferecemos um conjunto de nomes de domínio que podem ser permitidos em vez de endereços IP. Esses nomes de host estão listados abaixo. Se começarmos a usar nomes de host adicionais, atualizaremos a lista aqui. O uso de nomes de domínio para sua regra de firewall pode ou não funcionar em seu dispositivo de firewall.

Portas TCP para abrir:

  • 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 de tradução de endereço de rede e/ou inspeção de pacote com estado:

Se sua rede implementa NAT (Network Address Translation) ou SPI (Stateful Packet Inspection), implemente um tempo limite de 30 minutos ou mais para nossas conexões nas portas 5228-5230. Isso nos permite fornecer conectividade confiável enquanto reduz o consumo de bateria dos dispositivos móveis de seus usuários.

Credenciais

Dependendo de quais recursos do FCM você implementar, talvez você precise das seguintes credenciais do seu projeto do Firebase:

Código do projeto Um identificador exclusivo para seu projeto do Firebase, usado em solicitações para o endpoint HTTP do FCM v1. 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 aplicativo cliente. O token de registro é necessário para mensagens de dispositivo único e grupo de dispositivos. Observe que os tokens de registro devem ser mantidos em segredo.

ID do remetente Um valor numérico exclusivo criado ao criar seu projeto do Firebase, disponível na guia Cloud Messaging do painel Configurações do console do Firebase. A ID do remetente é usada para identificar cada remetente que pode enviar mensagens para o aplicativo cliente.
Token de acesso Um token OAuth 2.0 de curta duração que autoriza solicitações para a API HTTP v1. Este 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 de servidor que autoriza seu servidor de aplicativos a acessar os serviços do Google, incluindo o envio de mensagens por meio dos protocolos legados do Firebase Cloud Messaging. Você obtém a chave do servidor ao criar seu projeto do Firebase. Você pode visualizá-lo na guia Cloud Messaging do painel Configurações do console do Firebase.

Importante: Não inclua a chave do servidor em nenhum lugar do código do cliente. Além disso, certifique-se de usar apenas chaves de servidor para autorizar seu servidor de aplicativos. As chaves do Android, da plataforma Apple e do navegador são rejeitadas pelo FCM.