En el caso de los dispositivos que ejecutan Android 12 o versiones posteriores, Android admite la segmentación de redes 5G, el uso de la virtualización de red para dividir las conexiones de una sola red en varias conexiones virtuales distintas que proporcionan diferentes cantidades de recursos a distintos tipos de tráfico. El corte de red 5G permite a los operadores de red dedicar una parte de la red a proporcionar funciones específicas a un segmento particular de clientes. Android 12 presenta las siguientes capacidades de segmentación de red empresarial 5G, que los operadores de red pueden proporcionar a sus clientes empresariales:
Dividir dispositivos empresariales para dispositivos completamente administrados
En el caso de las empresas que proporcionan dispositivos de la empresa completamente administrados a sus empleados, los proveedores de red pueden proporcionarles una o más porciones de red empresarial activas a las que se enruta el tráfico de los dispositivos de la empresa. A partir de Android 12, Android permite que los proveedores proporcionen segmentos empresariales mediante reglas URSP, en lugar de configurarlos mediante APN.
Segmentación de apps empresariales para dispositivos con perfiles de trabajo
En el caso de las empresas que usan la solución de perfil de trabajo, Android 12 permite que los dispositivos enruten el tráfico de todas las apps del perfil de trabajo a una porción de red empresarial. Las empresas pueden habilitar esta función a través de un controlador de política de dispositivo (DPC).
La solución de perfil de trabajo proporciona un nivel automático de autenticación y control de acceso que las empresas requieren para garantizar que solo el tráfico de las apps empresariales en el perfil de trabajo se enrute a la porción de red empresarial. No es necesario modificar las apps del perfil de trabajo para solicitar de forma explícita el fragmento de red empresarial.
Cómo funciona la segmentación de red 5G en AOSP
Android 12 admite la división de red 5G a través de incorporaciones a la base de código de telefonía en AOSP y el módulo de Conexión para incorporar las APIs de conectividad existentes que se requieren para la división de red.
La plataforma de telefonía de Android proporciona APIs de HAL y telefonía para admitir el corte basado en solicitudes de red que envía el código de red principal y las capacidades de corte 5G en el módem. En la Figura 1, se describen los componentes de la función de división de red 5G.
Figura 1: Arquitectura de segmentación de red 5G en AOSP.
La plataforma de telefonía y conectividad admite lo siguiente:
- Conversión de solicitudes de red para categorías de segmentos en descriptores de tráfico que luego se pasan al módem para la coincidencia de tráfico de URSP y la selección de ruta
- Recurrir a la red predeterminada si no está disponible la porción de red empresarial
- Enruta el tráfico de todas las apps en el perfil de trabajo a la conexión correspondiente
Compatibilidad con la segmentación empresarial
- Cómo detectar la presencia de un perfil de trabajo en el dispositivo
- Comprobar si hay permisos o instrucciones de enrutamiento proporcionados desde el DPC que usa el administrador de TI de la empresa
El servicio de herramientas de redes principal incluye los siguientes cambios en el módulo de conexión mediante dispositivo móvil en Android 12:
- Se agregó la mayoría de las clases de API públicas o del sistema de
android.net.*al módulo de vinculación. Expande los límites del módulo de Conexión por cable para incluir lo siguiente:
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
Se quita el código de VPN del módulo de Conexión mediante dispositivo móvil
Android 12 traslada el código con las siguientes capacidades al módulo de Conexión por cable:
- Recibir solicitudes de apps para conexiones de red
- Recibir solicitudes del sistema (por ejemplo, "colocar estas apps en una porción empresarial", que se introdujo en Android 12)
- Envío de solicitudes del sistema al código de telefonía que intenta configurar redes o rebanadas a través de la API de HAL y el módem
- Informar a netd cómo enrutar el tráfico por app (se introdujo en Android 12)
- Informar a las apps lo que sucede con su tráfico de red a través de las APIs de
ConnectivityManager, comoNetworkCallback,getActiveNetworkygetNetworkCapabilities
Implementación
Para admitir la segmentación de 5G en un dispositivo, este debe tener un módem que admita la HAL de IRadio 1.6, que tenga la API de setupDataCall_1_6. Esta API configura una conexión de datos y, además, incluye los siguientes parámetros para admitir la división de 5G:
trafficDescriptor: Especifica el descriptor de tráfico que se envía al módem.sliceInfo: Especifica la información de la porción de red que se usará en el caso de la entrega de EPDG a 5G.matchAllRuleAllowed: Especifica si se permite usar una regla de URSP predeterminada que coincida con todo. La telefonía establece este valor como verdadero para las redes predeterminadas, pero no para las porciones. Esta regla se aplica a las redes predeterminadas. Cuando una app solicita una porción específica que no está disponible, esta se informa como no disponible. En el caso de las apps empresariales, el framework de telefonía puede recurrir a la red predeterminada si la red empresarial no está disponible.
Los módems también deben implementar la API de getSlicingConfig, a menos que se informe que la API de getHalDeviceCapabilities no es compatible.
Requisitos empresariales
A continuación, se describen los requisitos para que las empresas usen la segmentación de red 5G en los dispositivos en una implementación empresarial de Android.
- Asegúrate de que los dispositivos completamente administrados o de los empleados configurados con un perfil de trabajo sean compatibles con la SA 5G con módems que admitan la API de
setupDataCall_1_6. - Trabaja con un socio operador en la configuración y el rendimiento de los segmentos, o bien las características del ANS.
Habilita la división de 5G en dispositivos configurados con un perfil de trabajo
En el caso de los dispositivos configurados con perfiles de trabajo, la división de red 5G está desactivada de forma predeterminada en AOSP. Para habilitar la segmentación de red, los administradores de TI empresariales pueden activar o desactivar el enrutamiento del tráfico de la app del perfil de trabajo a la porción de red empresarial por empleado a través del DPC de EMM, que usa el método setPreferentialNetworkServiceEnabled en la API de DevicePolicyManager (DPM) (presentada en Android 12).
Los proveedores de EMM con DPC personalizados deben integrar la API de DevicePolicyManager para admitir clientes empresariales.
Reglas de URSP
En esta sección, se incluye información para los operadores sobre cómo configurar reglas de URSP para diferentes categorías de fragmentos, como empresas, CBS, latencia baja y tráfico de gran ancho de banda. Cuando se configuran reglas de URSP para diferentes categorías de fragmentos, los operadores deben usar los siguientes valores específicos de Android.
| ID | Valor | Descripción |
|---|---|---|
| OSId | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
El OSId de Android es un UUID de versión 5 generado con el OID de ISO del espacio de nombres y el nombre "Android". |
Los operadores deben configurar reglas de URSP para cada tráfico de fragmento con el componente del descriptor de tráfico como "ID de SO + tipo de ID de app del SO". Por ejemplo, la porción "ENTERPRISE" debe tener un valor de 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345.
Este valor es una concatenación del OSId, la longitud del OSAppId (0x0A) y el OSAppId.
Para obtener más información sobre el tipo de componente del descriptor de tráfico, consulta la Tabla 5.2.1 del 3GPP TS 24.526.
En la siguiente tabla, se describen los valores de OSAppId para diferentes categorías de segmentos.
| Categoría de la porción | OSAppId | Descripción |
|---|---|---|
| ENTERPRISE | 0x454E5445525052495345 |
OSAppId es una representación de array de bytes de la cadena "ENTERPRISE". |
| EMPRESA2 | 0x454E544552505249534532 |
El OSAppId es una representación de array de bytes de la cadena "ENTERPRISE2". |
| ENTERPRISE3 | 0x454E544552505249534533 |
El OSAppId es una representación de array de bytes de la cadena "ENTERPRISE3". |
| EMPRESA4 | 0x454E544552505249534534 |
OSAppId es una representación de array de bytes de la cadena "ENTERPRISE4". |
| ENTERPRISE5 | 0x454E544552505249534535 |
El OSAppId es una representación de array de bytes de la cadena “ENTERPRISE5”. |
| CBS | 0x434253 |
OSAppId es una representación de array de bytes de la cadena "CBS". |
| PRIORITIZE_LATENCY | 0x5052494f524954495a455f4c4154454e4359 |
OSAppId es una representación de array de bytes de la cadena "PRIORITIZE_LATENCY". |
| PRIORITIZE_BANDWIDTH | 0x5052494f524954495a455f42414e445749445448 |
El OSAppId es una representación de array de bytes de la cadena "PRIORITIZE_BANDWIDTH". |
Ejemplos de reglas de URSP
En las siguientes tablas, se muestran ejemplos de reglas de URSP para empresas, CBS, baja latencia, ancho de banda alto y tráfico predeterminado.
Enterprise 1
La compatibilidad con Enterprise 1 está disponible en Android 12 y versiones posteriores. El siguiente es un ejemplo de regla de URSP para el tráfico de ENTERPRISE1:
| Regla de URSP n° 1 (empresa 1) | |
|---|---|
| Prioridad | 1 (0x01) |
| Descriptor de tráfico n.o 1 | |
| ID del SO + tipo de ID de app del SO | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
| Descriptor de selección de ruta n.° 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente n.o 2: DNN | enterprise |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | enterprise |
Enterprise 2
La compatibilidad con Enterprise 2 está disponible en Android 13 y versiones posteriores. El siguiente es un ejemplo de regla de URSP para el tráfico de ENTERPRISE2:
| Regla URSP n.° 2 (enterprise2) | |
|---|---|
| Prioridad | 2 (0x02) |
| Descriptor de tráfico n° 1 | |
| ID de SO + tipo de ID de app del SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
| Descriptor de selección de ruta n.° 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | empresa2 |
| Descriptor de selección de ruta n.° 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | enterprise2 |
Enterprise 3
La compatibilidad con Enterprise 3 está disponible en Android 13 y versiones posteriores. A continuación, se muestra un ejemplo de una regla de URSP para el tráfico de ENTERPRISE3:
| Regla URSP n° 3 (enterprise3) | |
|---|---|
| Prioridad | 3 (0x03) |
| Descriptor de tráfico n° 1 | |
| ID del SO + tipo de ID de app del SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Descriptor de selección de ruta n.o 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise3 |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | enterprise3 |
Enterprise 4
La compatibilidad con Enterprise 4 está disponible en Android 13 y versiones posteriores. El siguiente es un ejemplo de regla de URSP para el tráfico de ENTERPRISE4:
| Regla URSP n.° 4 (enterprise4) | |
|---|---|
| Prioridad | 4 (0x04) |
| Descriptor de tráfico n° 1 | |
| ID de SO + tipo de ID de app del SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Descriptor de selección de ruta n.° 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise4 |
| Descriptor de selección de ruta n.° 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | Enterprise4 |
Enterprise 5
La compatibilidad con Enterprise 5 está disponible en Android 13 y versiones posteriores. El siguiente es un ejemplo de regla de URSP para el tráfico ENTERPRISE5:
| Regla de URSP n.° 5 (enterprise5) | |
|---|---|
| Prioridad | 5 (0x05) |
| Descriptor de tráfico n° 1 | |
| ID del SO + tipo de ID de app del SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Descriptor de selección de ruta n.° 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise5 |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | enterprise5 |
CBS
La compatibilidad con CBS está disponible en Android 13 y versiones posteriores. El siguiente es un ejemplo de regla de URSP para el tráfico de CBS:
| Regla 6 de la URSP (CBS) | |
|---|---|
| Prioridad | 6 (0x06) |
| Descriptor de tráfico n.o 1 | |
| ID del SO + tipo de ID de app del SO | 0x97A498E3FC925C9489860333D06E4E4703434253 |
| Descriptor de selección de ruta n.° 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente n.o 2: DNN | cbs |
| Descriptor de selección de ruta n.° 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | cbs |
Latencia baja
La compatibilidad con latencia baja está disponible en Android 13 y versiones posteriores. El siguiente es un ejemplo de regla de URSP para el tráfico LOW_LATENCY:
| Regla de URSP 7 (latencia baja) | |
|---|---|
| Prioridad | 7 (0x07) |
| Descriptor de tráfico n.o 1 | |
| ID del SO + tipo de ID de app del SO | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Descriptor de selección de ruta n.° 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente n.o 2: DNN | latencia |
| Descriptor de selección de ruta n.° 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | latencia |
Ancho de banda alto
La compatibilidad con el ancho de banda alto está disponible en Android 13 y versiones posteriores. El siguiente es un ejemplo de regla de URSP para el tráfico de HIGH_BANDWIDTH:
| Regla 8 de la URSP (ancho de banda alto) | |
|---|---|
| Prioridad | 8 (0x08) |
| Descriptor de tráfico n° 1 | |
| ID del SO + tipo de ID de app del SO | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Descriptor de selección de ruta n.o 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | ancho de banda |
| Descriptor de selección de ruta n.° 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | ancho de banda |
Predeterminado
| Regla URSP n° 9 (predeterminada) | |
|---|---|
| Prioridad | 9 (0x09) |
| Descriptor de tráfico n° 1 | |
| match-all | N/A |
| Descriptor de selección de ruta n.° 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
Prueba
Para probar la división de red 5G, usa la siguiente prueba manual.
Para configurar un dispositivo para realizar pruebas, haz lo siguiente:
Asegúrate de que la política de URSP esté configurada con una regla no predeterminada que coincida con la categoría empresarial y que el descriptor de selección de ruta correspondiente asigne la categoría empresarial a la porción empresarial, y una regla predeterminada que dirija el tráfico a la porción de Internet predeterminada.
Asegúrate de que se haya configurado un perfil de trabajo en el dispositivo.
Acepta el uso de la segmentación de red a través del DPC
Para probar el comportamiento de la segmentación de red 5G, haz lo siguiente:
- Verifica que se establezca una sesión de PDU con la porción empresarial (por ejemplo, con una dirección IP específica) y que las apps del perfil de trabajo usen esa sesión de PDU.
- Verifica que se establezca una sesión de PDU independiente con la porción predeterminada de Internet y que las apps del perfil personal usen la sesión de PDU.
Venta incremental de segmentación de 5G
La función de venta incremental de segmentación de 5G, disponible a partir de Android 14-QPR1, permite a los operadores ofrecer capacidades de red mejoradas (latencia y ancho de banda) a sus usuarios a través de la segmentación de la red 5G.
La función de venta incremental de división de 5G usa la respuesta TS.43 del servidor de derechos del operador para impulsar el flujo de compra. Los operadores pueden usar la respuesta para especificar la URL de la WebView de la compra del operador, enviar datos adicionales a ella e indicar si la porción está aprovisionada y disponible en la red del operador.
Los operadores pueden personalizar el comportamiento de la función de venta incremental de la división de 5G con configuraciones del operador, que controlan si se pueden realizar solicitudes de compra, cuándo las apps pueden solicitar capacidades premium y durante cuánto tiempo el framework de telefonía espera respuestas del usuario o la red.
La función de venta incremental de división de 5G proporciona una interfaz, llamada DataBoostWebServiceFlow, para permitir la comunicación entre Android y el WebView del operador.
En la Figura 2, se muestra el flujo de compra de la venta incremental de segmentación de 5G:
Figura 2: Flujo de compra de venta incremental de segmentación de 5G
Proceso de derechos de TS.43
Cuando un usuario realiza una solicitud de funciones de red mejoradas, el framework de telefonía solicita la configuración de derechos de servicio para la función premium solicitada. Si la respuesta de TS.43 es válida, el framework de telefonía usa los campos de la respuesta HTTP para impulsar la solicitud de compra.
Cómo dividir campos de compra
La configuración de derechos de TS.43 incluye los siguientes campos de compra de fragmentos:
- Estado de autorización
Tecla:
EntitlementStatusTipo:
intValores admitidos:
0(inhabilitado),1(habilitado),2(incompatible),3(aprovisionamiento),4(incluido)- Estado de aprovisionamiento
Tecla:
ProvStatusTipo:
intValores admitidos:
0(no aprovisionado),1(aprovisionado),2(no disponible),3(en curso)
El framework de telefonía usa la combinación del estado de derechos y el estado de aprovisionamiento para determinar el estado actual de la compra de la porción. El resultado puede ser uno de los siguientes:
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASEDPURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESSPURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILEDPURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
Si el estado de derechos es 1 (habilitado) y el estado de aprovisionamiento es 0 (no aprovisionado), el framework de telefonía muestra una notificación de venta incremental al usuario para que compre el aumento a través del WebView del operador. En la siguiente tabla, se describe el comportamiento del framework de telefonía para diferentes combinaciones de valores de estado de aprovisionamiento y derechos.
| Estado de aprovisionamiento | |||||
|---|---|---|---|---|---|
No aprovisionado (0) |
Aprovisionados (1) |
No disponibles (2) |
En curso (3) |
||
| Estado de derechos | Inhabilitadas (0) |
Error | Error | Error | Error |
Habilitado (1) |
Cómo mostrar WebView | Ya compré ese producto | Ya compré ese producto | En curso | |
Incompatible (2) |
Error | Error | Error | Error | |
Aprovisionamiento (3) |
Error del proveedor | Error de la empresa de transporte | En curso | En curso | |
Incluidos (4) |
Error de la empresa de transporte | Ya compré ese producto | Ya compré ese producto | Error del proveedor | |
Campos del flujo de servicios
La respuesta de TS.43 especifica la URL, los datos del usuario y el tipo de contenido para personalizar el comportamiento de la WebView de compra del proveedor. Si no se especifica el tipo de contenido, la URL se carga como una solicitud GET. Si los datos del usuario existen, se adjuntan a la URL como un parámetro de consulta (por ejemplo, https://www.android.com?encodedValue=Base64EncodedUserData). Si no existen, la URL se usa tal como está (por ejemplo, https://www.android.com).
Si el tipo de contenido se especifica en formato JSON o XML, la URL se carga como una solicitud POST, y los datos del usuario (decodificados si están codificados en Base 64) se envían como los datos de la solicitud POST.
- URL
Tecla:
ServiceFlow_URLTipo:
StringEjemplo:
"https://www.android.com"- Datos del usuario
Tecla:
ServiceFlow_UserDataTipo:
StringEjemplo:
"encodedValue=Base64EncodedUserData"- Tipo de contenido
Tecla:
ServiceFlow_ContentsTypeTipo:
StringValores admitidos:
0(sin especificar),1(JSON),2(XML)
Configuraciones del operador
Las siguientes son las configuraciones del operador disponibles para personalizar el comportamiento de la función de venta incremental de la división de 5G.
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAYEs una lista de las funciones premium compatibles. Este es un array int de
TelephonyManager.PremiumCapability. Estas funciones premium comparten el mismo valor que la claseNetworkCapabilities.NetCapabilitycorrespondiente. Si se solicita una función premium y no se incluye en esta configuración, la solicitud de compra falla con el resultadoCARRIER_DISABLED.En Android 14, solo se admite
PREMIUM_CAPABILITY_PRIORITIZE_LATENCY.KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INTEs la cantidad máxima diaria de veces que se muestra al usuario la notificación de venta incremental de compras. Si se cumple el máximo diario, no se muestra la notificación de venta incremental y las solicitudes de compra (incluidas las solicitudes del servidor de derechos) se limitan hasta la medianoche del día siguiente. Las solicitudes de compra que se realizan después de alcanzar el máximo diario fallan con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INTEs la cantidad máxima mensual de veces que se muestra la notificación de venta incremental de la compra al usuario. Si se cumple el máximo mensual, no se muestra la notificación de venta incremental y las solicitudes de compra (incluidas las solicitudes del servidor de derechos) se limitan hasta el primer día del mes siguiente. Las solicitudes de compra realizadas después de que se alcanza el máximo mensual fallan con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRINGEs la URL de compra del operador de respaldo que se mostrará al usuario cuando haga clic en la notificación de venta incremental. Si no se encuentra la URL de compra en la respuesta TS.43 del servidor de derechos, se usa este valor. Si ni la URL de la respuesta de TS.43 ni la configuración del operador son válidas, la solicitud de compra falla con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOLEspecifica si se debe permitir la compra de funciones premium cuando el dispositivo está conectado a evolución a largo plazo (LTE). Si es
true, las solicitudes de compra se pueden realizar tanto en LTE como en New Radio (NR). Si esfalse, las solicitudes de compra solo se pueden realizar en NR, y las solicitudes realizadas en LTE fallan con el resultadoPURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGEs la cantidad de tiempo que se mostrará la notificación de venta incremental de la compra al usuario antes de que se cancele automáticamente. Cuando se cancela la notificación, las solicitudes posteriores se regulan y fallan con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGEs la cantidad de tiempo que se debe reducir el límite de las solicitudes de compra posteriores después de una falla debido a un tiempo de espera o una cancelación del usuario. Si el usuario no hace clic en la notificación de venta incremental de la compra dentro del tiempo de espera especificado por
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGo si cancela o descarta la notificación, se inicia este temporizador de inactividad. Mientras este temporizador está activo, las solicitudes de compra fallan con el resultadoPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGEs la cantidad de tiempo que se debe reducir el límite de las solicitudes de compra posteriores después de una falla debido al operador o la red. Si la verificación de derechos falla, la URL no está disponible o la URL de compra del operador indica una falla, se inicia este temporizador de recuperación. Mientras este temporizador está activo, las solicitudes de compra fallan con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONGEs la cantidad de tiempo en la que la red debe configurar una configuración de división para la función de compra premium. Durante este período, se bloquean las solicitudes de compra posteriores y se muestra el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Si la red no configura una configuración de división a tiempo, las apps pueden solicitar volver a comprar funciones premium. La telefonía no considera que una compra está completa hasta que se envía la configuración de división correspondiente, independientemente de si el usuario pagó al operador o no.
Interfaz de JavaScript
Cuando el usuario hace clic en la notificación de aumento de red, se le muestra un objeto WebView con la URL de compra del operador. Los operadores pueden usar las APIs proporcionadas en la interfaz de JavaScript DataBoostWebServiceFlow en su sitio web de compra para comunicarse con la app de compra de fragmentos.
El sitio web del operador puede obtener la función premium solicitada a través del método getRequestedCapability().
Si la compra se realiza correctamente, el sitio web del operador debe notificar a la app de compra de fragmentos a través de notifyPurchaseSuccessful() o notifyPurchaseSuccessful(duration), donde duration es un parámetro opcional que indica la duración prevista del fragmento.
Si la compra no se realiza correctamente, el sitio web del operador debe notificar a la app de compra de slices a través del método notifyPurchaseFailed(code, reason), en el que code es el código de falla que indica el motivo del error y reason es el motivo legible por humanos si se desconoce el código de falla.
Si no se llama a ninguno de estos métodos de respuesta, la compra no se considerará completada y, con el tiempo, se agotará el tiempo de espera de la solicitud de compra.
Los siguientes son los códigos de error válidos que puede mostrar el sitio web del transportista en caso de fallas en la compra:
FAILURE_CODE_UNKNOWNFAILURE_CODE_CARRIER_URL_UNAVAILABLEFAILURE_CODE_AUTHENTICATION_FAILEDFAILURE_CODE_PAYMENT_FAILEDFAILURE_CODE_NO_USER_DATA
Cuando se completa la compra, el operador debe actualizar las reglas de URSP con la porción PRIORITIZE_LATENCY en el dispositivo del usuario.