Em 2026, para nos alinharmos ao nosso modelo de desenvolvimento estável e garantir a estabilidade da plataforma para o ecossistema, vamos publicar o código-fonte no AOSP no segundo e quarto trimestres. Para criar e contribuir com o AOSP, use android-latest-release. A ramificação de manifesto android-latest-release sempre vai referenciar a versão mais recente enviada ao AOSP. Para mais informações, consulte Mudanças no AOSP.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Fracionamento de rede 5G

Em dispositivos com Android 12 ou mais recente, o Android oferece suporte ao fracionamento de rede 5G, que é o uso da virtualização de rede para dividir conexões de rede únicas em várias conexões virtuais distintas que fornecem quantidades diferentes de recursos para tipos de tráfego diferentes. O fatiamento de rede 5G permite que os operadores de rede dediquem uma parte dela para fornecer recursos específicos a um segmento de clientes específico. O Android 12 apresenta os seguintes recursos de fracionamento de rede 5G para empresas, que os operadores de rede podem oferecer aos clientes corporativos:

Divisão de dispositivos empresariais para dispositivos totalmente gerenciados

Para empresas que fornecem dispositivos corporativos totalmente gerenciados aos funcionários, os provedores de rede podem oferecer uma ou mais divisões de rede empresarial ativas para onde o tráfego nos dispositivos da empresa é encaminhado. A partir do Android 12, o Android permite que as operadoras forneçam frações empresariais usando regras de URSP, em vez de configurar frações com APNs.

Divisão de apps empresariais para dispositivos com perfis de trabalho

Para empresas que usam a solução de perfil de trabalho, o Android 12 permite que os dispositivos encaminhem o tráfego de todos os apps no perfil de trabalho para uma fatia de rede empresarial. As empresas podem ativar esse recurso com um controlador de política de dispositivo (DPC).

A solução de perfil de trabalho oferece um nível automático de autenticação e controle de acesso que as empresas precisam para garantir que apenas o tráfego de apps corporativos no perfil de trabalho seja encaminhado para a fatia de rede empresarial. Não é necessário modificar os apps no perfil de trabalho para solicitar explicitamente a fatia de rede empresarial.

Como o fracionamento de rede 5G funciona no AOSP

O Android 12 introduz suporte ao particionamento de rede 5G com adições à base de código de telefonia no AOSP e ao módulo Tethering para incorporar APIs de conectividade atuais necessárias para o particionamento de rede.

A plataforma de telefonia do Android fornece HAL e APIs de telefonia para oferecer suporte ao segmentação com base em solicitações de rede enviadas pelo código de rede principal e recursos de segmentação 5G no modem. A Figura 1 descreve os componentes do recurso de corte de rede 5G.

$Componentes de fracionamento de rede 5G$

Figura 1. Arquitetura de fracionamento de rede 5G no AOSP.

A plataforma de telefonia e conectividade é compatível com:

Converter solicitações de rede para categorias de fatias em descritores de tráfego que são transmitidos ao modem para correspondência de tráfego URSP e seleção de rotas
Voltar para a rede padrão se a fatia de rede empresarial não estiver disponível
Encaminhar o tráfego de todos os apps no perfil de trabalho para a conexão correspondente
Suporte ao fatiamento empresarial
- Detectar a presença de um perfil de trabalho no dispositivo
- Verificar permissões ou rotas fornecidas pelo DPC usado pelo administrador de TI da empresa

O serviço principal de rede inclui as seguintes mudanças no módulo de tethering do Android 12:

Adiciona a maioria das classes de API pública ou do sistema android.net.* ao módulo Tethering
Expande os limites do módulo de tethering para incluir:
- f/b/core/java/android/net/…
- f/b/services/net/…
- f/b/services/core/java/com/android/server/connectivity/…
- f/b/services/core/java/com/android/server/ConnectivityService.java
- f/b/services/core/java/com/android/server/TestNetworkService.java
Move o código da VPN para fora do módulo de tethering.

O Android 12 move o código com os seguintes recursos para o módulo de tethering:

