Pour les appareils exécutant Android 12 ou version ultérieure, Android prend en charge le découpage du réseau 5G, l'utilisation de la virtualisation du réseau pour diviser les 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 du réseau 5G permet aux opérateurs de réseau de consacrer une partie du réseau à fournir des fonctionnalités spécifiques à un segment particulier de clients. Android 12 introduit les capacités de découpage du réseau d'entreprise 5G suivantes, que les opérateurs de réseau peuvent fournir à leurs entreprises clientes :
Découpage des appareils d'entreprise pour les appareils entièrement gérés
Pour les entreprises qui fournissent des appareils d'entreprise entièrement gérés à leurs employé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 de l'entreprise est acheminé. À partir d'Android 12, Android permet aux opérateurs de fournir des tranches d'entreprise via les règles URSP, au lieu de configurer des tranches via des APN.
Découpage des applications professionnelles d'entreprise pour les appareils dotés de profils professionnels
Pour les entreprises utilisant la solution de profil professionnel , Android 12 permet aux appareils d'acheminer le trafic de toutes les applications du profil professionnel vers une tranche 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 d'accès dont les entreprises ont besoin pour garantir que seul le trafic des applications d'entreprise du profil professionnel est acheminé vers la tranche de réseau d'entreprise. Les applications du profil professionnel n’ont pas besoin d’être modifiées pour demander explicitement la tranche de réseau d’entreprise.
Comment fonctionne le découpage du réseau 5G dans AOSP
Android 12 introduit la prise en charge du découpage du réseau 5G grâce à des ajouts à la base de code de téléphonie dans AOSP et au module Tethering pour intégrer les API de connectivité existantes requises pour le 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 le découpage en fonction des requêtes réseau déposées par le code du réseau principal et des capacités de découpage 5G du modem. La figure 1 décrit les composants de la fonctionnalité de découpage du réseau 5G.
Figure 1. Architecture de découpage du réseau 5G dans AOSP.
La plateforme de téléphonie et de connectivité prend en charge :
- Conversion des requêtes réseau pour les catégories de tranches en descripteurs de trafic qui sont ensuite transmis au modem pour la correspondance du trafic URSP et la sélection de l'itinéraire.
- Revenir au réseau par défaut si la tranche de réseau d'entreprise n'est pas disponible
- Acheminer le trafic de toutes les applications sous le profil professionnel vers la connexion correspondante
Soutenir le découpage des entreprises
- Détection de 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 réseau principal inclut les modifications suivantes apportées au module Tethering dans Android 12 :
- Ajoute la plupart des classes d'API publiques ou système
android.net.*
au module Tethering Étend les limites du module Tethering 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.java
-
f/b/services/core/java/com/android/server/TestNetworkService.java
-
Déplace le code VPN hors du module Tethering
Android 12 déplace le code avec les fonctionnalités suivantes vers le module Tethering :
- Réception de demandes d'applications pour les connexions réseau
- Réception de requêtes du système (par exemple, « placer ces applications sur une tranche d'entreprise » ; introduit dans Android 12)
- Envoi de requêtes du système au code de téléphonie qui tente de mettre en place des réseaux ou des tranches en passant par l'API HAL et le modem
- Informer netd de la manière d'acheminer le trafic pour chaque application (introduit dans Android 12)
- Informer les applications de ce qui arrive à leur trafic réseau via les API
ConnectivityManager
telles queNetworkCallback
,getActiveNetwork
,getNetworkCapabilities
.
Mise en œuvre
Pour prendre en charge le découpage 5G sur un appareil, celui-ci doit disposer d'un modem prenant en charge le HAL IRadio 1.6 doté de l'API setupDataCall_1_6
. Cette API établit une connexion de données et inclut les paramètres suivants pour prendre en charge le découpage 5G :
-
trafficDescriptor
: Spécifie le descripteur de trafic envoyé au modem -
sliceInfo
: spécifie les informations sur la tranche de réseau à utiliser en cas de transfert d'EPDG vers la 5G -
matchAllRuleAllowed
: Spécifie si l'utilisation d'une règle URSP de correspondance totale par défaut est autorisée. La téléphonie définit cela sur vrai pour les réseaux par défaut mais pas pour les tranches. La règle "match all" 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, la structure de téléphonie peut revenir au 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 est signalée comme non prise en charge par l'API getHalDeviceCapabilities
.
Exigences de l'entreprise
Ce qui suit décrit les conditions requises pour que les entreprises utilisent le découpage de réseau 5G sur les appareils dans un déploiement d'entreprise Android.
- Assurez-vous que les appareils entièrement gérés ou ceux des employés configurés avec un profil professionnel sont compatibles 5G SA avec des modems prenant en charge l'API
setupDataCall_1_6
. - Travaillez avec le partenaire opérateur sur la configuration des tranches et les performances ou les caractéristiques des SLA.
Activation du 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 du réseau, les administrateurs informatiques de l'entreprise peuvent activer ou désactiver le routage du trafic des applications de profil professionnel vers la tranche de réseau d'entreprise pour chaque employé via le DPC EMM, qui utilise la méthode setPreferentialNetworkServiceEnabled
dans l'API DevicePolicyManager
(DPM) (introduite dans Android). 12).
Les fournisseurs EMM dotés de DPC personnalisés doivent intégrer l'API DevicePolicyManager
pour prendre en charge les clients d'entreprise.
Règles URSP
Cette section comprend des informations destinées aux opérateurs sur la configuration des règles URSP pour différentes catégories de tranches, notamment le trafic d'entreprise, CBS, à faible latence et à 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.
IDENTIFIANT | Valeur | Description |
---|---|---|
ID OS | 97a498e3-fc92-5c94-8986-0333d06e4e47 | L'OSID pour Android est un UUID version 5 généré avec l'espace de noms ISO OID et le nom « Android ». |
Les opérateurs doivent configurer les règles URSP pour chaque tranche de trafic avec le composant descripteur de trafic comme « ID du système d'exploitation + type d'identifiant de l'application du système d'exploitation ». Par exemple, la tranche "ENTERPRISE" doit avoir une valeur de 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
. Cette valeur est une concaténation de l'OSId, de la longueur de l'OSAppId ( 0x0A
) et de l'OSAppId. Pour plus d'informations sur le type de composant du descripteur de trafic, voir 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 | IDAppOS | Description |
---|---|---|
ENTREPRISE | 0x454E5445525052495345 | OSAppId est une représentation sous forme de tableau d'octets de la chaîne "ENTERPRISE". |
ENTREPRISE2 | 0x454E544552505249534532 | OSAppId est une représentation sous forme de tableau d'octets de la chaîne "ENTERPRISE2". |
ENTREPRISE3 | 0x454E544552505249534533 | OSAppId est une représentation sous forme de tableau d'octets de la chaîne "ENTERPRISE3". |
ENTREPRISE4 | 0x454E544552505249534534 | OSAppId est une représentation sous forme de tableau d'octets de la chaîne "ENTERPRISE4". |
ENTREPRISE5 | 0x454E544552505249534535 | OSAppId est une représentation sous forme de tableau d'octets de la chaîne "ENTERPRISE5". |
CBS | 0x434253 | OSAppId est une représentation sous forme de tableau d'octets de la chaîne "CBS". |
PRIORITIZE_LATENCY | 0x5052494f524954495a455f4c4154454e4359 | OSAppId est une représentation sous forme de tableau d'octets de la chaîne "PRIORITIZE_LATENCY" |
PRIORITIZE_BANDWIDTH | 0x5052494f524954495a455f42414e445749445448 | OSAppId est une représentation sous forme de 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 le trafic d'entreprise, CBS, à faible latence, à bande passante élevée et par défaut.
Entreprise 1
La prise en charge d'Enterprise 1 est disponible sur Android 12 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE1 :
Règle URSP n°1 (entreprise1) | |
---|---|
Priorité | 1 (0x01) |
Descripteur de trafic n°1 | |
ID du système d'exploitation + type d'identifiant de l'application du système d'exploitation | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
Descripteur de sélection d'itinéraire #1 | |
Priorité | 1 (0x01) |
Composant n°1 : S-NSSAI | SST : XX SD : AAAAAA |
Composant n°2 : DNN | entreprise |
Descripteur de sélection d'itinéraire #2 | |
Priorité | 2 (0x02) |
Composant n° 1 : DNN | entreprise |
Entreprise 2
La prise en charge d’Enterprise 2 est disponible sur Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE2 :
Règle URSP n°2 (entreprise2) | |
---|---|
Priorité | 2 (0x02) |
Descripteur de trafic n°1 | |
ID du système d'exploitation + type d'identifiant de l'application du système d'exploitation | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
Descripteur de sélection d'itinéraire #1 | |
Priorité | 1 (0x01) |
Composant n°1 : S-NSSAI | SST : XX SD : AAAAAA |
Composant n°2 : DNN | entreprise2 |
Descripteur de sélection d'itinéraire #2 | |
Priorité | 2 (0x02) |
Composant n° 1 : DNN | entreprise2 |
Entreprise 3
La prise en charge d’Enterprise 3 est disponible sur Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE3 :
Règle URSP n°3 (entreprise3) | |
---|---|
Priorité | 3 (0x03) |
Descripteur de trafic n°1 | |
ID du système d'exploitation + type d'identifiant de l'application du système d'exploitation | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
Descripteur de sélection d'itinéraire #1 | |
Priorité | 1 (0x01) |
Composant n°1 : S-NSSAI | SST : XX SD : AAAAAA |
Composant n°2 : DNN | entreprise3 |
Descripteur de sélection d'itinéraire #2 | |
Priorité | 2 (0x02) |
Composant n° 1 : DNN | entreprise3 |
Entreprise 4
La prise en charge d’Enterprise 4 est disponible sur Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE4 :
Règle URSP n°4 (entreprise4) | |
---|---|
Priorité | 4 (0x04) |
Descripteur de trafic n°1 | |
ID du système d'exploitation + type d'identifiant de l'application du système d'exploitation | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
Descripteur de sélection d'itinéraire #1 | |
Priorité | 1 (0x01) |
Composant n°1 : S-NSSAI | SST : XX SD : AAAAAA |
Composant n°2 : DNN | entreprise4 |
Descripteur de sélection d'itinéraire #2 | |
Priorité | 2 (0x02) |
Composant n° 1 : DNN | entreprise4 |
Entreprise 5
La prise en charge d’Enterprise 5 est disponible sur Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE5 :
Règle URSP n°5 (entreprise5) | |
---|---|
Priorité | 5 (0x05) |
Descripteur de trafic n°1 | |
ID du système d'exploitation + type d'identifiant de l'application du système d'exploitation | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
Descripteur de sélection d'itinéraire #1 | |
Priorité | 1 (0x01) |
Composant n°1 : S-NSSAI | SST : XX SD : AAAAAA |
Composant n°2 : DNN | entreprise5 |
Descripteur de sélection d'itinéraire #2 | |
Priorité | 2 (0x02) |
Composant n° 1 : DNN | entreprise5 |
CBS
La prise en charge de CBS est disponible dans Android 13 et versions ultérieures. 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 du système d'exploitation + type d'identifiant de l'application du système d'exploitation | 0x97A498E3FC925C9489860333D06E4E4703434253 |
Descripteur de sélection d'itinéraire #1 | |
Priorité | 1 (0x01) |
Composant n°1 : S-NSSAI | SST : XX SD : AAAAAA |
Composant n°2 : DNN | CBS |
Descripteur de sélection d'itinéraire #2 | |
Priorité | 2 (0x02) |
Composant n° 1 : DNN | CBS |
Faible latence
La prise en charge de la faible latence est disponible sur Android 13 et versions ultérieures. 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 du système d'exploitation + type d'identifiant de l'application du système d'exploitation | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
Descripteur de sélection d'itinéraire #1 | |
Priorité | 1 (0x01) |
Composant n°1 : S-NSSAI | SST : XX SD : AAAAAA |
Composant n°2 : DNN | latence |
Descripteur de sélection d'itinéraire #2 | |
Priorité | 2 (0x02) |
Composant n° 1 : DNN | latence |
Bande passante élevée
La prise en charge de la bande passante élevée est disponible dans Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic HIGH_BANDWIDTH :
Règle URSP n°8 (large bande passante élevée) | |
---|---|
Priorité | 8 (0x08) |
Descripteur de trafic n°1 | |
ID du système d'exploitation + type d'identifiant de l'application du système d'exploitation | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
Descripteur de sélection d'itinéraire #1 | |
Priorité | 1 (0x01) |
Composant n°1 : S-NSSAI | SST : XX SD : AAAAAA |
Composant n°2 : DNN | bande passante |
Descripteur de sélection d'itinéraire #2 | |
Priorité | 2 (0x02) |
Composant n° 1 : DNN | bande passante |
Défaut
Règle URSP n°9 (par défaut) | |
---|---|
Priorité | 9 (0x09) |
Descripteur de trafic n°1 | |
match-all | N / A |
Descripteur de sélection d'itinéraire #1 | |
Priorité | 1 (0x01) |
Composant n°1 : S-NSSAI | SST : XX SD : AAAAAA |
Essai
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 d'entreprise et que le descripteur de sélection d'itinéraire correspondant mappe la catégorie d'entreprise à la tranche d'entreprise ; et une règle par défaut dirigeant le trafic vers la tranche Internet par défaut.
Assurez-vous qu'un profil professionnel est configuré sur l'appareil.
Choisissez d'utiliser le découpage de réseau via le DPC
Pour tester le comportement de découpage du réseau 5G, procédez comme suit :
- Vérifiez qu'une session PDU est établie avec la tranche d'entreprise (par exemple, en utilisant 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 découpage 5G
La fonctionnalité de vente incitative de découpage 5G, disponible à partir d'Android 14-QPR1, permet aux opérateurs d'offrir des capacités réseau améliorées (latence et bande passante) à leurs utilisateurs via le découpage de réseau 5G.
La fonctionnalité de vente incitative de découpage 5G utilise la réponse TS.43 du serveur d'autorisation de l'opérateur pour piloter le flux d'achat. Les opérateurs peuvent utiliser la réponse pour spécifier l'URL de la vue Web d'achat du transporteur, envoyer des données supplémentaires à la vue Web 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 découpage 5G à l'aide des configurations de l'opérateur, qui contrôlent si les demandes d'achat peuvent être effectuées, quand les applications sont autorisées à demander des fonctionnalités premium et combien de temps le cadre de téléphonie 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 la vue Web de l'opérateur.
La figure 2 montre le flux d’achat de vente incitative de découpage 5G :
Figure 2. Flux d’achat de ventes incitatives 5G.
Processus d'admissibilité TS.43
Lorsqu'un utilisateur fait une demande de capacités réseau améliorées, le cadre de téléphonie demande la configuration des droits de service pour la capacité premium demandée. Si la réponse TS.43 est valide, la structure de téléphonie utilise les champs de la réponse HTTP pour piloter la demande d'achat.
Champs d'achat en tranches
La configuration des droits TS.43 comprend les champs d'achat de tranches suivants :
- Statut d'admissibilité
Clé :
EntitlementStatus
Type :
int
Valeurs prises en charge :
0
(désactivé),1
(activé),2
(incompatible),3
(approvisionnement),4
(inclus)- Statut d'approvisionnement
Clé :
ProvStatus
Type :
int
Valeurs prises en charge :
0
(non provisionné),1
(provisionné),2
(non disponible),3
(en cours)
L'infrastructure de téléphonie utilise la combinaison du statut de droit et du statut de provisionnement pour déterminer l'état actuel d'achat de tranche. Le résultat peut être l'un des suivants :
-
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASED
-
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESS
-
PURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILED
-
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
Si l'état du droit est 1
(activé) et que l'état de provisionnement est 0
(non provisionné), la structure de téléphonie affiche une notification de vente incitative à l'utilisateur pour qu'il achète le boost via la vue Web de l'opérateur. Le tableau suivant décrit le comportement de l'infrastructure de téléphonie pour différentes combinaisons de valeurs d'état de provisionnement et d'autorisation.
Statut d'approvisionnement | |||||
---|---|---|---|---|---|
Non provisionné ( 0 ) | Provisionné ( 1 ) 1 ) | Non disponible ( 2 ) | En cours ( 3 ) | ||
Statut d'admissibilité | Désactivé ( 0 ) | Échoué | Échoué | Échoué | Échoué |
Activé ( 1 ) | Afficher la vue Web | Déjà acheté | Déjà acheté | En cours | |
Incompatible ( 2 ) | Échoué | Échoué | Échoué | Échoué | |
Approvisionnement ( 3 ) | Erreur de transporteur | Erreur de transporteur | En cours | En cours | |
Inclus ( 4 ) | Erreur de transporteur | Déjà acheté | Déjà acheté | Erreur de transporteur |
Champs de flux de services
La réponse TS.43 spécifie l'URL, les données utilisateur et le type de contenu pour personnaliser le comportement d'affichage Web d'achat 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 à l'URL en tant que paramètre de requête (par exemple, https://www.android.com?encodedValue=Base64EncodedUserData
) ; et si elle n'existe 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 codées en Base 64) sont envoyées en tant que données pour la requête POST.
- URL
Clé :
ServiceFlow_URL
Type :
String
Exemple :
"https://www.android.com"
- Données d'utilisateur
Clé :
ServiceFlow_UserData
Type :
String
Exemple :
"encodedValue=Base64EncodedUserData"
- Type de contenu
Clé :
ServiceFlow_ContentsType
Type :
String
Valeurs prises en charge :
0
(non spécifié),1
(JSON),2
(XML)
Configurations de transporteur
Voici les configurations d'opérateur disponibles pour personnaliser le comportement de la fonctionnalité de vente incitative de découpage 5G.
-
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY
Une liste des fonctionnalités premium prises en charge. Il s'agit d'un tableau int de
TelephonyManager.PremiumCapability
. Ces fonctionnalités premium partagent la même valeur que la classeNetworkCapabilities.NetCapability
correspondante. Si une fonctionnalité premium est demandée et qu'elle n'est pas incluse dans cette configuration, la demande d'achat échoue avec le résultatCARRIER_DISABLED
.Sous Android 14, seul
PREMIUM_CAPABILITY_PRIORITIZE_LATENCY
est pris en charge.-
KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT
Nombre maximum quotidien de fois où la notification de vente incitative d'achat est affichée à l'utilisateur. Si le maximum quotidien est atteint, la notification de vente incitative ne s'affiche pas et les demandes d'achat (y compris les demandes du serveur de droits) sont limitées jusqu'à minuit le lendemain. Les demandes d'achat effectuées après que le maximum quotidien soit atteint échouent avec le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED
.-
KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT
Nombre mensuel maximum de fois où la notification de vente incitative d'achat est affichée à l'utilisateur. Si le maximum mensuel est atteint, la notification de vente incitative ne s'affiche pas et les demandes d'achat (y compris les demandes du serveur de droits) sont limitées jusqu'au premier jour du mois suivant. Les demandes d'achat effectuées après que le maximum mensuel soit atteint échouent avec le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED
.-
KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING
URL d'achat de l'opérateur de secours à afficher à l'utilisateur lorsqu'il clique sur la notification de vente incitative. Si l'URL d'achat n'est pas trouvée dans la réponse TS.43 du serveur de droits, cette valeur est utilisée à la place. Si ni l'URL de la réponse TS.43 ni la configuration de l'opérateur ne sont valides, la demande d'achat échoue avec le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED
.-
KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL
S'il faut autoriser l'achat de fonctionnalités premium lorsque l'appareil est connecté à Long-Term Evolution (LTE). Si c'est
true
, les demandes d'achat peuvent être effectuées à la fois sur LTE et sur New Radio (NR). Sifalse
, 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_LONG
Délai nécessaire pour afficher la notification de vente incitative d'achat à l'utilisateur avant qu'elle ne soit automatiquement annulée. Lorsque la notification est annulée, les demandes suivantes sont limitées et échouent avec le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED
.-
KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG
La durée pendant laquelle les demandes d'achat ultérieures doivent être limitées après un échec dû à un délai d'attente ou à une annulation par l'utilisateur. Si l'utilisateur ne clique pas sur la notification d'achat et de vente incitative dans le délai spécifié par
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG
ou s'il annule ou rejette la notification, ce délai d'attente démarre. Pendant que ce minuteur est actif, les demandes d'achat échouent avec le résultatPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED
.-
KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG
La durée pendant laquelle les demandes d'achat ultérieures doivent être limitées après une panne due à l'opérateur ou au réseau. Si la vérification des droits échoue, que l'URL n'est pas disponible ou que l'URL d'achat de l'opérateur indique un échec, ce délai d'attente démarre. Pendant que 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_LONG
Délai pendant lequel le réseau doit configurer une configuration de découpage pour la fonctionnalité premium d'achat. Pendant cette période, les demandes 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 découpage à temps, les applications peuvent demander à nouveau l'achat de fonctionnalités premium. La téléphonie ne considère pas un achat comme terminé tant que la configuration de découpage correspondante n'est pas envoyée, que l'utilisateur ait payé ou non l'opérateur.
Interface Javascript
Lorsque l'utilisateur clique sur la notification d'augmentation du réseau, un objet WebView
avec l'URL d'achat de l'opérateur s'affiche à l'utilisateur. Les transporteurs peuvent utiliser les API fournies dans l'interface Javascript DataBoostWebServiceFlow
dans 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 réussit, le site Web de l'opérateur doit informer l'application d'achat de 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 du transporteur doit en informer l'application d'achat de tranches 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 lisible de l'échec si le le code de panne est inconnu.
Si aucune de ces méthodes de réponse n’est appelée, l’achat ne sera pas considéré comme terminé et la demande d’achat finira par expirer.
Voici les codes d'échec valides que le site Web du transporteur peut renvoyer en cas d'échec d'achat :
-
FAILURE_CODE_UNKNOWN
-
FAILURE_CODE_CARRIER_URL_UNAVAILABLE
-
FAILURE_CODE_AUTHENTICATION_FAILED
-
FAILURE_CODE_PAYMENT_FAILED
-
FAILURE_CODE_NO_USER_DATA
Une fois l'achat terminé, le transporteur doit mettre à jour les règles URSP avec la tranche PRIORITIZE_LATENCY
sur l'appareil de l'utilisateur.