Eh bien, j'ai lu beaucoup de temps à propos de "la charge utile du développeur" mais je ne comprends pas clairement, que pour "la charge utile du développeur" utilisée. Donc, j'essaie d'utiliser cela aussi vide que ceci: et ceci: donc j'ai donc une image. pour 3 situations. Je veux apprendre ce qui va se passer après la condition 
3 Réponses :
Ce n'est pas nécessaire, mais il est conseillé. Selon les documents, vous pouvez envoyer une chaîne vide, même si je ne suis pas sûr de NULL. Il est conseillé pour des raisons de sécurité. Vous pouvez utiliser la charge utile pour vérifier que l'utilisateur a été effectué par l'utilisateur que vous avez destiné, par exemple. Voir la facturation Meilleures pratiques de sécurité
Ce que vous pensez de mon diagramme. Pour mes situations d'arbres, j'ai écrit ma pensée sur le côté droit. Est-ce vrai
Vous devez transmettre un jeton de chaîne qui aide votre application à identifier l'utilisateur qui a fait l'achat, de sorte que vous puissiez vérifier ultérieurement qu'il s'agit d'un achat légitime par cet utilisateur.
Pensez à cela comme un reçu. Si un client est entré et voulait renvoyer un article ou une garantie, vous voudrez être sûr que le reçu n'était pas imprimé à la maison. L'utilisation de ce jeton aidera à prévenir la fraude.
Oui, la merde la plus possible survient au scénario 2.
Mais combien d'utilisateurs sont sur scénario 2? Je pense que ce ne serait pas beaucoup. La plupart des gens ne partagent pas leurs appareils.
Mais je pense à une autre possibilité de fissure si cette chaîne de charge utile est vide. Il serait facile de le casser.
La seule chose qui me rend fou est que cette chose devrait être sur le côté de Google Api. Le travail de Google pour vérifier et s'assurer de qui a acheté l'article. Pourquoi nous avons besoin de notre propre serveur?
Je ne suis pas sûr de comprendre comment votre diagramme concerne la question. Pouvez-vous clarifier ce que la partie de diagramme demande?
Bien au diagramme, il y a 3 situations. Je demande que ce qui va se passer si l'usure achète un produit à ces trois situations. Tout d'abord, si l'usure a ouvert mon application dans un autre appareil avec le même compte. Deuxièmement, si un autre utilisateur utilise mon application dans le même périphérique avec un compte différent. Troisième tiers Y a-t-il une connexion entre chaque utilisateur
Je vois. Il y a peut-être deux notions d'utilisateur différentes. Il y a l'utilisateur de Google Play dont l'élément est associé à Google. Votre application pourrait avoir une notion distincte d'utilisateur. De qui parles-tu?
Situation 1: L'utilisateur n'a pas besoin d'acheter à nouveau, car les informations d'achat sont stockées sur le serveur.
Si vous souhaitez conserver le même comportement en utilisant la charge utile du développeur, vous auriez probablement besoin de stocker cette charge utile dans votre propre serveur.
Je devais supprimer cette vérification alors que je suis toujours null pour la charge utile dans mes tests. Google Play ne semble pas stocker la charge utile que j'envoie avec: inappbillinghelper.launchpurchaseflow (this, sku_sword, rc_request, mpurchasefinisheisener, charge utile);
Comment gérer la situation 1 dans l'affaire mentionnée ci-dessus?
@DAMNUM J'ai mis en œuvre une facturation inapprochée dans mon application avec une charge utile vierge. Ensuite, j'ai créé la situation 1, comme mentionné ci-dessus. J'ai acheté l'application dans le périphérique 1 avec Email ID ABC@XYZ.com et lorsque je vérifie un autre appareil 2 avec le même identifiant de messagerie, l'application demande à nouveau d'acheter à nouveau la fonction Premium.