Receber solicitações de apps para conexões de rede
Receber solicitações do sistema (por exemplo, "colocar estes apps em uma fatia empresarial"; introduzido no Android 12)
Envio de solicitações do sistema para o código de telefonia, que tenta configurar redes ou slices passando pela API HAL e pelo modem.
Informar ao netd como rotear o tráfego por app (introduzido no Android 12)
Informar aos apps o que está acontecendo com o tráfego de rede deles usando APIs ConnectivityManager, como NetworkCallback, getActiveNetwork, getNetworkCapabilities.

Implementação

Para oferecer suporte ao fracionamento de rede 5G em um dispositivo, ele precisa ter um modem compatível com o IRadio 1.6 HAL, que tem a API setupDataCall_1_6 (link em inglês). Essa API configura uma conexão de dados e inclui os seguintes parâmetros para oferecer suporte ao fracionamento de rede 5G:

trafficDescriptor: especifica o descritor de tráfego enviado ao modem.
sliceInfo: especifica informações para a fatia de rede a ser usada em caso de transferência de EPDG para 5G.
matchAllRuleAllowed: especifica se é permitido usar uma regra URSP padrão de correspondência total. A telefonia define isso como "true" para redes padrão, mas não para slices. A regra "corresponder a tudo" é aplicada às redes padrão. Quando um app solicita uma parte específica que não está disponível, ela é informada como indisponível. Para apps corporativos, a estrutura Telephony pode voltar à rede padrão se a rede corporativa não estiver disponível.

Os modems também precisam implementar a API getSlicingConfig a menos que ela seja informada como não compatível pela API getHalDeviceCapabilities.

Requisitos empresariais

A seguir, descrevemos os requisitos para que as empresas usem o particionamento de rede 5G em dispositivos em uma implantação do Android Enterprise.

Verifique se os dispositivos totalmente gerenciados ou dos funcionários configurados com um perfil de trabalho são compatíveis com 5G SA e têm modems que oferecem suporte à API setupDataCall_1_6.
Trabalhe com um parceiro de operadora na configuração e no desempenho da fatia ou nas características do SLA.

Ativar o fracionamento de rede 5G em dispositivos configurados com um perfil de trabalho

Em dispositivos configurados com perfis de trabalho, o particionamento de rede 5G fica desativado por padrão no AOSP. Para ativar o fracionamento de rede, os administradores de TI corporativos podem ativar ou desativar o roteamento de tráfego de apps do perfil de trabalho para a fração de rede corporativa em uma base por funcionário pelo DPC do EMM, que usa o método setPreferentialNetworkServiceEnabled na API DevicePolicyManager (DPM) (introduzida no Android 12).

Os fornecedores de EMMs com DPCs personalizados precisam integrar a API DevicePolicyManager para oferecer suporte a clientes empresariais.

Regras da URSP

Esta seção inclui informações para operadoras sobre como configurar regras de URSP para diferentes categorias de slices, incluindo tráfego corporativo, CBS, baixa latência, alta largura de banda e comunicações unificadas.

Ao configurar regras de URSP, as operadoras podem usar descritores de tráfego com base nestes fatores:

Tipo de ID do SO e ID do app do SO, tipo de componente 0x08, compatível com o Android 12 e versões mais recentes
Tipo de recursos de conexão, tipo de componente 0x90, compatível com Android 17 e versões mais recentes

ID do SO e ID do app do SO

Ao configurar regras de URSP usando o componente descritor de tráfego do tipo ID do SO e ID do app do SO, as operadoras podem usar os seguintes valores de ID do SO e ID do app do SO específicos do Android.

ID	Valor	Descrição
ID do SO	`97a498e3-fc92-5c94-8986-0333d06e4e47`	O ID do SO para Android é um UUID da versão 5 gerado com o namespace ISO OID e o nome Android.

As operadoras que configuram regras de URSP usando o ID do SO e o ID do app do SO precisam configurar cada tráfego de slice com o componente descritor de tráfego como uma concatenação do ID do SO, do comprimento do ID do app do SO (0x0A) e do ID do app do SO. Por exemplo, a fração ENTERPRISE precisa ter um valor de 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345. Para mais informações sobre o tipo de componente do descritor de tráfego, consulte 3GPP TS 24.526 Tabela 5.2.1.

A tabela a seguir descreve os valores de OSAppId para diferentes categorias de fração.

