Para dispositivos com Android 12 ou superior, o Android oferece suporte para fatiamento de rede 5G, o uso de virtualização de rede para dividir conexões de rede únicas em múltiplas conexões virtuais distintas que fornecem diferentes quantidades de recursos para diferentes tipos de tráfego. O fatiamento da rede 5G permite que as operadoras de rede dediquem uma parte da rede para fornecer recursos específicos para um determinado segmento de clientes. O Android 12 apresenta os seguintes recursos de fatiamento de rede empresarial 5G, que as operadoras de rede podem fornecer aos seus clientes empresariais:
Fatiamento de dispositivos corporativos para dispositivos totalmente gerenciados
Para empresas que fornecem dispositivos empresariais totalmente gerenciados a seus funcionários, os provedores de rede podem fornecer-lhes uma ou mais fatias de rede corporativa ativas para onde o tráfego nos dispositivos da empresa é roteado. A partir do Android 12, o Android permite que as operadoras forneçam fatias empresariais por meio de regras URSP, em vez de configurar fatias por meio de APNs.
Fatiamento de aplicativos empresariais 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 roteem o tráfego de todos os aplicativos no perfil de trabalho para uma fatia da rede corporativa. As empresas podem ativar esse recurso por meio de um Device Policy Controller (DPC) .
A solução de perfil de trabalho fornece um nível automático de autenticação e controle de acesso que as empresas exigem para garantir que apenas o tráfego de aplicativos empresariais no perfil de trabalho seja roteado para a fatia da rede corporativa. Os aplicativos no perfil de trabalho não precisam ser modificados para solicitar explicitamente a fatia da rede corporativa.
Como funciona o fatiamento de rede 5G no AOSP
O Android 12 introduz suporte para fatiamento de rede 5G por meio de adições à base de código de telefonia no AOSP e ao módulo Tethering para incorporar APIs de conectividade existentes que são necessárias para o fatiamento de rede.
A plataforma de telefonia Android fornece HAL e APIs de telefonia para oferecer suporte ao fatiamento com base em solicitações de rede enviadas pelo código de rede principal e recursos de fatiamento 5G no modem. A Figura 1 descreve os componentes do recurso de fatiamento da rede 5G.
Figura 1. Arquitetura de fatiamento de rede 5G em AOSP.
A plataforma de telefonia e conectividade suporta:
- Converter solicitações de rede para categorias de fatias em descritores de tráfego que são então passados ao modem para correspondência de tráfego URSP e seleção de rota
- Voltar para a rede padrão se a fatia da rede corporativa não estiver disponível
- Rotear o tráfego de todos os aplicativos no perfil de trabalho para a conexão correspondente
Apoiando o fatiamento empresarial
- Detectando a presença de um perfil de trabalho no dispositivo
- Verificação de permissões ou instruções de roteamento fornecidas pelo DPC usado pelo administrador de TI da empresa
O serviço de rede principal inclui as seguintes alterações no módulo Tethering no Android 12:
- Adiciona a maioria das classes de API públicas ou do sistema
android.net.*ao módulo Tethering Expande os limites do módulo 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 VPN para fora do módulo Tethering
O Android 12 move o código com os seguintes recursos para o módulo Tethering:
- Recebendo solicitações de aplicativos para conexões de rede
- Receber solicitações do sistema (por exemplo, "colocar esses apps em uma fatia corporativa"; 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
- Informando ao netd como rotear o tráfego por aplicativo (introduzido no Android 12)
- Informar os aplicativos sobre o que está acontecendo com o tráfego de rede por meio de APIs
ConnectivityManager, comoNetworkCallback,getActiveNetwork,getNetworkCapabilities.
Implementação
Para oferecer suporte ao fatiamento 5G em um dispositivo, o dispositivo deve ter um modem compatível com IRadio 1.6 HAL que possui a API setupDataCall_1_6 . Esta API configura uma conexão de dados e inclui os seguintes parâmetros para dar suporte ao fatiamento 5G:
-
trafficDescriptor: Especifica o descritor de tráfego enviado ao modem -
sliceInfo: Especifica informações para a fatia de rede a ser usada no caso de transferência de EPDG para 5G -
matchAllRuleAllowed: especifica se o uso de uma regra URSP padrão de correspondência de todos é permitido. A telefonia define isso como verdadeiro para redes padrão, mas não para fatias. A regra combinar tudo é aplicada às redes padrão. Quando um aplicativo solicita uma fatia específica que não está disponível, a fatia específica é relatada como não disponível. Para aplicações empresariais, a estrutura de Telefonia pode recorrer à rede padrão se a rede empresarial não estiver disponível.
Os modems também devem implementar a API getSlicingConfig , a menos que seja relatado como não suportado pela API getHalDeviceCapabilities .
Requisitos empresariais
Veja a seguir os requisitos para que as empresas usem o fatiamento de rede 5G em dispositivos em uma implantação empresarial do Android.
- Certifique-se de que os dispositivos totalmente gerenciados ou de funcionários configurados com um perfil de trabalho sejam compatíveis com 5G SA com modems que suportam a API
setupDataCall_1_6. - Trabalhe com a operadora parceira na configuração e desempenho do slice ou nas características do SLA.
Habilitar fatiamento 5G em dispositivos configurados com perfil de trabalho
Para dispositivos configurados com perfis de trabalho, o fatiamento da rede 5G está desativado por padrão no AOSP. Para ativar o fatiamento da rede, os administradores de TI corporativos podem ativar ou desativar o roteamento de tráfego do aplicativo do perfil de trabalho para o fatiamento da rede corporativa por funcionário por meio do EMM DPC, que usa o método setPreferentialNetworkServiceEnabled na API DevicePolicyManager (DPM) (introduzida no Android 12).
Os fornecedores de EMM com DPCs personalizados devem integrar a API DevicePolicyManager para oferecer suporte a clientes corporativos.
Regras da URSP
Esta seção inclui informações para operadoras sobre como configurar regras URSP para diferentes categorias de fatia, incluindo tráfego empresarial, CBS, baixa latência e alta largura de banda. Ao configurar regras URSP para diferentes categorias de fatias, as operadoras devem usar os seguintes valores específicos do Android.
| EU IA | Valor | Descrição |
|---|---|---|
| OSId | 97a498e3-fc92-5c94-8986-0333d06e4e47 | O OSId para Android é um UUID versão 5 gerado com o namespace ISO OID e o nome "Android". |
As operadoras devem configurar regras URSP para cada fatia de tráfego com o componente descritor de tráfego como "OS Id + OS App Id type". Por exemplo, a fatia "ENTERPRISE" deve ter um valor de 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 . Este valor é uma concatenação do OSId, do comprimento do OSAppId ( 0x0A ) e do OSAppId. Para obter mais informações sobre o tipo de componente descritor de tráfego, consulte 3GPP TS 24.526 Tabela 5.2.1 .
A tabela a seguir descreve os valores OSAppId para diferentes categorias de fatia.
| Categoria de fatia | OSAppId | Descrição |
|---|---|---|
| EMPREENDIMENTO | 0x454E5445525052495345 | O OSAppId é uma representação de array de bytes da string "ENTERPRISE" |
| EMPRESA2 | 0x454E544552505249534532 | O OSAppId é uma representação de array de bytes da string "ENTERPRISE2" |
| EMPRESA3 | 0x454E544552505249534533 | O OSAppId é uma representação de array de bytes da string "ENTERPRISE3" |
| EMPRESA4 | 0x454E544552505249534534 | O OSAppId é uma representação de array de bytes da string "ENTERPRISE4" |
| EMPRESA5 | 0x454E544552505249534535 | O OSAppId é uma representação de array de bytes da string "ENTERPRISE5" |
| CBS | 0x434253 | O OSAppId é uma representação de array de bytes da string "CBS" |
| PRIORITIZE_LATENCY | 0x5052494f524954495a455f4c4154454e4359 | O OSAppId é uma representação de array de bytes da string "PRIORITIZE_LATENCY" |
| PRIORITIZE_BANDWIDTH | 0x5052494f524954495a455f42414e445749445448 | O OSAppId é uma representação de array de bytes da string "PRIORITIZE_BANDWIDTH" |
Exemplo de regras URSP
As tabelas a seguir mostram exemplos de regras URSP para tráfego corporativo, CBS, baixa latência, alta largura de banda e tráfego padrão.
Empresa 1
O suporte para Enterprise 1 está disponível no Android 12 e superior. A seguir está um exemplo de regra URSP para tráfego ENTERPRISE1:
| Regra URSP nº 1 (empresa1) | |
|---|---|
| Precedência | 1 (0x01) |
| Descritor de tráfego nº 1 | |
| ID do SO + tipo de ID do aplicativo do SO | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente nº 1: S-NSSAI | SST:XX SD:AAAA |
| Componente nº 2: DNN | empreendimento |
| Descritor de seleção de rota nº 2 | |
| Precedência | 2 (0x02) |
| Componente nº 1: DNN | empreendimento |
Empresa 2
O suporte para Enterprise 2 está disponível no Android 13 e superior. A seguir está um exemplo de regra URSP para tráfego ENTERPRISE2:
| Regra URSP nº 2 (empresa2) | |
|---|---|
| Precedência | 2 (0x02) |
| Descritor de tráfego nº 1 | |
| ID do SO + tipo de ID do aplicativo do SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente nº 1: S-NSSAI | SST:XX SD:AAAA |
| Componente nº 2: DNN | empresa2 |
| Descritor de seleção de rota nº 2 | |
| Precedência | 2 (0x02) |
| Componente nº 1: DNN | empresa2 |
Empresa 3
O suporte para Enterprise 3 está disponível no Android 13 e superior. A seguir está um exemplo de regra URSP para tráfego ENTERPRISE3:
| Regra URSP nº 3 (empresa3) | |
|---|---|
| Precedência | 3 (0x03) |
| Descritor de tráfego nº 1 | |
| ID do SO + tipo de ID do aplicativo do SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente nº 1: S-NSSAI | SST:XX SD:AAAA |
| Componente nº 2: DNN | empresa3 |
| Descritor de seleção de rota nº 2 | |
| Precedência | 2 (0x02) |
| Componente nº 1: DNN | empresa3 |
Empresa 4
O suporte para Enterprise 4 está disponível no Android 13 e superior. A seguir está um exemplo de regra URSP para tráfego ENTERPRISE4:
| Regra URSP nº 4 (empresa4) | |
|---|---|
| Precedência | 4 (0x04) |
| Descritor de tráfego nº 1 | |
| ID do SO + tipo de ID do aplicativo do SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente nº 1: S-NSSAI | SST:XX SD:AAAA |
| Componente nº 2: DNN | empresa4 |
| Descritor de seleção de rota nº 2 | |
| Precedência | 2 (0x02) |
| Componente nº 1: DNN | empresa4 |
Empresa 5
O suporte para Enterprise 5 está disponível no Android 13 e superior. A seguir está um exemplo de regra URSP para tráfego ENTERPRISE5:
| Regra URSP nº 5 (empresa5) | |
|---|---|
| Precedência | 5 (0x05) |
| Descritor de tráfego nº 1 | |
| ID do SO + tipo de ID do aplicativo do SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente nº 1: S-NSSAI | SST:XX SD:AAAA |
| Componente nº 2: DNN | empresa5 |
| Descritor de seleção de rota nº 2 | |
| Precedência | 2 (0x02) |
| Componente nº 1: DNN | empresa5 |
CBS
O suporte para CBS está disponível no Android 13 e superior. A seguir está um exemplo de regra URSP para tráfego CBS:
| Regra URSP nº 6 (CBS) | |
|---|---|
| Precedência | 6 (0x06) |
| Descritor de tráfego nº 1 | |
| ID do SO + tipo de ID do aplicativo do SO | 0x97A498E3FC925C9489860333D06E4E4703434253 |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente nº 1: S-NSSAI | SST:XX SD:AAAA |
| Componente nº 2: DNN | cbs |
| Descritor de seleção de rota nº 2 | |
| Precedência | 2 (0x02) |
| Componente nº 1: DNN | cbs |
Baixa latência
O suporte para baixa latência está disponível no Android 13 e superior. A seguir está um exemplo de regra 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 aplicativo do SO | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente nº 1: S-NSSAI | SST:XX SD:AAAA |
| Componente nº 2: DNN | latência |
| Descritor de seleção de rota nº 2 | |
| Precedência | 2 (0x02) |
| Componente nº 1: DNN | latência |
Alta largura de banda
O suporte para alta largura de banda está disponível no Android 13 e superior. A seguir está um exemplo de regra URSP para tráfego HIGH_BANDWIDTH:
| Regra URSP nº 8 (alta largura de banda) | |
|---|---|
| Precedência | 8 (0x08) |
| Descritor de tráfego nº 1 | |
| ID do SO + tipo de ID do aplicativo do SO | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente nº 1: S-NSSAI | SST:XX SD:AAAA |
| Componente nº 2: DNN | largura de banda |
| Descritor de seleção de rota nº 2 | |
| Precedência | 2 (0x02) |
| Componente nº 1: DNN | largura de banda |
Padrão
| Regra URSP nº 9 (padrão) | |
|---|---|
| Precedência | 9 (0x09) |
| Descritor de tráfego nº 1 | |
| combinar tudo | N / D |
| Descritor de seleção de rota nº 1 | |
| Precedência | 1 (0x01) |
| Componente nº 1: S-NSSAI | SST:XX SD:AAAA |
Teste
Para testar o fatiamento da rede 5G, use o seguinte teste manual.
Para configurar um dispositivo para teste, faça o seguinte:
Certifique-se de que a política URSP esteja configurada com uma regra não padrão que corresponda à categoria empresarial e que o descritor de seleção de rota correspondente mapeie a categoria empresarial para a fatia empresarial; e uma regra padrão direcionando o tráfego para a fatia de Internet padrão.
Certifique-se de que um perfil de trabalho esteja configurado no dispositivo.
Opte por usar o fatiamento de rede por meio do DPC
Para testar o comportamento do fatiamento da rede 5G, faça o seguinte:
- Verifique se uma sessão de PDU foi estabelecida com a fatia corporativa (por exemplo, usando um endereço IP específico) e se os aplicativos 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 aplicativos no perfil pessoal usam a sessão de PDU.
Venda adicional de fatiamento 5G
O recurso de upsell de fatiamento 5G, disponível no Android 14-QPR1, permite que as operadoras ofereçam recursos de rede aprimorados (latência e largura de banda) aos seus usuários por meio do fatiamento de rede 5G.
O recurso de upsell de fatiamento 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 para a visualização na web de compra da operadora, enviar dados adicionais para a visualização na web e indicar se a fatia está provisionada e disponível na rede da operadora.
As operadoras podem personalizar o comportamento do recurso de upsell de fatiamento 5G usando configurações da operadora, que controlam se as solicitações de compra podem ser feitas, quando os aplicativos podem solicitar recursos premium e quanto tempo a estrutura de telefonia aguarda pelas respostas do usuário ou da rede.
O recurso de upsell de fatiamento 5G fornece uma interface, chamada DataBoostWebServiceFlow , para permitir a comunicação entre o Android e o webview da operadora.
A Figura 2 mostra o fluxo de compra de upsell de fatiamento 5G:
Figura 2. Fluxo de compra de upsell de fatiamento de 5G.
Processo de titularidade TS.43
Quando um usuário faz uma solicitação de recursos de rede aprimorados, a estrutura de Telefonia solicita a configuração de autorização de serviço para o recurso premium solicitado. Se a resposta TS.43 for válida, a estrutura de Telefonia usará os campos da resposta HTTP para conduzir a solicitação de compra.
Fatiar campos de compra
A configuração de autorização TS.43 inclui os seguintes campos de compra de fatia:
- Status de direito
Chave:
EntitlementStatusTipo:
intValores suportados:
0(desabilitado),1(habilitado),2(incompatível),3(provisionamento),4(incluído)- Status de provisionamento
Chave:
ProvStatusTipo:
intValores suportados:
0(não provisionado),1(provisionado),2(não disponível),3(em andamento)
A estrutura de Telefonia usa a combinação do status de autorização e do status de provisionamento para determinar o estado atual de compra da fatia. O resultado pode ser um dos seguintes:
-
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASED -
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESS -
PURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILED -
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
Se o status de direito for 1 (habilitado) e o status de provisionamento for 0 (não provisionado), a estrutura de telefonia exibirá uma notificação de upsell para o usuário comprar o reforço por meio do webview da operadora. A tabela a seguir descreve o comportamento da estrutura de Telefonia para diferentes combinações de valores de provisionamento e status de autorização.
| Status de provisionamento | |||||
|---|---|---|---|---|---|
Não provisionado ( 0 ) | Provisionado ( 1 )1 ) | Não disponível ( 2 ) | Em andamento ( 3 ) | ||
| Status de direito | Desativado ( 0 ) | Fracassado | Fracassado | Fracassado | Fracassado |
Habilitado ( 1 ) | Mostrar visualização na web | Já comprado | Já comprado | Em andamento | |
Incompatível ( 2 ) | Fracassado | Fracassado | Fracassado | Fracassado | |
Provisionamento ( 3 ) | Erro da operadora | Erro da operadora | Em andamento | Em andamento | |
Incluído ( 4 ) | Erro da operadora | Já comprado | Já comprado | Erro da operadora | |
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 de visualização na web de compra da operadora. Se o tipo de conteúdo não for especificado, a URL será carregada 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 ); e se não existir, 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 dados para a 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 suportados:
0(não especificado),1(JSON),2(XML)
Configurações da operadora
A seguir estão as configurações de operadora disponíveis para personalizar o comportamento do recurso de upsell de fatiamento 5G.
-
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY Uma lista de recursos premium com suporte. Esta é uma matriz interna de
TelephonyManager.PremiumCapability. Esses recursos premium compartilham o mesmo valor que a classeNetworkCapabilities.NetCapabilitycorrespondente. Se um recurso premium for solicitado e não estiver incluído nesta configuração, a solicitação de compra falhará com o resultadoCARRIER_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 upsell de compra é mostrada ao usuário. Se o máximo diário for atingido, a notificação de upsell não será mostrada e as solicitações de compra (incluindo solicitações do servidor de direitos) serão limitadas até a meia-noite do dia seguinte. As solicitações de compra feitas após o máximo diário ser atingido falham com o resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.-
KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT O número máximo mensal de vezes que a notificação de upsell de compra é mostrada ao usuário. Se o máximo mensal for atingido, a notificação de upsell não será mostrada e as solicitações de compra (incluindo solicitações de servidor de direitos) serão limitadas até o primeiro dia do mês subsequente. As solicitações de compra feitas após o máximo mensal ser 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 exibido ao usuário quando ele clicar na notificação de upsell. Se o URL de compra não for encontrado na resposta TS.43 do servidor de autorização, 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 falhará com o resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.-
KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL Se permitir a compra de recursos premium quando o dispositivo estiver conectado ao Long-Term Evolution (LTE). Se
true, as solicitações de compra poderão ser feitas tanto em LTE quanto em New Radio (NR). Sefalse, as solicitações de compra só poderão ser feitas em NR e as solicitações feitas em LTE falharão com o resultadoPURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.-
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG O período de tempo para mostrar a notificação de upsell de compra 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 A quantidade de tempo que as solicitações de compra subsequentes devem ser limitadas após uma falha devido ao tempo limite ou cancelamento do usuário. Se o usuário não clicar na notificação de upsell de compra dentro do tempo limite especificado por
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGou se cancelar ou dispensar a notificação, esse cronômetro de espera será iniciado. Enquanto esse cronômetro estiver ativo, as solicitações de compra falharão com o resultadoPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.-
KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG A quantidade de tempo que as solicitações de compra subsequentes devem ser limitadas após uma falha devido à operadora ou rede. Se a verificação de titularidade falhar, o URL estiver indisponível ou o URL de compra da operadora indicar uma falha, esse cronômetro de espera será iniciado. Enquanto esse cronômetro estiver ativo, as solicitações de compra falharão com o resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.-
KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONG O período de tempo dentro do qual a rede deve definir uma configuração de fatiamento para a capacidade premium de compra. Durante este 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 definir uma configuração de fatiamento a tempo, os aplicativos poderão solicitar a compra de recursos premium novamente. A telefonia não considera a compra concluída até que seja enviada a configuração de fatiamento correspondente, independentemente 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 em seu site de compra para se comunicar com o aplicativo de compra de fatias.
O site da operadora pode obter o recurso premium solicitado por meio do método getRequestedCapability() .
Se a compra for bem-sucedida, o site da operadora deverá notificar o aplicativo de compra da fatia por meio notifyPurchaseSuccessful() ou notifyPurchaseSuccessful(duration) onde duration é um parâmetro opcional que indica a duração pretendida da fatia.
Caso a compra não seja bem-sucedida, o site da operadora deverá notificar o aplicativo de compra de fatias através do método notifyPurchaseFailed(code, reason) , onde code é o código de falha que indica o motivo da falha e reason é o motivo da falha legível por humanos se o o código de falha é desconhecido.
Se algum desses métodos de resposta não for chamado, a compra não será considerada concluída e a solicitação de compra eventualmente expirará.
A seguir estão os códigos de falha válidos que o site da operadora pode retornar em caso de falha na compra:
-
FAILURE_CODE_UNKNOWN -
FAILURE_CODE_CARRIER_URL_UNAVAILABLE -
FAILURE_CODE_AUTHENTICATION_FAILED -
FAILURE_CODE_PAYMENT_FAILED -
FAILURE_CODE_NO_USER_DATA
Ao finalizar a compra a operadora deverá atualizar as regras da URSP com a fatia PRIORITIZE_LATENCY para o dispositivo do usuário.