En 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 segmentado de redes 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 introduce las siguientes capacidades de segmentación de redes empresariales 5G, que los operadores de redes pueden proporcionar a sus clientes empresariales:
Segmentación de dispositivos empresariales para dispositivos completamente administrados
En el caso de las empresas que proporcionan dispositivos empresariales completamente administrados a sus empleados, los proveedores de redes pueden proporcionarles una o más segmentaciones de red empresarial activas a las que se enruta el tráfico en los dispositivos empresariales. A partir de Android 12, Android permite que los operadores proporcionen segmentos empresariales a través de reglas de URSP, en lugar de configurar segmentos a través de 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 segmentación de red empresarial. Las empresas pueden habilitar esta capacidad a través de un controlador de políticas de dispositivos (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 segmentación de red empresarial. No es necesario modificar las apps del perfil de trabajo para solicitar explícitamente la segmentación de red empresarial.
Cómo funciona la segmentación de red 5G en AOSP
Android 12 incorpora compatibilidad con el segmentación de redes 5G a través de adiciones al código base de telefonía en AOSP y el módulo de Tethering para incorporar las APIs de conectividad existentes que se requieren para la segmentación de redes.
La plataforma de telefonía de Android proporciona APIs de telefonía y HAL para admitir el segmentado basado en las solicitudes de red presentadas por el código de red principal y las capacidades de segmentado 5G en el módem. En la Figura 1, se describen los componentes de la función de segmentación de redes 5G.
Figura 1: Arquitectura de segmentación de red 5G en AOSP.
La plataforma de telefonía y conectividad admite lo siguiente:
- Convierte las solicitudes de red para las 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 rutas.
- Volver a la red predeterminada si la segmentación de red empresarial no está disponible
- Enruta el tráfico de todas las apps del perfil de trabajo a la conexión correspondiente.
Admite la segmentación empresarial
- Detectar la presencia de un perfil de trabajo en el dispositivo
- Verificación de permisos o instrucciones de ruta proporcionadas por el DPC que usa el administrador de TI de la empresa
El servicio de redes principal incluye los siguientes cambios en el módulo de Tethering en Android 12:
- Se agregaron la mayoría de las clases de API públicas o del sistema de
android.net.*al módulo Tethering Se expanden los límites del módulo de vinculación 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 Tethering.
Android 12 mueve el código con las siguientes capacidades al módulo de Tethering:
- Recibir solicitudes de apps para conexiones de red
- Recibir solicitudes del sistema (por ejemplo, "coloca estas apps en una segmentación empresarial"; se introdujo en Android 12)
- Envía solicitudes del sistema al código de telefonía, que intenta configurar redes o segmentos a través de la API de HAL y el módem.
- Informa 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 el segmentado 5G en un dispositivo, este debe tener un módem que admita la HAL de IRadio 1.6, que tiene la API de setupDataCall_1_6. Esta API configura una conexión de datos y, para admitir el segmentado 5G, incluye los siguientes parámetros:
trafficDescriptor: Especifica el descriptor de tráfico que se envía al módem.sliceInfo: Especifica la información del segmento de red que se usará en caso de transferencia de EPDG a 5G.matchAllRuleAllowed: Especifica si se permite usar una regla de URSP predeterminada que coincida con todo. Telefonía establece este valor como verdadero para las redes predeterminadas, pero no para las segmentaciones. La regla de coincidencia con todo se aplica a las redes predeterminadas. Cuando una app solicita un segmento específico que no está disponible, se informa que el segmento específico no está 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 la API de getHalDeviceCapabilities indique que no es compatible.
Requisitos de Enterprise
A continuación, se describen los requisitos para que las empresas usen la segmentación de red 5G en dispositivos en una implementación de Android Enterprise.
- Asegúrate de que los dispositivos completamente administrados o de empleados configurados con un perfil de trabajo sean compatibles con 5G SA y tengan módems que admitan la API de
setupDataCall_1_6. - Trabaja con el socio operador en la configuración y el rendimiento de la segmentación, o bien en las características del ANS.
Habilita el segmentado 5G en dispositivos configurados con un perfil de trabajo
En los dispositivos configurados con perfiles de trabajo, la segmentación de redes 5G está desactivada de forma predeterminada en AOSP. Para habilitar el segmentación de red, los administradores de TI empresariales pueden activar o desactivar el enrutamiento del tráfico de las apps del perfil de trabajo al segmento de red empresarial por empleado a través del DPC de EMM, que usa el método setPreferentialNetworkServiceEnabled de la API de DevicePolicyManager (DPM) (introducida en Android 12).
Los proveedores de EMM con DPCs 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 la configuración de reglas de la URSP para diferentes categorías de segmentación, como tráfico empresarial, de CBS, de baja latencia y de alto ancho de banda. Cuando configuren reglas de URSP para diferentes categorías de segmentación, los operadores deben usar los siguientes valores específicos de Android.
| ID | Valor | Descripción |
|---|---|---|
| OSId | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
El OSId para 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 segmento de tráfico con el componente descriptor de tráfico como "ID de SO + tipo de ID de app de SO". Por ejemplo, la segmentación "ENTERPRISE" debe tener un valor de 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345.
Este valor es una concatenación de OSId, la longitud de OSAppId (0x0A) y OSAppId.
Para obtener más información sobre el tipo de componente del descriptor de tráfico, consulta la Tabla 5.2.1 de 3GPP TS 24.526.
En la siguiente tabla, se describen los valores de OSAppId para diferentes categorías de segmentación.
| Categoría de segmentación | OSAppId | Descripción |
|---|---|---|
| ENTERPRISE | 0x454E5445525052495345 |
El OSAppId es una representación de array de bytes de la cadena "ENTERPRISE". |
| ENTERPRISE2 | 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". |
| ENTERPRISE4 | 0x454E544552505249534534 |
El OSAppId es una representación de matriz de bytes de la cadena "ENTERPRISE4". |
| ENTERPRISE5 | 0x454E544552505249534535 |
El OSAppId es una representación de array de bytes de la cadena "ENTERPRISE5". |
| CBS | 0x434253 |
El OSAppId es una representación de matriz de bytes de la cadena "CBS". |
| PRIORITIZE_LATENCY | 0x5052494f524954495a455f4c4154454e4359 |
El 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". |
Ejemplo de reglas de la URSP
En las siguientes tablas, se muestran ejemplos de reglas de URSP para tráfico empresarial, de CBS, de baja latencia, de alto ancho de banda y predeterminado.
Enterprise 1
La compatibilidad con Enterprise 1 está disponible en Android 12 y versiones posteriores. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de ENTERPRISE1:
| Regla de URSP núm. 1 (enterprise1) | |
|---|---|
| Precedencia | 1 (0x01) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + ID de app para SO | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
| Descriptor de selección de ruta núm. 1 | |
| Precedencia | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise |
| Descriptor de selección de ruta núm. 2 | |
| Precedencia | 2 (0x02) |
| Componente 1: DNN | enterprise |
Enterprise 2
La compatibilidad con Enterprise 2 está disponible en Android 13 y versiones posteriores. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de ENTERPRISE2:
| Regla URSP núm. 2 (enterprise2) | |
|---|---|
| Precedencia | 2 (0x02) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + ID de app para SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
| Descriptor de selección de ruta núm. 1 | |
| Precedencia | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise2 |
| Descriptor de selección de ruta núm. 2 | |
| Precedencia | 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 regla de URSP para el tráfico de ENTERPRISE3:
| Regla URSP núm. 3 (enterprise3) | |
|---|---|
| Precedencia | 3 (0x03) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + ID de app para SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Descriptor de selección de ruta núm. 1 | |
| Precedencia | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise3 |
| Descriptor de selección de ruta núm. 2 | |
| Precedencia | 2 (0x02) |
| Componente 1: DNN | enterprise3 |
Enterprise 4
La compatibilidad con Enterprise 4 está disponible en Android 13 y versiones posteriores. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de ENTERPRISE4:
| Regla de URSP núm. 4 (enterprise4) | |
|---|---|
| Precedencia | 4 (0x04) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + ID de app para SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Descriptor de selección de ruta núm. 1 | |
| Precedencia | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise4 |
| Descriptor de selección de ruta núm. 2 | |
| Precedencia | 2 (0x02) |
| Componente 1: DNN | enterprise4 |
Enterprise 5
La compatibilidad con Enterprise 5 está disponible en Android 13 y versiones posteriores. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de ENTERPRISE5:
| Regla de URSP núm. 5 (enterprise5) | |
|---|---|
| Precedencia | 5 (0x05) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + ID de app para SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Descriptor de selección de ruta núm. 1 | |
| Precedencia | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise5 |
| Descriptor de selección de ruta núm. 2 | |
| Precedencia | 2 (0x02) |
| Componente 1: DNN | enterprise5 |
CBS
La compatibilidad con CBS está disponible en Android 13 y versiones posteriores. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de CBS:
| Regla URSP núm. 6 (CBS) | |
|---|---|
| Precedencia | 6 (0x06) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + ID de app para SO | 0x97A498E3FC925C9489860333D06E4E4703434253 |
| Descriptor de selección de ruta núm. 1 | |
| Precedencia | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | cbs |
| Descriptor de selección de ruta núm. 2 | |
| Precedencia | 2 (0x02) |
| Componente 1: DNN | cbs |
Latencia baja
La compatibilidad con baja latencia está disponible en Android 13 y versiones posteriores. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de LOW_LATENCY:
| Regla de URSP núm. 7 (latencia baja) | |
|---|---|
| Precedencia | 7 (0x07) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + ID de app para SO | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Descriptor de selección de ruta núm. 1 | |
| Precedencia | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | latencia |
| Descriptor de selección de ruta núm. 2 | |
| Precedencia | 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. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de HIGH_BANDWIDTH:
| Regla de URSP núm. 8 (ancho de banda alto) | |
|---|---|
| Precedencia | 8 (0x08) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + ID de app para SO | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Descriptor de selección de ruta núm. 1 | |
| Precedencia | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | ancho de banda |
| Descriptor de selección de ruta núm. 2 | |
| Precedencia | 2 (0x02) |
| Componente 1: DNN | ancho de banda |
Predeterminado
| Regla de URSP núm. 9 (predeterminada) | |
|---|---|
| Precedencia | 9 (0x09) |
| Descriptor de tráfico núm. 1 | |
| match-all | N/A |
| Descriptor de selección de ruta núm. 1 | |
| Precedencia | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
Prueba
Para probar el segmentado de red 5G, usa la siguiente prueba manual.
Para configurar un dispositivo para 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 de que el descriptor de selección de ruta correspondiente asigne la categoría empresarial a la segmentación empresarial, y una regla predeterminada que dirija el tráfico a la segmentación de Internet predeterminada.
Asegúrate de que haya un perfil de trabajo configurado en el dispositivo.
Habilita el uso de 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 haya establecido una sesión de PDU con la segmentación empresarial (por ejemplo, usando 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 de Internet predeterminada 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 sugerida de segmentación 5G usa la respuesta TS.43 del servidor de derechos del operador para dirigir el flujo de compra. Las empresas de telefonía celular pueden usar la respuesta para especificar la URL de la WebView de compra de la empresa, enviar datos adicionales a la WebView y, además, indicar si la segmentación está aprovisionada y disponible en la red de la empresa.
Los operadores pueden personalizar el comportamiento de la función de venta sugerida de segmentación de 5G con configuraciones del operador, que controlan si se pueden realizar solicitudes de compra, cuándo se permite que las apps soliciten capacidades premium y cuánto tiempo espera el framework de Telephony las respuestas del usuario o la red.
La función de venta adicional de segmentación 5G proporciona una interfaz, llamada DataBoostWebServiceFlow, para permitir la comunicación entre Android y la 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 la venta incremental de segmentación de 5G.
Proceso de derechos de TS.43
Cuando un usuario solicita capacidades de red mejoradas, el framework de Telephony solicita la configuración de derechos del servicio para la capacidad premium solicitada. Si la respuesta TS.43 es válida, el framework de Telephony usa los campos de la respuesta HTTP para controlar la solicitud de compra.
Segmenta los campos de compra
La configuración de derechos de TS.43 incluye los siguientes campos de compra de segmentos:
- 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 Telephony usa la combinación del estado de derechos y el estado de aprovisionamiento para determinar el estado actual de la compra de la segmentació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 del derecho es 1 (habilitado) y el estado de aprovisionamiento es 0 (no aprovisionado), el framework de Telephony muestra una notificación de aumento de ventas al usuario para que compre el aumento a través de la WebView del operador. En la siguiente tabla, se describe el comportamiento del framework de Telephony para diferentes combinaciones de valores de aprovisionamiento y estado de derechos.
| Estado de aprovisionamiento | |||||
|---|---|---|---|---|---|
No aprovisionado (0) |
Aprovisionado (1 |
No disponible (2) |
En curso (3) |
||
| Estado de derechos | Inhabilitado (0) |
Error | Error | Error | Error |
Habilitado (1) |
Mostrar WebView | Ya compré ese producto | Ya compré ese producto | En curso | |
Incompatible (2) |
Error | Error | Error | Error | |
Aprovisionamiento (3) |
Error de la empresa de transporte | Error de la empresa de transporte | En curso | En curso | |
Incluido (4) |
Error de la empresa de transporte | Ya compré ese producto | Ya compré ese producto | Error de la empresa de transporte | |
Campos del flujo de servicio
La respuesta TS.43 especifica la URL, los datos del usuario y el tipo de contenido para personalizar el comportamiento de la WebView de compra del operador. Si no se especifica el tipo de contenido, la URL se carga como una solicitud GET. Si los datos del usuario existen, se anexan 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 cual (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 Base64) 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 de operadores
A continuación, se muestran los parámetros de configuración del operador disponibles para personalizar el comportamiento de la función de venta superior de segmentación de 5G.
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAYEs una lista de las capacidades premium admitidas. Es un array de números enteros de
TelephonyManager.PremiumCapability. Estas capacidades 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 la notificación de aumento de ventas de compra al usuario. Si se alcanza el máximo diario, no se muestra la notificación de venta adicional y se limitan las solicitudes de compra (incluidas las solicitudes del servidor de derechos) hasta la medianoche del día siguiente. Las solicitudes de compra realizadas 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 aumento de ventas de compra al usuario. Si se alcanza el máximo mensual, no se muestra la notificación de aumento de ventas y se limitan las solicitudes de compra (incluidas las solicitudes del servidor de derechos) hasta el primer día del mes siguiente. Las solicitudes de compra realizadas después de alcanzar el máximo mensual fallan con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRINGEs la URL de compra de la empresa de telefonía celular de respaldo que se muestra al usuario cuando hace clic en la notificación de venta sugerida. Si no se encuentra la URL de compra en la respuesta TS.43 del servidor de derechos, se usa este valor. Si no son válidos ni la URL de la respuesta TS.43 ni la configuración del operador, la solicitud de compra falla con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOLIndica si se permite comprar funciones premium cuando el dispositivo está conectado a la evolución a largo plazo (LTE). Si es
true, se pueden realizar solicitudes de compra en LTE y 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 muestra la notificación de aumento de ventas de compra al usuario antes de que se cancele automáticamente. Cuando se cancela la notificación, las solicitudes posteriores se limitan y fallan con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGEs la cantidad de tiempo durante la que se deben limitar las solicitudes de compra posteriores después de un error debido a un tiempo de espera agotado o a la cancelación del usuario. Si el usuario no hace clic en la notificación de venta adicional de compra dentro del tiempo de espera especificado por
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG, o si cancela o descarta la notificación, se inicia este temporizador de espera. 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 durante la que se deben limitar las solicitudes de compra posteriores después de una falla debido al operador o la red. Si falla la verificación de derechos, la URL no está disponible o la URL de compra del operador indica una falla, se inicia este temporizador de espera. 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 el período dentro del cual la red debe establecer una configuración de segmentación para la capacidad premium de compra. Durante este período, se bloquean las solicitudes de compra posteriores y se devuelve el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Si la red no logra configurar la segmentación a tiempo, las apps pueden volver a solicitar la compra de capacidades premium. La telefonía no considera que una compra se haya completado hasta que se envía la configuración de segmentació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 refuerzo de red, se le muestra un objeto WebView con la URL de compra del operador. Las empresas de transporte 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 segmentos.
El sitio web de la empresa de transporte puede obtener la capacidad 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 segmentos a través de notifyPurchaseSuccessful() o notifyPurchaseSuccessful(duration), donde duration es un parámetro opcional que indica la duración prevista del segmento.
Si la compra no se realiza correctamente, el sitio web del operador debe notificar a la app de compra de segmentos a través del método notifyPurchaseFailed(code, reason), en el que code es el código de error que indica el motivo del error y reason es el motivo del error legible para las personas si el código de error es desconocido.
Si no se llama a ninguno de estos métodos de respuesta, la compra no se considerará completada y, finalmente, se agotará el tiempo de espera de la solicitud de compra.
A continuación, se indican los códigos de error válidos que puede devolver el sitio web de la empresa de transporte en caso de falla 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 división PRIORITIZE_LATENCY en el dispositivo del usuario.