Categoria de intervalo	OSAppId	Descrição
`ENTERPRISE`	`0x454E5445525052495345`	O OSAppId é uma representação de matriz de bytes da string `ENTERPRISE`.
`ENTERPRISE2`	`0x454E544552505249534532`	O OSAppId é uma representação de matriz de bytes da string `ENTERPRISE2`.
`ENTERPRISE3`	`0x454E544552505249534533`	O OSAppId é uma representação de matriz de bytes da string `ENTERPRISE3`.
`ENTERPRISE4`	`0x454E544552505249534534`	O OSAppId é uma representação de matriz de bytes da string `ENTERPRISE4`.
`ENTERPRISE5`	`0x454E544552505249534535`	O OSAppId é uma representação de matriz de bytes da string `ENTERPRISE5`.
`CBS`	`0x434253`	O OSAppId é uma representação de matriz de bytes da string `CBS`.
`PRIORITIZE_LATENCY`	`0x5052494f524954495a455f4c4154454e4359`	O OSAppId é uma representação de matriz de bytes da string `PRIORITIZE_LATENCY`.
`PRIORITIZE_BANDWIDTH`	`0x5052494f524954495a455f42414e445749445448`	O OSAppId é uma representação de matriz de bytes da string `PRIORITIZE_BANDWIDTH`.
`PRIORITIZE_UNIFIED_COMMUNICATIONS`	`0x5052494f524954495a455f554e49464945445f434f4d4d554e49434154494f4e53`	O OSAppId é uma representação de matriz de bytes da string `PRIORITIZE_UNIFIED_COMMUNICATIONS`.

O Android não planeja introduzir novos valores de OSAppId no futuro. Em vez disso, o Android vai melhorar o descritor de tráfego de recursos de conexão conforme necessário. ### Recursos de conexão {:#connection-capabilities} A partir do Android 17 e versões mais recentes (AIDL 2.5 e mais recentes da HAL de rádio), o Android oferece suporte ao componente descritor de tráfego de recursos de conexão (tipo "0x90"), definido na [Tabela 5.2.1 do 3GPP TS 24.526][3gpp-ts-24-526]. Quando um app ou serviço do sistema solicita uma rede com uma capacidade específica, a pilha de dados de telefonia do Android mapeia as [`NetworkCapabilities`][network-capabilities] solicitadas para um valor de capacidade de conexão padrão preenchido no [`TrafficDescriptor`][traffic-descriptor] enviado ao modem durante a configuração da chamada de dados (`setupDataCall`). Embora a especificação 3GPP permita várias capacidades de conexão em um único descritor, a estrutura de telefonia do Android 17 mapeia as várias capacidades de conexão solicitadas para uma única capacidade de conexão. A tabela a seguir descreve o mapeamento padrão de recursos de rede do Android para recursos de conexão 3GPP:

Capacidade da rede	Capacidade de conexão	Valor (hexadecimal ou decimal)	Descrição
`NET_CAPABILITY_IMS`	`CONNECTION_CAPABILITY_IMS`	`0x01` (1)	Comunicações de voz e vídeo por IMS
`NET_CAPABILITY_MMS`	`CONNECTION_CAPABILITY_MMS`	`0x02` (2)	Tráfego de MMS
`NET_CAPABILITY_SUPL`	`CONNECTION_CAPABILITY_SUPL`	`0x04` (4)	Localização do plano de usuário seguro (SUPL)
`NET_CAPABILITY_INTERNET`	`CONNECTION_CAPABILITY_INTERNET`	`0x08` (8)	Tráfego de dados da Internet padrão
`NET_CAPABILITY_PRIORITIZE_LATENCY`	`CONNECTION_CAPABILITY_REAL_TIME_INTERACTIVE`	`0xA6` (166)	Tráfego interativo em tempo real (por exemplo, jogos, AR/VR)
`NET_CAPABILITY_PRIORITIZE_BANDWIDTH`	`CONNECTION_CAPABILITY_DOWNLINK_STREAMING`	`0xA3` (163)	Tráfego de streaming de alta largura de banda de downlink
`NET_CAPABILITY_PRIORITIZE_UNIFIED_COMMUNICATIONS`	`CONNECTION_CAPABILITY_UNIFIED_COMMUNICATIONS`	`0xA7` (167)	Comunicações unificadas (por exemplo, chamadas de voz ou vídeo OTT)

Configuração de URSP da operadora e compatibilidade com versões anteriores

