Pour les appareils équipés d'Android 12 ou version ultérieure, Android est compatible avec le découpage de réseau 5G, qui consiste à utiliser 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. Le découpage de réseau 5G permet aux opérateurs de réseau de consacrer une partie du réseau à la fourniture de fonctionnalités spécifiques à un segment de clients particulier. Android 12 introduit les fonctionnalités de découpage de réseau d'entreprise 5G suivantes, que les opérateurs de réseau peuvent fournir à leurs clients professionnels:
Segmentation d'appareils d'entreprise pour les appareils entièrement gérés
Pour les entreprises qui fournissent à leurs employés des appareils professionnels entièrement gérés, les fournisseurs de réseau peuvent leur fournir une ou plusieurs tranches de réseau d'entreprise actives vers lesquelles le trafic sur les appareils professionnels est acheminé. À partir d'Android 12, Android permet aux opérateurs de fournir des tranches d'entreprise via des règles URSP, au lieu de configurer des tranches via des APN.
Segmentation d'applications d'entreprise pour les appareils avec des profils professionnels
Pour les entreprises qui utilisent la solution de profil professionnel, Android 12 permet aux appareils de router le trafic de toutes les applications du profil professionnel vers un segment de réseau d'entreprise. Les entreprises peuvent activer cette fonctionnalité via un Device Policy Controller (DPC).
La solution de profil professionnel fournit un niveau automatique d'authentification et de contrôle des accès dont les entreprises ont besoin pour s'assurer que seul le trafic provenant des applications d'entreprise du profil professionnel est acheminé vers le segment de réseau d'entreprise. Les applications du profil professionnel n'ont pas besoin d'être modifiées pour demander explicitement le segment de réseau d'entreprise.
Fonctionnement du découpage de réseau 5G dans AOSP
Android 12 prend en charge le découpage de réseau 5G grâce à des ajouts au code de base de la téléphonie dans AOSP et au module de partage de connexion pour intégrer les API de connectivité existantes requises pour le découpage de réseau.
La plate-forme de téléphonie Android fournit des API HAL et de téléphonie pour prendre en charge le fractionnement en fonction des requêtes réseau déposées par le code réseau principal et les fonctionnalités de fractionnement 5G du modem. La figure 1 décrit les composants de la fonctionnalité de découpage de réseau 5G.
Figure 1 : Architecture de découpage de réseau 5G dans AOSP.
La plate-forme de téléphonie et de connectivité est compatible avec les éléments suivants:
- 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 la sélection de l'itinéraire
- Retour au réseau par défaut si le segment de réseau d'entreprise n'est pas disponible
- Routage du trafic de toutes les applications du profil professionnel vers la connexion correspondante
Prise en charge du découpage d'entreprise
- Détecter la présence d'un profil professionnel sur l'appareil
- Vérification des autorisations ou des instructions de routage fournies par le DPC utilisé par l'administrateur informatique de l'entreprise
Le service de mise en réseau de base inclut les modifications suivantes apportées au module de partage de connexion sous Android 12:
- Ajoute la plupart des classes d'API publiques ou système
android.net.*au module de partage de connexion Élargit les limites du module de partage de connexion pour inclure les éléments suivants:
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
Transfère le code VPN hors du module de partage de connexion
Android 12 déplace le code avec les fonctionnalités suivantes vers le module de partage de connexion:
- Recevoir des requêtes d'applications pour des connexions réseau
- Recevoir des requêtes du système (par exemple, "placer ces applications sur un segment d'entreprise", introduit dans Android 12)
- 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
- Indiquer à netd comment acheminer le trafic par application (introduit dans Android 12)
- Informez les applications de ce qui se passe avec leur trafic réseau via des API
ConnectivityManagertelles queNetworkCallback,getActiveNetworketgetNetworkCapabilities.
Implémentation
Pour prendre en charge le découpage de la 5G sur un appareil, celui-ci doit disposer d'un modem compatible avec le HAL IRadio 1.6, qui dispose de l'API setupDataCall_1_6. Cette API configure une connexion de données et inclut les paramètres suivants pour prendre en charge le découpage de la 5G:
trafficDescriptor: spécifie le descripteur de trafic envoyé au modemsliceInfo: spécifie les informations à utiliser pour la tranche de réseau en cas de transfert EPDG vers la 5G.matchAllRuleAllowed: indique si l'utilisation d'une règle URSP par défaut de correspondance totale est autorisée. La téléphonie définit cette valeur sur "true" pour les réseaux par défaut, mais pas pour les tranches. La règle "Tout correspondre" est appliquée aux réseaux par défaut. Lorsqu'une application demande une tranche spécifique qui n'est pas disponible, la tranche spécifique est signalée comme non disponible. Pour les applications d'entreprise, le framework Telephony peut utiliser le réseau par défaut si le réseau d'entreprise n'est pas disponible.
Les modems doivent également implémenter l'API getSlicingConfig, sauf si elle n'est pas prise en charge par l'API getHalDeviceCapabilities.
Exigences concernant les entreprises
Ce qui suit décrit les exigences que les entreprises doivent respecter pour utiliser le découpage de réseau 5G sur les appareils dans un déploiement Android d'entreprise.
- Assurez-vous que les appareils entièrement gérés ou les appareils des employés configurés avec un profil professionnel sont compatibles avec la 5G SA et disposent de modems compatibles avec l'API
setupDataCall_1_6. - Collaborer avec le partenaire opérateur sur la configuration et les performances des tranches ou les caractéristiques du contrat de niveau de service.
Activer le fractionnement 5G sur les appareils configurés avec un profil professionnel
Pour les appareils configurés avec des profils professionnels, le découpage de 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 désactiver l'acheminement du trafic des applications du profil professionnel vers le segment de réseau d'entreprise par employé via le DPC EMM, qui utilise la méthode setPreferentialNetworkServiceEnabled dans l'API DevicePolicyManager (DPM) (introduite dans Android 12).
Les fournisseurs EMM disposant de DPC personnalisées doivent intégrer l'API DevicePolicyManager pour prendre en charge 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 différentes catégories de tranches, y compris le trafic d'entreprise, le trafic CBS, le trafic à faible latence et le trafic à bande passante élevée. Lors de la configuration des règles URSP pour différentes catégories de tranches, les opérateurs doivent utiliser les valeurs spécifiques à Android suivantes.
| ID | Valeur | Description |
|---|---|---|
| OSId | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
L'OSId d'Android est un UUID de version 5 généré avec l'OID ISO de l'espace de noms et le nom "Android". |
Les opérateurs doivent configurer des règles URSP pour chaque trafic de tranche avec le composant de descripteur de trafic défini sur "ID de l'OS + type d'ID de l'application de l'OS". Par exemple, la tranche "ENTREPRISE" doit avoir une valeur de 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345.
Cette valeur est une concatenaison de l'OSId, de la longueur de l'OSAppId (0x0A) et de l'OSAppId.
Pour en savoir plus sur le type de composant de descripteur de trafic, consultez la table 5.2.1 de la spécification 3GPP TS 24.526.
Le tableau suivant décrit les valeurs OSAppId pour différentes catégories de tranches.
| Catégorie de tranche | OSAppId | Description |
|---|---|---|
| ENTREPRISE | 0x454E5445525052495345 |
L'OSAppId est une représentation de tableau d'octets de la chaîne "ENTERPRISE". |
| ENTERPRISE2 | 0x454E544552505249534532 |
L'OSAppId est une représentation de tableau d'octets de la chaîne "ENTERPRISE2". |
| ENTERPRISE3 | 0x454E544552505249534533 |
L'OSAppId est une représentation de tableau d'octets de la chaîne "ENTERPRISE3". |
| ENTERPRISE4 | 0x454E544552505249534534 |
L'OSAppId est une représentation de tableau d'octets de la chaîne "ENTERPRISE4". |
| ENTERPRISE5 | 0x454E544552505249534535 |
L'OSAppId est une représentation de tableau d'octets de la chaîne "ENTERPRISE5". |
| CBS | 0x434253 |
L'OSAppId est une représentation de tableau d'octets de la chaîne "CBS". |
| PRIORITIZE_LATENCY | 0x5052494f524954495a455f4c4154454e4359 |
L'OSAppId est une représentation de tableau d'octets de la chaîne "PRIORITIZE_LATENCY". |
| PRIORITIZE_BANDWIDTH | 0x5052494f524954495a455f42414e445749445448 |
L'OSAppId est une représentation d'une matrice 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, les CBS, la faible latence, la bande passante élevée et le trafic par défaut.
Entreprise 1
La prise en charge d'Enterprise 1 est disponible sous Android 12 ou version ultérieure. Voici un exemple de règle URSP pour le trafic ENTERPRISE1:
| Règle URSP 1 (enterprise1) | |
|---|---|
| Priorité | 1 (0x01) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
| Descripteur de sélection de l'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2: DNN | entreprise |
| Descripteur de sélection de l'itinéraire 2 | |
| Priorité | 2 (0x02) |
| Composant 1: DNN | entreprise |
Enterprise 2
La prise en charge d'Enterprise 2 est disponible sous Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE2:
| Règle URSP 2 (enterprise2) | |
|---|---|
| Priorité | 2 (0x02) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
| Descripteur de sélection de l'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2: DNN | enterprise2 |
| Descripteur de sélection de l'itinéraire 2 | |
| Priorité | 2 (0x02) |
| Composant 1: DNN | enterprise2 |
Enterprise 3
La prise en charge d'Enterprise 3 est disponible sous Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE3:
| Règle 3 de l'URSP (enterprise3) | |
|---|---|
| Priorité | 3 (0x03) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Descripteur de sélection de l'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2: DNN | enterprise3 |
| Descripteur de sélection de l'itinéraire 2 | |
| Priorité | 2 (0x02) |
| Composant 1: DNN | enterprise3 |
Enterprise 4
La prise en charge d'Enterprise 4 est disponible sous Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE4:
| Règle 4 de l'URSP (enterprise4) | |
|---|---|
| Priorité | 4 (0x04) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Descripteur de sélection de l'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2: DNN | enterprise4 |
| Descripteur de sélection de l'itinéraire 2 | |
| Priorité | 2 (0x02) |
| Composant 1: DNN | enterprise4 |
Enterprise 5
La prise en charge d'Enterprise 5 est disponible sous Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE5:
| Règle 5 de l'URSP (enterprise5) | |
|---|---|
| Priorité | 5 (0x05) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Descripteur de sélection de l'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2: DNN | enterprise5 |
| Descripteur de sélection de l'itinéraire 2 | |
| Priorité | 2 (0x02) |
| Composant 1: DNN | enterprise5 |
CBS
La prise en charge de CBS est disponible sous Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic CBS:
| Règle 6 de l'URSP (CBS) | |
|---|---|
| Priorité | 6 (0x06) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E4703434253 |
| Descripteur de sélection de l'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2: DNN | cbs |
| Descripteur de sélection de l'itinéraire 2 | |
| Priorité | 2 (0x02) |
| Composant 1: DNN | cbs |
Latence faible
La prise en charge de la faible latence est disponible sous Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic LOW_LATENCY:
| Règle 7 de l'URSP (faible latence) | |
|---|---|
| Priorité | 7 (0x07) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Descripteur de sélection de l'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2: DNN | latence |
| Descripteur de sélection de l'itinéraire 2 | |
| Priorité | 2 (0x02) |
| Composant 1: DNN | latence |
Bande passante élevée
La prise en charge de la bande passante élevée est disponible sous Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic HIGH_BANDWIDTH:
| Règle 8 de l'URSP (bande passante élevée) | |
|---|---|
| Priorité | 8 (0x08) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + Type d'ID de l'application de l'OS | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Descripteur de sélection de l'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1: S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2: DNN | bande passante |
| Descripteur de sélection de l'itinéraire 2 | |
| Priorité | 2 (0x02) |
| Composant 1: DNN | bande passante |
Par défaut
| Règle URSP 9 (par défaut) | |
|---|---|
| Priorité | 9 (0x09) |
| Descripteur de trafic n° 1 | |
| match-all | N/A |
| Descripteur de sélection de l'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1: S-NSSAI | SST:XX SD:YYYYYY |
Tests
Pour tester le découpage de 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 non par défaut correspondant à la catégorie d'entreprise, que le descripteur de sélection de route correspondant mappe la catégorie d'entreprise sur la tranche d'entreprise, et qu'une règle par défaut dirige le trafic vers la tranche Internet par défaut.
Assurez-vous qu'un profil professionnel est configuré sur l'appareil.
Activer l'utilisation du découpage de réseau via le DPC
Pour tester le comportement du découpage de réseau 5G, procédez comme suit:
- Vérifiez qu'une session PDU est établie avec le segment d'entreprise (par exemple, à l'aide d'une adresse IP spécifique) et que les applications du profil professionnel utilisent cette session PDU.
- Vérifiez qu'une session PDU distincte est établie avec la tranche Internet par défaut et que les applications du profil personnel utilisent la session PDU.
Vente incitative de la segmentation 5G
La fonctionnalité de vente incitative de la segmentation de réseau 5G, disponible à partir d'Android 14-QPR1, permet aux opérateurs de proposer à leurs utilisateurs des fonctionnalités réseau améliorées (latence et bande passante) grâce à la segmentation de réseau 5G.
La fonctionnalité de vente incitative de la segmentation 5G utilise la réponse TS.43 du serveur d'autorisation du transporteur pour générer le parcours d'achat. Les opérateurs peuvent utiliser la réponse pour spécifier l'URL de la WebView d'achat de l'opérateur, envoyer des données supplémentaires à la WebView et indiquer si la tranche est provisionnée et disponible sur le réseau de l'opérateur.
Les opérateurs peuvent personnaliser le comportement de la fonctionnalité de vente incitative de la segmentation 5G à l'aide de configurations d'opérateur, qui contrôlent si des demandes d'achat peuvent être effectuées, quand les applications sont autorisées à demander des fonctionnalités premium et la durée d'attente du framework Telephony pour les réponses de l'utilisateur ou du réseau.
La fonctionnalité de vente incitative de la segmentation 5G fournit une interface, appelée DataBoostWebServiceFlow, pour permettre la communication entre Android et la WebView de l'opérateur.
La figure 2 illustre le parcours d'achat d'une offre de vente incitative de slicing 5G:
Figure 2. Parcours d'achat d'upsell de la fonctionnalité de découpage de la 5G.
Procédure d'attribution des droits TS.43
Lorsqu'un utilisateur demande des fonctionnalités réseau améliorées, le framework Telephony demande la configuration des droits d'accès au service pour la fonctionnalité premium demandée. Si la réponse TS.43 est valide, le framework Telephony utilise les champs de la réponse HTTP pour générer la requête d'achat.
Champs d'achats segmentés
La configuration des droits d'accès TS.43 inclut les champs d'achat de segment suivants:
- É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)
Le framework Telephony utilise la combinaison de l'état d'éligibilité et de l'état de provisionnement pour déterminer l'état actuel de l'achat de la tranche. Le résultat peut être l'un des suivants:
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 du droit d'accès est 1 (activé) et que l'état de provisionnement est 0 (non provisionné), le framework Telephony affiche une notification d'incitation à l'achat pour inviter l'utilisateur à acheter l'amélioration via la vue Web du transporteur. Le tableau suivant décrit le comportement du framework Telephony pour différentes combinaisons de valeurs d'état de provisionnement et d'éligibilité.
| État du provisionnement | |||||
|---|---|---|---|---|---|
Non provisionné (0) |
Provisionné (1 |
Non disponible (2) |
En cours (3) |
||
| État des droits d'accès | Désactivé (0) |
Échec | Échec | Échec | Échec |
Activé (1) |
Afficher la WebView | Déjà acheté | Déjà acheté | En cours | |
Incompatible (2) |
Échec | Échec | Échec | Échec | |
Provisionnement (3) |
Erreur du transporteur | Erreur du transporteur | En cours | En cours | |
Inclus (4) |
Erreur du transporteur | Déjà acheté | Déjà acheté | Erreur du transporteur | |
Champs du flux de service
La réponse TS.43 spécifie l'URL, les données utilisateur et le type de contenu pour personnaliser le comportement de la WebView d'achat auprès du transporteur. 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 à l'URL en tant que paramètre de requête (par exemple, https://www.android.com?encodedValue=Base64EncodedUserData). Si elles n'existent pas, 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 requête POST, et les données utilisateur (décodées si elles sont encodées en base64) sont envoyées en tant que données de 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 de l'opérateur
Voici les configurations de l'opérateur disponibles pour personnaliser le comportement de la fonctionnalité de vente incitative de la segmentation 5G.
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAYListe des fonctionnalités premium compatibles. Il s'agit d'un tableau int de
TelephonyManager.PremiumCapability. Ces fonctionnalités premium partagent la même valeur que la classeNetworkCapabilities.NetCapabilitycorrespondante. Si une fonctionnalité premium est demandée et qu'elle n'est pas incluse dans cette configuration, la requête d'achat échoue avec le résultatCARRIER_DISABLED.Dans Android 14, seul
PREMIUM_CAPABILITY_PRIORITIZE_LATENCYest compatible.KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INTNombre maximal de fois par jour où la notification de vente incitative est présentée à l'utilisateur. Si le nombre maximal quotidien est atteint, la notification de vente incitative ne s'affiche pas et les demandes d'achat (y compris les requêtes du serveur d'autorisation) sont limitées jusqu'à minuit du jour suivant. Les requêtes d'achat effectuées après le nombre maximal quotidien atteint échouent avec le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INTNombre maximal de fois par mois où la notification d'incitation à l'achat est présentée à l'utilisateur. Si le nombre maximal mensuel est atteint, la notification de vente incitative ne s'affiche pas et les demandes d'achat (y compris les requêtes du serveur d'attribution de droits d'accès) sont limitées jusqu'au premier jour du mois suivant. Les requêtes d'achat effectuées après avoir atteint le plafond mensuel échouent avec le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRINGURL d'achat du transporteur de secours à afficher à l'utilisateur lorsqu'il clique sur la notification d'incitation à l'achat. Si l'URL d'achat n'est pas trouvée dans la réponse TS.43 du serveur d'autorisation, cette valeur est utilisée à la place. Si ni l'URL de la réponse TS.43 ni la configuration du transporteur ne sont valides, la demande d'achat échoue avec le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOLIndique si les fonctionnalités premium peuvent être achetées lorsque l'appareil est connecté à la technologie LTE (Long-Term Evolution). Si la valeur est
true, les demandes d'achat peuvent être effectuées à la fois sur LTE et sur New Radio (NR). Si la valeur estfalse, les demandes d'achat ne peuvent être effectuées que sur NR, et les demandes effectuées sur LTE échouent avec le résultatPURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGDurée pendant laquelle la notification de vente incitative doit être affichée à l'utilisateur avant d'être automatiquement annulée. Lorsque la notification est annulée, les requêtes ultérieures sont limitées et échouent avec le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGDurée pendant laquelle les demandes d'achat ultérieures doivent être limitées après un échec en raison d'un délai avant expiration ou d'une annulation par l'utilisateur. Si l'utilisateur ne clique pas sur 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, ce minuteur de délai avant expiration commence. Lorsque ce minuteur est actif, les requêtes d'achat échouent avec le résultatPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGDurée pendant laquelle les demandes d'achat suivantes doivent être limitées après un échec dû à l'opérateur ou au réseau. Si la vérification des droits d'accès échoue, si l'URL est indisponible ou si l'URL d'achat auprès du transporteur indique un échec, ce minuteur de délai avant expiration démarre. Lorsque ce minuteur est actif, les demandes d'achat échouent avec le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONGDurée pendant laquelle le réseau doit configurer une configuration de fractionnement pour la fonctionnalité d'achat premium. Pendant cette période, les requêtes d'achat ultérieures sont bloquées et renvoient le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Si le réseau ne parvient pas à configurer une configuration de segmentation à temps, les applications peuvent demander à nouveau à acheter des fonctionnalités premium. La téléphonie ne considère pas un achat comme terminé tant que la configuration de fractionnement correspondante n'a pas été envoyée, que l'utilisateur ait payé le transporteur ou non.
Interface JavaScript
Lorsque l'utilisateur clique sur la notification de boost de réseau, un objet WebView avec l'URL d'achat de l'opérateur est affiché. Les opérateurs peuvent utiliser les API fournies dans l'interface JavaScript DataBoostWebServiceFlow de leur site Web d'achat pour communiquer avec l'application d'achat de tranches.
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 informer l'application d'achat de la tranche 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 l'application d'achat de tranche via la méthode notifyPurchaseFailed(code, reason), où code est le code d'échec indiquant la raison de l'échec et reason est la raison de l'échec lisible par l'humain 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é comme terminé et la requête d'achat finit par expirer.
Voici les codes d'erreur 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é, l'opérateur doit mettre à jour les règles URSP avec la tranche PRIORITIZE_LATENCY sur l'appareil de l'utilisateur.