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 de tethering para incorporar APIs de conectividade atuais necessárias para o particionamento de rede.
A plataforma de telefonia Android oferece HAL e APIs de telefonia para oferecer suporte a divisão com base em solicitações de rede enviadas pelo código de rede principal e recursos de divisão 5G no modem. A Figura 1 descreve os componentes do recurso de corte 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.javaf/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 (lançado no Android 12)
- Informar aos apps o que está acontecendo com o tráfego de rede deles usando
APIs
ConnectivityManager, comoNetworkCallback,getActiveNetwork,getNetworkCapabilities.
Implementação
Para oferecer suporte ao fracionamento de rede 5G em um dispositivo, ele precisa ter um modem compatível com o HAL IRadio 1.6, que tem a API
setupDataCall_1_6. 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 o fracionamento de rede a ser usado 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 para a 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 empresarial, CBS, de baixa latência e de alta largura de banda. Ao configurar regras de URSP para diferentes categorias de segmentação, as operadoras precisam usar os seguintes valores específicos do Android.
| ID | Valor | Descrição |
|---|---|---|
| OSId | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
O OSId para Android é um UUID da versão 5 gerado com o namespace ISO OID e o nome "Android". |
As operadoras precisam configurar regras de URSP para cada tráfego de slice com o componente
descritor de tráfego como "ID do SO + tipo de ID do app do SO". Por exemplo, a fatia "ENTERPRISE"
precisa ter um valor de
0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345.
Esse valor é uma concatenação do OSId, do comprimento do OSAppId (0x0A) e do OSAppId.
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. |
Exemplos de regras da URSP
As tabelas a seguir mostram exemplos de regras de URSP para tráfego empresarial, CBS, de baixa latência, de alta largura de banda e padrão.
Enterprise 1
O suporte para o Enterprise 1 está disponível no Android 12 e em versões mais recentes. Confira um exemplo de regra URSP para tráfego ENTERPRISE1:
| Regra URSP nº 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 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 um exemplo de regra URSP para tráfego ENTERPRISE2:
| Regra URSP nº 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 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 do ENTERPRISE3:
| Regra URSP nº 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 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 da URSP para tráfego do ENTERPRISE4:
| Regra URSP nº 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 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 um exemplo de regra URSP para tráfego ENTERPRISE5:
| Regra URSP nº 5 (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 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 URSP nº 6 (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 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
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 LOW_LATENCY:
| Regra URSP nº 7 (baixa latência) | |
|---|---|
| Precedência | 7 (0x07) |
| 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 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
O suporte para alta largura de banda está disponível no Android 13 e versões mais recentes. Confira a seguir um exemplo de regra URSP para tráfego de ALTA_LARGURA_DE_BANDA:
| Regra 8 da URSP (alta largura de banda) | |
|---|---|
| Precedência | 8 (0x08) |
| Descritor de tráfego nº 1 | |
| ID do SO + tipo de ID do app do SO | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente 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 |
Padrão
| Regra URSP nº 9 (padrão) | |
|---|---|
| Precedência | 9 (0x09) |
| Descritor de tráfego nº 1 | |
| match-all | N/A |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente 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 upsell 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:
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:
EntitlementStatusTipo:
intValores aceitos:
0(desativado),1(ativado),2(incompatível),3(provisionamento),4(incluído)- Status do provisionamento
Chave:
ProvStatusTipo:
intValores 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:
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASEDPURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESSPURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILEDPURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
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_URLTipo:
StringExemplo:
"https://www.android.com"- Dados do usuário
Chave:
ServiceFlow_UserDataTipo:
StringExemplo:
"encodedValue=Base64EncodedUserData"- Tipo de conteúdo
Chave:
ServiceFlow_ContentsTypeTipo:
StringValores 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 upsell de fracionamento de rede 5G.
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAYUma lista de recursos premium compatíveis. Essa é uma matriz de números inteiros de
TelephonyManager.PremiumCapability. Esses recursos premium compartilham o mesmo valor da classeNetworkCapabilities.NetCapabilitycorrespondente. 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 resultadoCARRIER_DISABLED.No Android 14, apenas
PREMIUM_CAPABILITY_PRIORITIZE_LATENCYé compatível.KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INTO 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 os pedidos de compra (incluindo solicitações do servidor de direitos) serão limitados 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_INTO 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_STRINGO 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_BOOLSe 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). Sefalse, as solicitações de compra só poderão ser feitas em NR, e as solicitações feitas em LTE vão falhar com o resultadoPURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGO 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_LONGO 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_LONGou 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 resultadoPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGO 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_LONGO 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 bem-sucedida, o site da operadora vai 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:
FAILURE_CODE_UNKNOWNFAILURE_CODE_CARRIER_URL_UNAVAILABLEFAILURE_CODE_AUTHENTICATION_FAILEDFAILURE_CODE_PAYMENT_FAILEDFAILURE_CODE_NO_USER_DATA
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 fatia 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. As operadoras precisam preencher a URSP com um
OSAppIDespecífico para o 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.