Para garantir uma operação perfeita em dispositivos com diferentes versões de HAL e SO, as operadoras precisam considerar o seguinte comportamento ao provisionar regras de URSP:

Dispositivos com Android 16 ou versões anteriores (AIDL HAL de rádio 2.4 e versões anteriores): o modem recebe pelo menos o OSAppId no descritor de tráfego.
Dispositivos com Android 17 ou mais recente (AIDL 2.5 e mais recente): para recursos de slice premium (como baixa latência, alta largura de banda e comunicações unificadas), a plataforma preenche OSAppId, ConnectionCapability ou ambos no descritor de tráfego.

As operadoras podem configurar regras de URSP usando uma das seguintes abordagens:

Regras baseadas em precedência (recomendadas):
- Regra A (precedência maior, número de precedência menor, por exemplo, 10): corresponde às capacidades de conexão (por exemplo, 0xA6 para baixa latência, 0xA3 para alta largura de banda ou 0xA7 para comunicações unificadas). Dispositivos com Android 17 e versões mais recentes correspondem a essa regra primeiro.
- Regra B (precedência menor, número de precedência maior, por exemplo, 20): corresponde ao ID do SO e ao tipo de ID do app do SO (por exemplo, PRIORITIZE_LATENCY). Dispositivos mais antigos que não oferecem suporte à capacidade de conexão no HAL correspondem a essa regra de substituição.
Regra somente com ID do app do SO (legado):
- As operadoras podem continuar usando as regras URSP atuais com base no ID do SO e no ID do app do SO. Como os dispositivos com Android 17 e versões mais recentes continuam passando no OSAppId, tanto os dispositivos novos quanto os mais antigos correspondem a essas regras.
Regra combinada (condição AND):
- As operadoras podem especificar o ID do SO e o ID do app do SO, além de recursos de conexão em um único descritor de tráfego. Essa regra só corresponde a dispositivos com o Android 17 ou mais recente com AIDL 2.5 e versões mais recentes.

Exemplos de regras da URSP

As tabelas a seguir mostram exemplos de regras de URSP para empresas, CBS, baixa latência, alta largura de banda, comunicações unificadas e tráfego padrão.

Empresa 1

O suporte para o Enterprise 1 está disponível no Android 12 e em versões mais recentes. Confira a seguir um exemplo de regra de URSP para tráfego ENTERPRISE1:

Regra URSP 1 (ENTERPRISE1)
Precedência	`1 (0x01)`
Descritor de tráfego nº 1
ID do SO + tipo de ID do app do SO	0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY
Componente 2: DNN	enterprise
Descritor de seleção de rota nº 2
Precedência	`2 (0x02)`
Componente 1: DNN	enterprise

Enterprise 2

O suporte para o Enterprise 2 está disponível no Android 13 e versões mais recentes. Confira a seguir um exemplo de regra de URSP para tráfego ENTERPRISE2:

Regra URSP 2 (ENTERPRISE2)
Precedência	`2 (0x02)`
Descritor de tráfego nº 1
ID do SO + tipo de ID do app do SO	0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY
Componente 2: DNN	enterprise2
Descritor de seleção de rota nº 2
Precedência	`2 (0x02)`
Componente 1: DNN	enterprise2

Enterprise 3

O suporte para o Enterprise 3 está disponível no Android 13 e versões mais recentes. Confira a seguir um exemplo de regra de URSP para tráfego ENTERPRISE3:

Regra URSP 3 (ENTERPRISE3)
Precedência	`3 (0x03)`
Descritor de tráfego nº 1
ID do SO + tipo de ID do app do SO	0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY
Componente 2: DNN	enterprise3
Descritor de seleção de rota nº 2
Precedência	`2 (0x02)`
Componente 1: DNN	enterprise3

Enterprise 4

O suporte para o Enterprise 4 está disponível no Android 13 e versões mais recentes. Confira a seguir um exemplo de regra de URSP para tráfego ENTERPRISE4:

Regra URSP 4 (ENTERPRISE4)
Precedência	`4 (0x04)`
Descritor de tráfego nº 1
ID do SO + tipo de ID do app do SO	0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY
Componente 2: DNN	enterprise4
Descritor de seleção de rota nº 2
Precedência	`2 (0x02)`
Componente 1: DNN	enterprise4

Enterprise 5

