Pour les appareils équipés d'Android 12 ou version ultérieure, Android prend en charge le découpage de réseaux 5G, l'utilisation de la virtualisation de réseau pour diviser des connexions réseau uniques en plusieurs connexions virtuelles distinctes qui fournissent différentes quantités de ressources à différents types de trafic. 5G le découpage de réseau permet aux opérateurs de dédier une partie du réseau à en fournissant des fonctionnalités spécifiques à un segment particulier de clients. Android 12 introduit les fonctionnalités de segmentation du réseau 5G des entreprises, les opérateurs réseau peut fournir à ses clients d'entreprise:
Segmentation des appareils d'entreprise pour les appareils entièrement gérés
Pour les entreprises qui fournissent entièrement géré les appareils de l'entreprise à leurs employés, les fournisseurs de réseau peuvent leur fournir un ou des segments de réseau d'entreprise plus actifs où le trafic sur les appareils de l'entreprise sont acheminées. À partir d'Android 12, Android autorise les opérateurs pour fournir des segments d'entreprise via les règles URSP, au lieu de configurer des segments via APNs.
Segmentation des applications professionnelles pour les appareils dotés d'un profil professionnel
Pour les entreprises qui utilisent profil professionnel , Android 12 permet aux appareils d'acheminer le trafic provenant de toutes les applications du profil professionnel à une tranche de réseau d'entreprise. Les entreprises peuvent activer cette fonctionnalité grâce à un Outil de contrôle des règles relatives aux appareils (DPC) :
La solution de profil professionnel fournit un niveau automatique d'authentification et de contrôle des accès requis par les entreprises pour garantir que seul le trafic provenant les applications d'entreprise du profil professionnel sont acheminées vers la tranche de réseau d'entreprise. Il n'est pas nécessaire de modifier les applications du profil professionnel pour demander explicitement tranche de réseau d'entreprise.
Fonctionnement du découpage du réseau 5G dans AOSP
Android 12 est compatible avec le découpage de réseau 5G grâce à des ajouts au codebase de téléphonie dans AOSP et à Module de partage de connexion pour intégrer les API de connectivité existantes nécessaires au découpage du réseau.
La plate-forme de téléphonie Android fournit des API HAL et de téléphonie pour prendre en charge segmenter en fonction des requêtes réseau enregistrées par le code réseau central et la 5G les fonctionnalités de segmentation du modem. La figure 1 décrit les composants de la 5G de segmentation réseau.
Figure 1 : Architecture de segmentation du réseau 5G dans AOSP
La plate-forme de téléphonie et de connectivité est compatible avec:
- Conversion des requêtes réseau pour les catégories de tranches en descripteurs de trafic qui sont ensuite transmis au modem pour la mise en correspondance du trafic URSP et le routage sélection
- Revenir au réseau par défaut si la tranche de réseau de l'entreprise n'est pas disponible
- Routage du trafic de toutes les applications du profil professionnel vers le connexion correspondante
Prendre en charge le tranchage d'entreprise
- Détecter la présence d'un profil professionnel sur l'appareil
- Vérification des autorisations ou des instructions d'itinéraire fournies par le Outil DPC utilisé par l'administrateur informatique de l'entreprise
Le service de mise en réseau principal inclut les modifications suivantes apportées au partage de connexion d'Android 12:
- Ajoute la plupart des
android.net.*classes d'API publiques ou système au partage de connexion module Développe les limites du module de partage de connexion pour inclure:
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
Déplace le code VPN hors du module de partage de connexion
Android 12 déplace le code avec les fonctionnalités suivantes au module de partage de connexion:
- Recevoir des requêtes de connexion réseau en provenance d'applications
- Recevoir des requêtes du système (par exemple, "placez ces applications sur un tranche entreprise"; introduite sous Android 12).
- L'envoi de requêtes du système au code de téléphonie qui tente de configurer des réseaux ou des tranches en passant par l'API HAL et le modem
- Cette section indique comment acheminer le trafic par application (présentée dans Android 12)
- Informer les applications de ce qu'il advient de leur trafic réseau via
Les API
ConnectivityManagertelles queNetworkCallback,getActiveNetwork,getNetworkCapabilities
Implémentation
Pour pouvoir segmenter un appareil en 5G, celui-ci doit disposer d'un modem compatible avec
l'IRadio 1.6 HAL
qui dispose du
setupDataCall_1_6
API. Cette API configure une connexion de données et inclut les paramètres suivants
pour la prise en charge du découpage 5G:
trafficDescriptor: spécifie le descripteur de trafic envoyé au modem.sliceInfo: spécifie les informations de la tranche de réseau à utiliser dans dans le cas d'un transfert EPDG vers la 5GmatchAllRuleAllowed: spécifie si l'URSP par défaut est "match-all" ou non. est autorisée. Le service de téléphonie définit ce paramètre sur "true" pour les réseaux par défaut. mais pas pour les tranches. La règle "Tout correspondre" est appliquée aux paramètres par défaut réseaux sociaux. Lorsqu'une application demande un segment spécifique disponible, le segment spécifique est signalé comme non disponible. Pour pour les applications d'entreprise, le framework de téléphonie peut revenir au modèle par défaut réseau si le réseau d'entreprise n'est pas disponible.
Les modems doivent également implémenter
getSlicingConfig
API, sauf s'il est signalé comme non compatible
getHalDeviceCapabilities
API.
Conditions requises pour les entreprises
Vous trouverez ci-dessous les conditions requises pour que les entreprises utilisent la segmentation de réseau 5G sur les appareils lors d'un déploiement Android en entreprise.
- Assurez-vous que les appareils entièrement gérés ou ceux des employés sont configurés avec un profil professionnel.
compatibles avec la 5G SA et les modems compatibles avec le
setupDataCall_1_6API. - Collaborez avec l'opérateur partenaire sur la configuration et les performances des segments, ou contrat de niveau de service. caractéristiques.
Activer le découpage 5G sur les appareils configurés avec un profil professionnel
Pour les appareils configurés avec des profils professionnels, le découpage du réseau 5G est désactivé
par défaut dans AOSP. Pour activer le découpage de réseau, les administrateurs informatiques d'entreprise peuvent activer ou
routage du trafic des applications du profil professionnel vers la tranche de réseau de l'entreprise sur une
par employé grâce à l'outil DPC EMM, qui utilise le
setPreferentialNetworkServiceEnabled
dans la classe
DevicePolicyManager (DPM)
(introduite dans Android 12).
Les fournisseurs EMM avec des DPC personnalisés doivent intégrer l'API DevicePolicyManager pour :
pour les clients d'entreprise.
Règles URSP
Cette section contient des informations destinées aux opérateurs sur la configuration des règles URSP pour de tranches de 20 %, y compris Enterprise, CBS, et un trafic à large bande passante. Lorsque vous configurez des règles URSP pour catégories de secteurs différentes, les opérateurs doivent utiliser les attributs valeurs.
| ID | Valeur | Description |
|---|---|---|
| ID de l'OS | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
L'OSId pour Android est un UUID de version 5 généré avec l'espace de noms ISO. OID et le nom "Android". |
Les opérateurs doivent configurer des règles URSP pour chaque segment de trafic associé au trafic.
comme "OS Id + OS App Id type". Par exemple, "ENTREPRISE"
tranche doit avoir une valeur de
0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
Cette valeur est une concaténation de l'OSId et de la longueur de l'OSAppId (0x0A),
et OSAppId.
Pour en savoir plus sur le type de composant "Descripteur de trafic", consultez
3GPP TS 24.526 Tableau 5.2.1
Le tableau suivant décrit les valeurs OSAppId pour différentes catégories de tranches.
| Catégorie de tranche | ID d'application OS | Description |
|---|---|---|
| ENTREPRISE | 0x454E5445525052495345 |
OSAppId est une représentation de tableau d'octets de la chaîne "ENTERPRISE" |
| ENTREPRISE2 | 0x454E544552505249534532 |
OSAppId est une représentation de la chaîne "ENTERPRISE2" dans un tableau d'octets |
| ENTREPRISE3 | 0x454E544552505249534533 |
OSAppId est une représentation de la chaîne "ENTERPRISE3" dans un tableau d'octets |
| ENTREPRISE4 | 0x454E544552505249534534 |
OSAppId est une représentation de la chaîne "ENTERPRISE4" dans un tableau d'octets |
| ENTREPRISE5 | 0x454E544552505249534535 |
OSAppId est une représentation de la chaîne "ENTERPRISE5" dans un tableau d'octets |
| CBS | 0x434253 |
OSAppId est une représentation de la chaîne "CBS" sous forme de tableau d'octets |
| LATENCE_PRIORITAIRE | 0x5052494f524954495a455f4c4154454e4359 |
OSAppId est une représentation de tableau d'octets de la chaîne "PRIORITIZE_LATENCY" |
| BANDE_BANDE_PRIORITAIRE | 0x5052494f524954495a455f42414e445749445448 |
L'OSAppId est une représentation du tableau d'octets de la chaîne "PRIORITIZE_BANDWIDTH". |
Exemples de règles URSP
Les tableaux suivants présentent des exemples de règles URSP pour les entreprises, CBS, faible latence, bande passante élevée et trafic par défaut.
Entreprise 1
Enterprise 1 est compatible avec Android 12 ou version ultérieure. Voici un exemple de règle URSP pour le trafic ENTERPRISE1:
| Règle URSP n° 1 (enterprise1) | |
|---|---|
| Priorité | 1 (0x01) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application d'OS | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
| Descripteur 1 de la sélection de l'itinéraire | |
| Priorité | 1 (0x01) |
| Composant n° 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant n° 2: DNN | Enterprise |
| Descripteur 2 de la sélection de l'itinéraire | |
| Priorité | 2 (0x02) |
| Composant n° 1: DNN | Enterprise |
Entreprise 2
Enterprise 2 est compatible avec Android 13 ou version ultérieure. Voici un exemple de règle URSP pour le trafic ENTERPRISE2:
| Règle URSP n° 2 (enterprise2) | |
|---|---|
| Priorité | 2 (0x02) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application d'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
| Descripteur 1 de la sélection de l'itinéraire | |
| Priorité | 1 (0x01) |
| Composant n° 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant n° 2: DNN | entreprise2 |
| Descripteur 2 de la sélection de l'itinéraire | |
| Priorité | 2 (0x02) |
| Composant n° 1: DNN | entreprise2 |
Entreprise 3
Enterprise 3 est compatible avec Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE3:
| Règle URSP n° 3 (enterprise3) | |
|---|---|
| Priorité | 3 (0x03) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application d'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Descripteur 1 de la sélection de l'itinéraire | |
| Priorité | 1 (0x01) |
| Composant n° 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant n° 2: DNN | entreprise3 |
| Descripteur 2 de la sélection de l'itinéraire | |
| Priorité | 2 (0x02) |
| Composant n° 1: DNN | entreprise3 |
Entreprise 4
Enterprise 4 est compatible avec Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE4:
| Règle URSP n° 4 (enterprise4) | |
|---|---|
| Priorité | 4 (0x04) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application d'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Descripteur 1 de la sélection de l'itinéraire | |
| Priorité | 1 (0x01) |
| Composant n° 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant n° 2: DNN | entreprise4 |
| Descripteur 2 de la sélection de l'itinéraire | |
| Priorité | 2 (0x02) |
| Composant n° 1: DNN | entreprise4 |
Entreprise 5
Enterprise 5 est compatible avec Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE5:
| Règle URSP n° 5 (enterprise5) | |
|---|---|
| Priorité | 5 (0x05) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application d'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Descripteur 1 de la sélection de l'itinéraire | |
| Priorité | 1 (0x01) |
| Composant n° 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant n° 2: DNN | entreprise5 |
| Descripteur 2 de la sélection de l'itinéraire | |
| Priorité | 2 (0x02) |
| Composant n° 1: DNN | entreprise5 |
CBS
La prise en charge de CBS est disponible sur Android 13 ou version ultérieure. Voici un exemple de règle URSP pour le trafic CBS:
| Règle URSP n° 6 (CBS) | |
|---|---|
| Priorité | 6 (0x06) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application d'OS | 0x97A498E3FC925C9489860333D06E4E4703434253 |
| Descripteur 1 de la sélection de l'itinéraire | |
| Priorité | 1 (0x01) |
| Composant n° 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant n° 2: DNN | cbs |
| Descripteur 2 de la sélection de l'itinéraire | |
| Priorité | 2 (0x02) |
| Composant n° 1: DNN | cbs |
Latence faible
La compatibilité avec la faible latence est disponible sur Android 13 ou version ultérieure. Voici un exemple de règle URSP pour le trafic LOW_LATENCY:
| Règle URSP n° 7 (faible latence) | |
|---|---|
| Priorité | 7 (0x07) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application d'OS | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Descripteur 1 de la sélection de l'itinéraire | |
| Priorité | 1 (0x01) |
| Composant n° 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant n° 2: DNN | latence |
| Descripteur 2 de la sélection de l'itinéraire | |
| Priorité | 2 (0x02) |
| Composant n° 1: DNN | latence |
Bande passante élevée
La prise en charge de la bande passante élevée est disponible sur Android 13 ou version ultérieure. Voici un exemple de règle URSP pour le trafic HIGH_BANDWIDTH:
| Règle URSP n° 8 (bande passante élevée) | |
|---|---|
| Priorité | 8 (0x08) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application d'OS | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Descripteur 1 de la sélection de l'itinéraire | |
| Priorité | 1 (0x01) |
| Composant n° 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant n° 2: DNN | bande passante |
| Descripteur 2 de la sélection de l'itinéraire | |
| Priorité | 2 (0x02) |
| Composant n° 1: DNN | bande passante |
Par défaut
| Règle URSP n° 9 (par défaut) | |
|---|---|
| Priorité | 9 (0x09) |
| Descripteur de trafic n° 1 | |
| CANNOT TRANSLATE | N/A |
| Descripteur 1 de la sélection de l'itinéraire | |
| Priorité | 1 (0x01) |
| Composant n° 1: S-NSSAI | SST:XX SD:YYYYYY |
Tests
Pour tester le découpage du réseau 5G, utilisez le test manuel suivant.
Pour configurer un appareil à des fins de test, procédez comme suit:
Assurez-vous que la stratégie URSP est configurée avec une règle autre que celle par défaut qui correspond à la catégorie "Entreprise" et que la sélection d'itinéraire correspondante le descripteur met en correspondance la catégorie entreprise avec la tranche entreprise ; et un qui dirige le trafic vers le segment Internet par défaut.
Assurez-vous qu'un profil professionnel est configuré sur l'appareil.
Activer le découpage du réseau via l'outil DPC
Pour tester le comportement de la segmentation du réseau 5G, procédez comme suit:
- Vérifiez qu'une session PDU est établie avec la tranche entreprise (pour (par exemple, à l'aide d'une adresse IP spécifique) et que les applications du profil professionnel utilisent cette session PDU.
- Vérifier qu'une session PDU distincte est établie avec l'Internet par défaut et que les applis du profil personnel utilisent la session PDU.
Vente incitative de segmentation 5G
La fonctionnalité de vente incitative de découpage 5G, disponible auprès Android 14-QPR1 permet aux opérateurs de proposer un réseau amélioré (latence et bande passante) à leurs utilisateurs via la segmentation réseau 5G.
La fonctionnalité de vente incitative de découpage 5G utilise la réponse TS.43 de l'opérateur. des droits d'accès pour gérer le parcours d'achat. Les opérateurs peuvent utiliser la réponse spécifier l'URL de la WebView d'achat de l'opérateur, envoyer des données supplémentaires au WebView, et indiquer si le segment est provisionné et disponible sur le réseau de l'opérateur.
Les opérateurs peuvent personnaliser le comportement de la fonctionnalité de segmentation 5G incitative à l'aide de des configurations d'opérateur qui déterminent si les demandes d'achat peuvent être quand les applications sont autorisées à demander des fonctionnalités premium, et pendant combien de temps Telephony Framework attend les réponses de l'utilisateur ou du réseau.
La fonctionnalité de vente incitative de découpage 5G fournit une interface, appelée
DataBoostWebServiceFlow,
pour permettre la communication entre Android et WebView de l'opérateur.
La figure 2 illustre le parcours d'achat de vente incitative de découpage 5G:
Figure 2. La 5G divise le flux d'achat de vente incitative.
TS.43 Processus de gestion des droits d'accès
Lorsqu'un utilisateur demande à bénéficier de capacités réseau améliorées, la fonctionnalité framework demande la configuration des droits d'accès au service pour l'objet des fonctionnalités premium. Si la réponse TS.43 est valide, le framework de téléphonie utilise les champs de la réponse HTTP pour générer la demande d'achat.
Champs d'achat de segments d'application
La configuration des droits d'accès TS.43 inclut l'achat de segment suivant :
- État du droit d'accès
Touche :
EntitlementStatusType :
intValeurs acceptées:
0(désactivé),1(activé),2(incompatible),3(provisionnement),4(inclus)- État de gestion des comptes
Touche :
ProvStatusType :
intValeurs acceptées:
0(non provisionné),1(provisionné),2(non disponible),3(en cours)
Telephony Framework utilise à la fois l'état des droits d'accès et l'état de provisionnement pour déterminer l'état actuel de l'achat du segment. Résultat peut être:
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASEDPURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESSPURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILEDPURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
Si l'état des droits d'accès est 1 (activé) et que l'état du provisionnement est 0
(non provisionné), Telephony Framework affiche une notification de vente incitative pour
l'utilisateur à acheter le boost via
l'interface WebView de l'opérateur. Le tableau suivant
décrit le comportement du framework de téléphonie pour différentes combinaisons
de provisionnement et des droits d'accès.
| État du provisionnement | |||||
|---|---|---|---|---|---|
Non provisionné (0) |
Géré (1) |
Non disponible (2) |
En cours (3) |
||
| État des droits d'accès | Désactivé (0) |
Échec | Échec | Échec | Échec |
Activé (1) |
Afficher WebView | Déjà acheté | Déjà acheté | En cours | |
Incompatible (2) |
Échec | Échec | Échec | Échec | |
Provisionnement (3) |
Erreur liée à l'opérateur | Erreur liée à l'opérateur | En cours | En cours | |
Inclus (4) |
Erreur liée à l'opérateur | Déjà acheté | Déjà acheté | Erreur liée à l'opérateur | |
Champs du flux de service
La réponse TS.43 spécifie l'URL, les données utilisateur et le type de contenu à personnaliser.
le comportement de WebView pour les achats
par l'opérateur. Si le type de contenu n'est pas spécifié,
L'URL est chargée en tant que requête GET. Si les données utilisateur existent, elles sont ajoutées
URL en tant que paramètre de requête (par exemple,
https://www.android.com?encodedValue=Base64EncodedUserData); Si ce n'est pas le cas,
existe, l'URL est utilisée telle quelle (par exemple, https://www.android.com).
Si le type de contenu est spécifié au format JSON ou XML, l'URL est chargée en tant que
POST, et les données utilisateur (décodées si elles sont encodées en base64) sont envoyées en tant que
les données pour la requête POST.
- URL
Touche :
ServiceFlow_URLType :
StringExemple :
"https://www.android.com"- Données utilisateur
Touche :
ServiceFlow_UserDataType :
StringExemple :
"encodedValue=Base64EncodedUserData"- Type de contenu
Touche :
ServiceFlow_ContentsTypeType :
StringValeurs acceptées:
0(non spécifié),1(JSON),2(XML)
Configurations d'opérateurs
Voici les configurations d'opérateurs disponibles pour personnaliser les du comportement de la fonctionnalité de vente incitative de découpage 5G.
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAYListe des fonctionnalités premium compatibles. Il s'agit d'un tableau int de
TelephonyManager.PremiumCapabilityCes fonctionnalités premium ont la même valeur que lesNetworkCapabilities.NetCapability. Si une fonctionnalité Premium est demandée et qu'elle n'est pas incluse , la demande d'achat échoue avecCARRIER_DISABLEDrésultat.Sous Android 14, seuls
PREMIUM_CAPABILITY_PRIORITIZE_LATENCYest pris en charge.KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INTNombre maximal quotidien de fois où la notification de vente incitative d'achat est présentée aux l'utilisateur. Si la limite quotidienne est atteinte, la notification de vente incitative ne s'affiche pas. les demandes d'achat (y compris les demandes de serveur de droits d'accès) sont limitées jusqu'à à minuit le lendemain. Les demandes d'achat effectuées après la limite quotidienne sont de atteint, par exemple,
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDrésultat.KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INTNombre maximal mensuel d'affichages de la notification de vente incitative d'achat pour l'utilisateur. Si la limite mensuelle est atteinte, la notification de vente incitative ne s'affiche pas et les demandes d'achat (y compris les demandes de serveur de droits d'accès) sont limitées jusqu'au premier jour du mois suivant. Les demandes d'achat effectuées après le si le maximum mensuel est atteint,
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDrésultat.KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRINGURL d'achat secondaire auprès de l'opérateur à présenter à l'utilisateur lorsqu'il clique sur le notification de vente incitative. Si l'URL d'achat est introuvable dans la réponse TS.43 du serveur des droits d'accès, cette valeur est utilisée à la place. Si ni l'URL du site la réponse TS.43 ou si la configuration de l'opérateur est valide, la demande d'achat échoue avec
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLEDrésultat.KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOLPermet d'autoriser ou non l'achat de fonctionnalités premium lorsque l'appareil est connectée à Long-Term Evolution (LTE). Si la valeur est
true, les demandes d'achat peuvent être à la fois sur LTE et sur New Radio (NR). Sifalse, les demandes d'achat ne peuvent être effectuées que sur les réseaux NR et les requêtes effectuées sur LTE échouent avec lePURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLErésultat.KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGDélai avant lequel la notification de vente incitative d'achat est présentée à l'utilisateur elle est automatiquement annulée. Lorsque la notification est annulée, les sont limitées et échouent avec
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDrésultat.KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGLa durée pendant laquelle les demandes d'achat ultérieures doivent être limitées après d'un échec dû à un délai d'inactivité ou à une annulation par l'utilisateur. Si l'utilisateur ne clique pas la notification de vente incitative d'achat dans le délai spécifié par
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGou s'il annule ou ignore la notification, cet intervalle entre les tentatives démarre. Alors que ce minuteur est actif, les demandes d'achat échouentPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDrésultat.KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGLa durée pendant laquelle les demandes d'achat ultérieures doivent être limitées après une défaillance due à l'opérateur ou au réseau. Si la vérification des droits d'accès échoue, l'URL ou si l'URL d'achat de l'opérateur indique un échec, cet intervalle entre les tentatives le minuteur démarre. Tant que ce minuteur est actif, les demandes d'achat échouent avec la
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDrésultat.KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONGDurée pendant laquelle le réseau doit définir une configuration de segmentation pour la capacité d'achat premium. Pendant cette période, tout achat ultérieur sont bloquées et renvoient le
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUPrésultat. Si le réseau ne parvient pas à établir une configuration de segmentation à temps, les applications peuvent une nouvelle demande d'achat de fonctionnalités premium. Le service de téléphonie ne tient pas compte jusqu'à ce que la configuration de segmentation correspondante soit envoyée, que l'utilisateur ait payé ou non l'opérateur.
Interface JavaScript
Lorsque l'utilisateur clique sur la notification d'optimisation réseau, un objet WebView avec
l'URL d'achat par l'opérateur
est présentée à l'utilisateur. Les opérateurs peuvent utiliser les API
fournies dans le
DataBoostWebServiceFlow
Interface JavaScript sur leur site Web d'achat pour communiquer avec le segment
l'application d'achat.
Le site Web de l'opérateur peut obtenir la fonctionnalité premium demandée via la méthode
getRequestedCapability()
Si l'achat aboutit, le site Web de l'opérateur doit en informer le segment
acheter l'application via notifyPurchaseSuccessful() ou
notifyPurchaseSuccessful(duration), où duration est un paramètre facultatif
indiquant la durée prévue de la tranche.
Si l'achat échoue, le site Web de l'opérateur doit en informer le segment
acheter l'application via la méthode notifyPurchaseFailed(code, reason), où code
est le code d'échec indiquant la raison de l'échec, et reason est le
un motif lisible de l'échec si le code d'échec est inconnu.
Si l'une de ces méthodes de réponse n'est pas appelée, l'achat n'est pas considérée comme terminée et que la demande d'achat finit par expirer.
Voici les codes d'échec valides que le site Web du transporteur peut renvoyer en cas d'échec de l'achat:
FAILURE_CODE_UNKNOWNFAILURE_CODE_CARRIER_URL_UNAVAILABLEFAILURE_CODE_AUTHENTICATION_FAILEDFAILURE_CODE_PAYMENT_FAILEDFAILURE_CODE_NO_USER_DATA
Une fois l'achat effectué, le transporteur doit mettre à jour le
Règles URSP
avec la tranche PRIORITIZE_LATENCY sur l'appareil de l'utilisateur.