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 empresarial 5G, 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, as operadoras podem fornecer frações empresariais usando regras URSP, em vez de configurar frações usando 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. Os apps no perfil de trabalho não precisam ser modificados para solicitar explicitamente a fatia de rede empresarial.
Como o fracionamento de rede 5G funciona no AOSP
O Android 12 introduz suporte para o particionamento de rede 5G com adições ao código-fonte de telefonia no AOSP e ao módulo de tethering para incorporar as APIs de conectividade 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 rota
- 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 (introduzido 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 particionamento 5G em um dispositivo, ele precisa ter um modem compatível com
o IRadio 1.6 HAL, 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 particionamento 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 fatia 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 particionamento 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 segmentação, incluindo tráfego empresarial, CBS, baixa latência e alta largura de banda. Ao configurar regras de URSP para diferentes categorias de slices, 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 fração | 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". |
Exemplos de regras de 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.
Empresa 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 1 da URSP (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 3 da URSP (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 nº 4 da URSP (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 nº 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 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 nº 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 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 de BAIXA_LATÊNCIA:
| 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 nº 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 que direciona 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 por meio do fracionamento de rede 5G.
O recurso de upselling de segmentação 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 venda cruzada de segmentação 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 aguarda 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 avançados, 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 a solicitação de compra.
Segmentar campos de compra
A configuração de direitos do TS.43 inclui os seguintes campos de compra de fatia:
- Status de titularidade
Tecla:
EntitlementStatusTipo:
intValores aceitos:
0(desativado),1(ativado),2(incompatível),3(provisionamento),4(incluído)- Status do provisionamento
Tecla:
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 na 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 direito.
| Status do provisionamento | |||||
|---|---|---|---|---|---|
Não provisionado (0) |
Provisionado (1 |
Não disponível (2) |
Em andamento (3) |
||
| Status do direito | Desativado (0) |
Falha | Falha | Falha | Falha |
Ativado (1) |
Mostrar WebView | Já comprei | Já comprei | Em andamento | |
Incompatível (2) |
Falha | Falha | 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 como está (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
Tecla:
ServiceFlow_URLTipo:
StringExemplo:
"https://www.android.com"- Dados do usuário
Tecla:
ServiceFlow_UserDataTipo:
StringExemplo:
"encodedValue=Base64EncodedUserData"- Tipo de conteúdo
Tecla:
ServiceFlow_ContentsTypeTipo:
StringValores aceitos:
0(não especificado),1(JSON),2(XML)
Configurações da operadora
Confira a seguir as configurações de operadora disponíveis para personalizar o comportamento do recurso de venda cruzada de segmentação 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, a solicitaçã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 upselling 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, a solicitaçã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 exponencial será iniciado. 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 o recurso 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. 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 operadora pode receber o recurso premium solicitado pelo método
getRequestedCapability().
Se a compra for concluída, o site da operadora vai notificar o app de compra de
pacotes usando notifyPurchaseSuccessful() ou
notifyPurchaseSuccessful(duration), em que duration é um parâmetro opcional
que indica a duração pretendida do pacote.
Se a compra não for concluída, o site da operadora 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 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 URSP com a fração PRIORITIZE_LATENCY no dispositivo do usuário.