O suporte ao Enterprise 5 está disponível no Android 13 e versões mais recentes. Confira a seguir um exemplo de regra de URSP para tráfego ENTERPRISE5:

Regra 5 da URSP (ENTERPRISE5)
Precedência	`5 (0x05)`
Descritor de tráfego nº 1
ID do SO + tipo de ID do app do SO	0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY
Componente 2: DNN	enterprise5
Descritor de seleção de rota nº 2
Precedência	`2 (0x02)`
Componente 1: DNN	enterprise5

CBS

O suporte ao CBS está disponível no Android 13 e versões mais recentes. Confira a seguir um exemplo de regra de URSP para tráfego de CBS:

Regra 6 da URSP (CBS)
Precedência	`6 (0x06)`
Descritor de tráfego nº 1
ID do SO + tipo de ID do app do SO	0x97A498E3FC925C9489860333D06E4E4703434253
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY
Componente 2: DNN	cbs
Descritor de seleção de rota nº 2
Precedência	`2 (0x02)`
Componente 1: DNN	cbs

Baixa latência com capacidade de conexão

O suporte para recursos de conexão em regras URSP está disponível no Android 17 e versões mais recentes. Confira a seguir um exemplo de regra URSP para tráfego de baixa latência usando o descritor de recursos de conexão:

Regra 7 da URSP (baixa latência com capacidade de conexão)
Precedência	`7 (0x07)`
Descritor de tráfego nº 1
Tipo de recursos de conexão	0xA6 (166: interativo em tempo real)
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY
Componente 2: DNN	latência
Descritor de seleção de rota nº 2
Precedência	`2 (0x02)`
Componente 1: DNN	latência

Baixa latência com OSAppId

O suporte para baixa latência está disponível no Android 13 e versões mais recentes. Confira a seguir um exemplo de regra de URSP para tráfego de LOW_LATENCY usando OSAppId:

Regra 8 da URSP (baixa latência com fallback de OSAppId)
Precedência	`8 (0x08)`
Descritor de tráfego nº 1
ID do SO + tipo de ID do app do SO	0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY
Componente 2: DNN	latência
Descritor de seleção de rota nº 2
Precedência	`2 (0x02)`
Componente 1: DNN	latência

Alta largura de banda com capacidade de conexão

O suporte para recursos de conexão em regras URSP está disponível no Android 17 e versões mais recentes. Confira a seguir um exemplo de regra URSP para tráfego de alta largura de banda usando o descritor de recursos de conexão:

Regra 9 do URSP (alta largura de banda com capacidade de conexão)
Precedência	`9 (0x09)`
Descritor de tráfego nº 1
Tipo de recursos de conexão	0xA3 (163: streaming de downlink)
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY
Componente 2: DNN	bandwidth
Descritor de seleção de rota nº 2
Precedência	`2 (0x02)`
Componente 1: DNN	bandwidth

Alta largura de banda com OSAppId

O suporte a alta largura de banda está disponível no Android 13 e versões mais recentes. Confira a seguir um exemplo de regra de URSP para tráfego de HIGH_BANDWIDTH usando OSAppId:

Regra 10 do URSP (alta largura de banda com fallback de OSAppId)
Precedência	`10 (0x0A)`
Descritor de tráfego nº 1
ID do SO + tipo de ID do app do SO	0x97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY
Componente 2: DNN	bandwidth
Descritor de seleção de rota nº 2
Precedência	`2 (0x02)`
Componente 1: DNN	bandwidth

Comunicações unificadas com capacidade de conexão

O suporte para comunicações unificadas está disponível no Android 17 e versões mais recentes. Confira a seguir um exemplo de regra URSP para tráfego UNIFIED_COMMUNICATIONS usando a capacidade de conexão. Como o tráfego de comunicações unificadas é roteado pela conexão de dados padrão da Internet, não é necessário um APN (DNN) dedicado no descritor de seleção de rota:

Regra 11 do URSP (comunicações unificadas com capacidade de conexão)
Precedência	`11 (0x0B)`
Descritor de tráfego nº 1
Tipo de recursos de conexão	0xA7 (167: Comunicações unificadas)
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY

Comunicações unificadas com OSAppId

O suporte para comunicações unificadas está disponível no Android 17 e versões mais recentes. Confira a seguir um exemplo de regra URSP para tráfego UNIFIED_COMMUNICATIONS usando OSAppId:

