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

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 para os clientes:

  • Mensagens de notificação, às vezes consideradas como "mensagens de exibição". Eles são tratados automaticamente pelo SDK do FCM.
  • 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 de dados opcional. O payload máximo para ambos os tipos de mensagem é de 4.000 bytes, exceto ao enviar mensagens do Firebase console, 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 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 Admin SDK ou os protocolos do servidor FCM : defina a chave de notification . Pode ter carga útil de dados opcional. Sempre dobrável.

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

  2. Use o compositor de Notificações : Digite o Texto da Mensagem, 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 chave-valor personalizados sem nomes de chave reservados (veja abaixo). Em um ambiente confiável, como o Cloud Functions ou seu servidor de aplicativos, use o Admin SDK 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 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 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 Firebase console . O Firebase console fornece testes A/B baseados em análises para ajudar você a refinar e melhorar as mensagens de marketing.

Para enviar mensagens de notificação programaticamente usando o Admin SDK 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 utilizador pode esperar ver uma mensagem com o título "Portugal vs. Dinamarca" e o texto "great match!" 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 valor-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 nível superior ou campo de data comum, que é interpretado por 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 a arquitetura 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 completa. No entanto, existem soluções externas disponíveis, como Capillary ou DTLS .

Mensagens de notificação com payload de dados opcional

Tanto de forma programática 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 - essencialmente, se está ativo ou não no momento do recebimento.

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

Aqui está uma mensagem formatada em 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 Firebase Admin SDK e o protocolo FCM v1 HTTP 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 de aplicativos 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 você 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:

  • Enviar campos apenas para plataformas específicas
  • Envie campos específicos da plataforma além dos campos comuns

Sempre que 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 os campos específicos da plataforma para defini-los. Você pode especificar valores diferentes por plataforma, se desejar. No entanto, mesmo quando você deseja definir essencialmente o mesmo valor entre plataformas, deve usar campos específicos da plataforma. Isso ocorre porque cada plataforma pode interpretar o valor de maneira 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 seguinte solicitação de envio v1 envia um título e conteúdo de notificação comuns 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 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 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 contêm 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 da Apple e na web. Por exemplo, o comportamento da mensagem "recolhível" é suportado no Android por meio do FCM ' 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 indica 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 contatar o servidor para buscar dados.

Alguns casos de uso típicos de mensagens não recolhíveis são mensagens de chat 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 adequadamente, normalmente solicitando uma sincronização completa do servidor do aplicativo.

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

Um caso de uso comum de mensagens recolhíveis são mensagens usadas para instruir um aplicativo móvel a sincronizar dados do servidor. Um exemplo seria um aplicativo 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âmetrolapse_key no collapse_key da mensagem. Por padrão, a chave de recolhimento é o nome do pacote do aplicativo registrado no Firebase console. O servidor FCM pode armazenar simultaneamente quatro mensagens recolhíveis diferentes por dispositivo, cada uma com uma chave de recolhimento diferente. Caso ultrapasse esse número, o FCM mantém apenas quatro chaves recolhidas, sem garantia de quais serão mantidas.

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

Qual devo usar?

Mensagens recolhíveis são uma escolha melhor do ponto de vista de 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 permite apenas um máximo de quatro chaves recolhíveis diferentes a serem 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 relacionada mais antiga 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)

Definindo 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 sensíveis ao tempo, como notificações de novo e-mail, mantendo sua interface do usuário sincronizada ou sincronizando dados do aplicativo em segundo plano, escolha a prioridade de entrega normal.

  • Prioridade máxima. O FCM tenta entregar mensagens de alta prioridade imediatamente, mesmo se o dispositivo estiver no modo Soneca. 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 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 o tempo de vida 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, offline 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 de a chamada ser encerrada. Ou se a mensagem for um convite para um evento, de nada serve se for recebida após o término do evento.

No Android e Web/JavaScript, você pode especificar o tempo máximo de vida 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 de bate-papo por vídeo
  • Eventos de convite expirados
  • Eventos do calendário

Outra vantagem de especificar o tempo de vida 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". Lembre-se de que um valor de time_to_live igual a 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 envia 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. 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 Soneca, uma mensagem de baixa prioridade é armazenada pelo FCM até que o dispositivo saia de Soneca. E é aí que o flag collapse_key desempenha um papel: se já houver uma mensagem com a mesma chave de recolher (e token de registro) armazenada e aguardando entrega, a mensagem antiga é descartada e a nova mensagem toma 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 é 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 for conectado novamente (por exemplo, se foi redefinido para as configurações 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 nas 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 adequadamente, normalmente solicitando uma sincronização completa do servidor do aplicativo.

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 .

Limitação 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 escalonável para todos os remetentes.

Limitação de mensagem recolhível

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 (limitamos) 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, podemos 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 tais mensagens, certifique-se de incluir o conteúdo em tais mensagens para reduzir o custo da bateria.

Limitamos as mensagens recolhíveis a um burst de 20 mensagens por aplicativo por dispositivo, com uma recarga 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 2500 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 chat. Esse limite evita que erros no envio de lógica descarreguem 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 a 1.500.000/minuto por projeto para evitar a sobrecarga dos servidores de destino upstream.

Limitamos as mensagens upstream por dispositivo em 1.000/minuto para proteger contra o esgotamento da bateria devido ao mau comportamento do aplicativo.

Limite de mensagem de 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 Fanout Throttling .

Estrangulamento em fanout

Distribuição de mensagem é o processo de enviar 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 a fanout das solicitações até que algumas das fanouts já em andamento sejam concluídas.

A taxa de fanout alcançável real é influenciada pelo número de projetos solicitando 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 o seu projeto tiver dois fanouts em andamento, cada fanout verá apenas metade da taxa de fanout disponível. A maneira recomendada de maximizar a velocidade do 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 conectados em 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 de seus usuários. O ideal é permitir as portas 5228-5230 e 443 sem restrições de IP. No entanto, se você precisar ter uma restrição de IP, deverá permitir todos os endereços IP listados em goog.json . Esta grande lista é atualizada regularmente e é recomendável atualizar suas regras mensalmente. 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 ser funcional em seu dispositivo de firewall.

Portas TCP a serem abertas:

  • 5228
  • 5229
  • 5230
  • 443

Hostnames para abrir:

  • 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
  • dispositivo-provisioning.googleapis.com
  • firebaseinstallations.googleapis.com

Firewalls de tradução de endereços de rede e/ou inspeção de pacotes com informações de estado:

Se sua rede implementa Network Address Translation (NAT) ou Stateful Packet Inspection (SPI), 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ê implementa, você pode precisar das seguintes credenciais do seu projeto do Firebase:

ID do projeto Um identificador exclusivo para seu projeto Firebase, usado em solicitações para o endpoint HTTP FCM v1. Esse valor está disponível no painel Configurações do Firebase console .
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 quando você cria seu projeto Firebase, disponível na guia Cloud Messaging do painel Configurações do Firebase console. O ID do remetente é usado 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 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 Firebase console.

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. Android, plataforma Apple e chaves de navegador são rejeitadas pelo FCM.