Regra URSP 12 (comunicações unificadas com substituição de OSAppId)
Precedência	`12 (0x0C)`
Descritor de tráfego nº 1
ID do SO + tipo de ID do app do SO	0x97A498E3FC925C9489860333D06E4E47215052494F524954495A455F554E49464945445F434F4D4D554E49434154494F4E53
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY

Padrão

Regra URSP 13 (padrão)
Precedência	`13 (0x0D)`
Descritor de tráfego nº 1
match-all	N/A
Descritor de seleção de rota nº 1
Precedência	`1 (0x01)`
Componente nº 1: S-NSSAI	SST:XX SD:YYYYYY

Teste

Para testar o particionamento de rede 5G, use o seguinte teste manual.

Para configurar um dispositivo para teste, faça o seguinte:

Verifique se a política de URSP está configurada com uma regra não padrão que corresponde à categoria da empresa e se o descritor de seleção de rota correspondente mapeia a categoria da empresa para a fração empresarial. Além disso, confira se há uma regra padrão direcionando o tráfego para a fração de Internet padrão.
Verifique se um perfil de trabalho está configurado no dispositivo.
Ativar o uso do particionamento de rede pela DPC

Para testar o comportamento do fracionamento de rede 5G, faça o seguinte:

Verifique se uma sessão de PDU foi estabelecida com a faixa empresarial (por exemplo, usando um endereço IP específico) e se os apps no perfil de trabalho usam essa sessão de PDU.
Verifique se uma sessão de PDU separada foi estabelecida com a fatia de Internet padrão e se os apps no perfil pessoal usam a sessão de PDU.

Upsell por fracionamento de rede 5G

O recurso de upsell por fracionamento de rede 5G, disponível no Android 14 QPR1, permite que as operadoras ofereçam recursos de rede aprimorados (latência e largura de banda) aos usuários com o fracionamento de rede 5G.

O recurso de upselling de fracionamento de rede 5G usa a resposta TS.43 do servidor de direitos da operadora para impulsionar o fluxo de compra. As operadoras podem usar a resposta para especificar o URL da webview de compra da operadora, enviar dados adicionais para a webview e indicar se a fatia foi provisionada e está disponível na rede da operadora.

As operadoras podem personalizar o comportamento do recurso de upsell de fracionamento de rede 5G usando configurações da operadora, que controlam se as solicitações de compra podem ser feitas, quando os apps podem solicitar recursos premium e por quanto tempo o framework de telefonia espera respostas do usuário ou da rede.

O recurso de upselling de fracionamento de rede 5G oferece uma interface chamada DataBoostWebServiceFlow, para permitir a comunicação entre o Android e a WebView da operadora.

A Figura 2 mostra o fluxo de compra do upsell por fracionamento de rede 5G:

$Fluxo de compra de upsell por fracionamento de rede 5G$

Figura 2. Fluxo de compra de upsell por fracionamento de rede 5G.

Processo de direito TS.43

Quando um usuário faz uma solicitação de recursos de rede aprimorados, o framework Telephony solicita a configuração de direito de serviço para o recurso premium solicitado. Se a resposta TS.43 for válida, o framework Telephony usará os campos da resposta HTTP para direcionar o pedido de aprovação de compra.

Segmentar campos de compra

A configuração de direitos do TS.43 inclui os seguintes campos de compra de frações:

Status de titularidade: Chave: EntitlementStatus; Tipo: int; Valores aceitos: 0 (desativado), 1 (ativado), 2 (incompatível), 3 (provisionamento), 4 (incluído)
Status do provisionamento: Chave: ProvStatus; Tipo: int; Valores aceitos: 0 (não provisionado), 1 (provisionado), 2 (não disponível), 3 (em andamento)

O framework de telefonia usa a combinação do status de direito e provisionamento para determinar o estado atual da compra de uma fatia. O resultado pode ser um dos seguintes:

Se o status do direito for 1 (ativado) e o status do provisionamento for 0 (não provisionado), o framework Telephony vai mostrar uma notificação de upselling para o usuário comprar o pacote extra pela WebView da operadora. A tabela a seguir descreve o comportamento da estrutura de telefonia para diferentes combinações de valores de status de provisionamento e direitos.

		Status do provisionamento
		Não provisionado (`0`)	Provisionado (`1`)	Não disponível (`2`)	Em andamento (`3`)
Status do direito	Desativado (`0`)	Falha	Com falha	Com falha	Falha
	Ativado (`1`)	Mostrar WebView	Já comprei	Já comprei	Em andamento
	Incompatível (`2`)	Falha	Com falha	Com falha	Falha
	Provisionamento (`3`)	Erro da transportadora	Erro da transportadora	Em andamento	Em andamento
	Incluído (`4`)	Erro da transportadora	Já comprei	Já comprei	Erro da transportadora

Campos de fluxo de serviço

A resposta TS.43 especifica o URL, os dados do usuário e o tipo de conteúdo para personalizar o comportamento da WebView de compra da operadora. Se o tipo de conteúdo não for especificado, o URL será carregado como uma solicitação GET. Se os dados do usuário existirem, eles serão anexados ao URL como um parâmetro de consulta (por exemplo, https://www.android.com?encodedValue=Base64EncodedUserData). Se não existirem, o URL será usado no estado em que se encontra (por exemplo, https://www.android.com).
Se o tipo de conteúdo for especificado no formato JSON ou XML, o URL será carregado como uma solicitação POST, e os dados do usuário (decodificados se estiverem codificados em Base 64) serão enviados como os dados da solicitação POST.

URL: Chave: ServiceFlow_URL; Tipo: String; Exemplo: "https://www.android.com"
Dados do usuário: Chave: ServiceFlow_UserData; Tipo: String; Exemplo: "encodedValue=Base64EncodedUserData"
Tipo de conteúdo: Chave: ServiceFlow_ContentsType; Tipo: String; Valores aceitos: 0 (não especificado), 1 (JSON), 2 (XML)

Configurações da operadora

Confira abaixo as configurações de operadora disponíveis para personalizar o comportamento do recurso de upselling de fracionamento da rede 5G.

KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY: Uma lista de recursos premium compatíveis. Essa é uma matriz de números inteiros de TelephonyManager.PremiumCapability. Esses recursos premium compartilham o mesmo valor da classe NetworkCapabilities.NetCapability correspondente. Se uma funcionalidade premium for solicitada e não estiver incluída nessa configuração, o pedido de aprovação de compra vai falhar com o resultado CARRIER_DISABLED.; No Android 14, apenas PREMIUM_CAPABILITY_PRIORITIZE_LATENCY é compatível.
KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT: O número máximo diário de vezes que a notificação de upselling de compra é mostrada ao usuário. Se o máximo diário for atingido, a notificação de upselling não será mostrada, e as solicitações de compra (incluindo as do servidor de direitos) serão limitadas até a meia-noite do dia seguinte. As solicitações de compra feitas depois que o máximo diário é atingido falham com o resultado PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.
KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT: O número máximo de vezes por mês que a notificação de aumento de compra é mostrada ao usuário. Se o máximo mensal for atingido, a notificação de upselling não será mostrada, e as solicitações de compra (incluindo as do servidor de direitos) serão limitadas até o primeiro dia do mês seguinte. As solicitações de compra feitas depois que o máximo mensal é atingido falham com o resultado PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.
KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING: O URL de compra da operadora de backup a ser mostrado ao usuário quando ele clicar na notificação de upselling. Se o URL de compra não for encontrado na resposta TS.43 do servidor de direitos, esse valor será usado. Se nem o URL da resposta TS.43 nem a configuração da operadora forem válidos, o pedido de aprovação de compra vai falhar com o resultado PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.
KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL: Se as funcionalidades premium podem ser compradas quando o dispositivo está conectado ao Long-Term Evolution (LTE). Se true, as solicitações de compra poderão ser feitas em LTE e New Radio (NR). Se false, as solicitações de compra só poderão ser feitas em NR, e as solicitações feitas em LTE vão falhar com o resultado PURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG: O período em que a notificação de upselling de compra é mostrada ao usuário antes de ser cancelada automaticamente. Quando a notificação é cancelada, as solicitações subsequentes são limitadas e falham com o resultado PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.
KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG: O período em que as solicitações de compra subsequentes devem ser limitadas após uma falha devido a tempo limite ou cancelamento do usuário. Se o usuário não clicar na notificação de aumento de compra dentro do tempo limite especificado por KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG ou se ele cancelar ou dispensar a notificação, esse timer de espera vai começar. Enquanto esse timer estiver ativo, as solicitações de compra vão falhar com o resultado PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.
KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG: O período em que as solicitações de compra subsequentes devem ser limitadas após uma falha devido à operadora ou à rede. Se a verificação de direitos falhar, o URL ficar indisponível ou o URL de compra da operadora indicar uma falha, esse timer de espera vai começar. Enquanto esse timer estiver ativo, as solicitações de compra vão falhar com o resultado PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.
KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONG: O período em que a rede precisa configurar uma configuração de segmentação para a capacidade premium de compra. Durante esse período, as solicitações de compra subsequentes são bloqueadas e retornam o resultado PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Se a rede não conseguir configurar uma configuração de segmentação a tempo, os apps poderão solicitar a compra de recursos premium novamente. A telefonia não considera uma compra concluída até que a configuração de segmentação correspondente seja enviada, independente de o usuário ter pago ou não à operadora.

Interface JavaScript

Quando o usuário clica na notificação de aumento de rede, um objeto WebView com o URL de compra da operadora é mostrado ao usuário. As operadoras podem usar as APIs fornecidas na interface Javascript DataBoostWebServiceFlow no site de compra para se comunicar com o app de compra de fatias.

O site da transportadora pode receber o recurso premium solicitado pelo método getRequestedCapability().

Se a compra for concluída, o site da operadora precisará notificar o app de compra de fatias usando notifyPurchaseSuccessful() ou notifyPurchaseSuccessful(duration), em que duration é um parâmetro opcional que indica a duração pretendida da fatia.

Se a compra não for concluída, o site da transportadora precisará notificar o app de compra de trechos usando o método notifyPurchaseFailed(code, reason), em que code é o código de falha que indica o motivo da falha e reason é o motivo da falha legível para humanos se o código de falha for desconhecido.

Se um desses métodos de resposta não for chamado, a compra não será considerada concluída e o pedido de aprovação de compra vai expirar.

Confira os códigos de falha válidos que o site da transportadora pode retornar em caso de falha na compra:

Quando a compra for concluída, a operadora precisará atualizar as regras da URSP com a fração PRIORITIZE_LATENCY no dispositivo do usuário.

Roteamento automático de fracionamento de rede 5G para voz e vídeo OTT

O Android 17 oferece suporte ao roteamento automático de chamadas de voz e vídeo over-the-top (OTT) para conexões de rede premium. Com esse recurso, o sistema direciona automaticamente o tráfego de chamadas de voz e vídeo para uma interface de rede premium dedicada (como uma faixa premium de 5G ou uma conexão PDN 4G premium) sem exigir mudanças na pilha de rede do app.

Essa solução no nível da plataforma elimina a necessidade de os desenvolvedores de apps solicitarem explicitamente recursos de rede, proporcionando uma experiência perfeita para desenvolvedores e usuários finais.

Como funciona

O Android incorpora suporte para roteamento automático com adições aos frameworks de conectividade e telecomunicações. O recurso de roteamento automático funciona da seguinte maneira:

Detecção de chamadas:o sistema usa as APIs Telecom Jetpack atuais usadas por apps OTT para detectar o início e o fim de chamadas de voz ou vídeo.
Gerenciamento de conexão:ao detectar uma chamada, o Android abre uma interface de rede premium designada, como uma fração de comunicação unificada.
Direcionamento de tráfego:durante a chamada, a plataforma identifica o aplicativo pelo UID e direciona automaticamente o tráfego para a conexão de rede premium.
Fallback pós-chamada:quando a chamada termina, a plataforma remove a regra de roteamento, e o tráfego do app volta para a rede padrão do sistema para tráfego que não é de chamada (como mensagens).

Requisitos

Para oferecer suporte ao encaminhamento automático de chamadas OTT, é necessário atender aos seguintes requisitos:

Operadoras:precisam oferecer uma fatia de comunicação unificada configurando regras URSP adequadas (usando capacidade de conexão ou OSAppId para tráfego de comunicação unificada).
Apps:precisam usar as APIs do Android Telecom Jetpack para permitir que o sistema detecte estados de chamada.
Fabricantes de dispositivos:é necessário o Android 17 ou mais recente.