Pokud pracujete s nákupy v aplikacích na Androidu, dříve či později se budete muset vypořádat s... Knihovna fakturace Google Play v7Není to jen další aktualizace: přináší změny API, nové funkce předplatného, požadavky konzole a velmi jasné termíny od Googlu. Ignorování této aktualizace již není možné, pokud chcete pokračovat v publikování nebo aktualizaci aplikace na Google Play bez jakýchkoli překvapení.
V celém tomto článku uvidíte, jak Aktualizace a implementace knihovny Google Play Billing Library v7 Krok za krokem: od rozdílů oproti PBL 5 a 6, přes integraci předplatného, jednorázových nákupů, RTDN, testování s Play Billing Lab až po přežití v ekosystémech, jako je .NET MAUI, kde oficiální podpora zaostává. Myšlenka je taková, že po dočtení si můžete s jistotou a bez utrácení koruny připravit migraci.
Přehled knihovny fakturace Google Play v7
Knihovna fakturace Google Play 7 přináší významná vylepšení ve způsobu správy faktur. Platby, předplatné a speciální tarifyJe však navržen tak, aby migrace byla relativně hladká. Dobrou zprávou je, že mnoho nových API je volitelných: můžete aktualizovat závislosti, upravit několik referencí a vaše základní integrace bude stále fungovat.
Tato verze se zaměřuje na tři klíčové oblasti: nové možnosti předplatného (například virtuální kvóty), lepší podpora pro čekající nákupy u předplacených tarifůa změny API, které opravují to, co již bylo v předchozích verzích (PBL 5 a 6) zastaralé. Google navíc upravuje některé způsoby ošetřování chyb a způsob, jakým byste měli zpracovávat čekající transakce, aby se předešlo nekonzistencím.
Pro začátek je třeba v modulu aplikace aktualizovat závislost v souboru build.gradle:
dependencies {
def billingVersion = "7.0.0"
implementation "com.android.billingclient:billing:$billingVersion"
}
Jakmile je to hotové, je čas zkontrolovat kód, který používá starší API. Mnoho volání souvisejících s poměrné rozdělení předplatného a alternativní fakturace Byly přejmenovány nebo odstraněny, takže je dobré si před kompilací a nahráním čehokoli do Play Console důkladně prohlédnout všechny odkazy na BillingClient a BillingFlowParams.
Strategie monetizace s jednorázovými nákupy a předplatným
Když prodáváte digitální produkty ve své aplikaci, nestačí jen vložit nákupní dialog a ukončit to: návrh bezproblémový uživatelský zážitek během celého nákupního cykluTo platí jak pro jednotlivé produkty (spotřebovatelné i nespotřebovatelné), tak pro předplatné. Čím přirozenější a bezproblémovější je proces, tím vyšší jsou konverze a nižší míra zrušení.
Typický proces nákupu s platformou Play Billing, ať už se jedná o předplatné nebo o jednotlivou položku, obvykle probíhá podle těchto jasně definovaných fází, kterých by si měl být vědom i vaše backendová platforma:
- Uživatel si prohlédne dostupné produkty a vybere si jeden.
- Aplikace zahájí proces fakturace Google Play pro dokončení platby.
- Nákup je dokončen a vaše aplikace obdrží výsledek.
- Váš server ověří nákup pomocí rozhraní Google Play Developer API.
- Uživateli je ve vašem systému udělen odpovídající obsah nebo právo.
- Google je informován, že nákup byl zpracován (uskutečněn nebo potvrzen).
V případě spotřebního zboží je nezbytné, aby spotřebujte token ve správný čas umožnit bezproblémové zpětné nákupy a pomoci Blokování nechtěných nákupů na Google PlayU předplatného musíte mít kontrolu nad obnovením, lhůtami, pozastavením a zrušením, aby uživatel dostal přesně to, za co zaplatil, a ani o den méně.
Integrace do aplikace je jen polovina úkolu: váš server musí udržovat spolehlivý záznam o právech a stavech nákupůTo je obzvláště důležité, pokud nabízíte přístup napříč platformami nebo potřebujete podrobné statistiky o tržbách, udržení zákazníků a odchodu zákazníků. Zde přicházejí na řadu oznámení pro vývojáře v reálném čase (RTDN), která fungují jako „černá skříňka“ životního cyklu nákupu.
S RTDN můžete reagovat téměř v reálném čase na kritické události: nový nákup, selhání obnovení, ukončení lhůty pro předplatné nebo zrušení nákupu. To vám umožňuje vyvíjet strategie pro obnovení odběratelů a prevence podvodů, například automatické odesílání e-mailů v případě neúspěšné platby nebo úpravy práv, pokud zákazník zprávu neobdrží kvůli problémům se sítí.
Oznámení pro vývojáře v reálném čase (RTDN) a Google Cloud Pub/Sub
Použití RTDN Google Cloud Pub/Sub jako systém pro zasílání zpráv v reálném čase mezi Google Play a vaším backendem. Google Play zveřejňuje události týkající se tématu Pub/Sub a vy se přihlásíte k odběru daného tématu, abyste dostávali zprávy vždy, když se stav nákupu nebo předplatného změní.
Základní postup je jednoduchý: Google Play odešle zprávu kódovanou v base64 do tématu Pub/Sub, váš odběratel ji extrahuje, dekóduje a zpracuje oznámení. V rámci pole data Ve zprávě najdete objekt JSON Oznámení pro vývojářecož zahrnuje informace, jako je verze zprávy, název balíčku, čas události a konkrétní údaje o jednorázových nákupech, předplatném, zrušených nákupech nebo zkušebních verzích.
{
"version": string,
"packageName": string,
"eventTimeMillis": long,
"oneTimeProductNotification": OneTimeProductNotification,
"subscriptionNotification": SubscriptionNotification,
"voidedPurchaseNotification": VoidedPurchaseNotification,
"testNotification": TestNotification
}
Díky těmto zprávám můžete Udržujte backend synchronizovaný i v případě selhání zařízení uživatelePředstavte si, že uživatel úspěšně provede nákup, Google Play ho potvrdí, ale mobilní zařízení ztratí připojení dříve, než vaše aplikace obdrží zpětné volání z fakturační knihovny. Bez RTDN se to možná nikdy nedozvíte. S Pub/Sub váš server obdrží samostatné oznámení a může udělit oprávnění nezávisle na klientovi.
Konfigurace Cloud Pub/Sub pro RTDN
Před aktivací RTDN v konzoli Google Play je třeba připravit projekt v Google Cloud Platform (GCP) a nakonfigurujte tam Pub/Sub. Postup je relativně jednoduchý, ale je nejlepší ho pečlivě dodržovat, abyste se vyhnuli překvapením s oprávněními nebo názvy zdrojů.
Vytvoření tématu
Nejprve musíte vytvořit Téma publikování/subversionu který bude sloužit jako váš publikační bod v Google Play. V konzoli Google Cloud vyberte svůj projekt, přejděte do sekce Pub/Sub a vytvořte nové téma podle oficiálního návodu „vytvořit téma“. Výsledek bude mít název v následujícím formátu:
projects/{project_id}/topics/{topic_name}
Toto celé jméno budete muset vložit do konzole Play Console při aktivaci oznámení.
Vytvoření předplatného
Pro čtení zpráv v tomto vlákně potřebujete Předplatné Pub/SubMůžete to nakonfigurovat jako tlačit nebo jako táhnoutV referenční kodové laboratoři pracujeme s pull subscription, kde váš backend iniciuje požadavky na načtení zpráv.
Měli byste si projít možnosti v průvodci pro odběratele Cloud Pub/Sub a rozhodnout se, zda je pro vaši architekturu vhodnější metoda push nebo pull. Jakmile se rozhodnete, postupujte podle dokumentace k „přidání odběru“ a propojte jej s tématem, které jste vytvořili dříve. Od tohoto okamžiku budou všechny zprávy, které Google Play v daném tématu publikuje, přístupné vašemu odběrateli.
Oprávnění pro publikování ve vašem motivu na Google Play
Pub/Sub neumožní Google Play publikovat cokoli, pokud k tomu nedáte výslovný souhlas. servisní účetV konzoli Google Cloud musíte přejít do nastavení oprávnění tématu a přidat hlavní:
[email protected]
Udělte tomuto účtu roli Vydavatel Pub/Sub (Vydavatel). Uložte změny a od té chvíle bude Google Play moci odesílat RTDN do vašeho motivu bez problémů s autorizací.
Aktivace RTDN v Google Play Console
Jakmile je nakonfigurováno Pub/Sub, je třeba sdělit službě Play Console, kam má odesílat oznámení. V aplikaci v Google Play Console přejděte na Zpeněžit s Play > Nastavení zpeněžení a vyhledejte sekci s oznámeními pro vývojáře v reálném čase.
Tam budete potřebovat:
- Zaškrtněte políčko pro povolení oznámení v reálném čase.
- Zadejte celý název tématu Pub/Sub do příslušného pole s ohledem na formát
projects/{project_id}/topics/{topic_name}. - Odešlete testovací zprávu pomocí testovacího tlačítka.
Testovací zpráva je nezbytná pro ověření, že Integrace je dobře implementována.Pokud máte pull subscription, můžete přejít do cloudové konzole, vybrat subscription, kliknout na „Zobrazit zprávy“ a extrahovat testovací zprávu. Nezapomeňte provést ack jakékoli zprávy, kterou si přečtete, abyste se vyhnuli opakovanému příjmu.
U push odběrů ověřte, zda váš koncový bod zprávu obdrží a odpoví platným kódem HTTP. Pokud se něco pokazí, konzole při publikování testu zobrazí chybu, obvykle související s názvem tématu nebo oprávněními servisního účtu.
Nakonec si můžete nakonfigurovat, jaké typy oznámení chcete dostávat: pouze předplatné a zrušené nákupy, nebo všechna oznámení včetně jednorázových nákupů (události jako ONE_TIME_PRODUCT_PURCHASED a ONE_TIME_PRODUCT_CANCELED). Pokud používáte také unikátní produkty, je běžnou praxí aktivovat celou sadu, aby byl zachován přehled o všem.
Vytvořte si odběratele Pub/Sub ve svém backendu
S připraveným tématem a předplatným je čas implementovat předplatitel, který čte a zpracovává RTDNGoogle poskytuje příklady v několika jazycích; typický případ v Javě využívá klientské knihovny Cloud Pub/Sub ke spuštění Subscriber kdo poslouchá zprávy a volá MessageReceiver.
Obecný vzorec je vždy stejný: načtete zprávu, dekódujete pole data Převedete base64 na text, analyzujete JSON a extrahujete relevantní pole (například packageName, oneTimeProductNotification o subscriptionNotification) a rozhodnout se, co se má ve vašem systému dělat. Po úspěšném zpracování oznámení musíte Potvrďte zprávu potvrzením aby to Pub/Sub znovu neposlal.
Ukázkový kód ukazuje, jak přijímač vypíše verzi a název balíčku, ale v reálné implementaci byste šli ještě dál: Ověřili byste nákup a udělili právo správnému uživateli.Aktualizovali byste databázi a v případě potřeby zavolali rozhraní Play Developer API pro zpracování nebo rozpoznání nákupu.
Propojení oznámení s uživatelem: použití obfuscatedAccountId
Častým problémem při správě nákupů ze serveru je zjištění, kterému uživateli patří konkrétní oznámení RTDN. Pro tento účel umožňuje rozhraní Billing Client API připojit zmatený identifikátor účtu když spustíte proces nákupu: obfuscatedAccountId.
Myšlenka je, že použijete stabilní identifikátor z vašeho systému (například interní ID uživatele), ale zatemněno z důvodů soukromí a bezpečnostiTato hodnota je přidružena k nákupu a poté se zobrazí v informacích vrácených z rozhraní Google Play Developer API, takže po obdržení RTDN a ověření tokenu budete jednoznačně vědět, kterému účtu ve vaší databázi máte oprávnění udělit.
Na straně zákazníka, při přípravě BillingFlowParamsStačí si jen sestavit seznam ProductDetailsParams a zavolat setObfuscatedAccountId(obfuscatedAccountId) před spuštěním toku. To nemění vizuální uživatelský zážitek, ale výrazně to zjednodušuje proces. logika alokace nákupů na backendu a pomáhá Googlu odhalovat podvody.
Ověřování nákupů pomocí rozhraní Google Play Developer API
Před udělením jakýchkoli práv k vašemu serveru je nutné ověřit legitimnost nákupu zavoláním na API pro vývojáře Google PlayNestačí se spoléhat na to, co říká klient nebo dokonce RTDN: musíte ověřit... purchaseToken přímo proti oficiálním koncovým bodům a v případě potřeby spravovat vrácení peněz.
V případě unikátních produktů použijete koncový bod purchases.products:getU předplatného vede cesta přes purchases.subscriptionsv2:getDoporučený tok je:
- Extrahujte
purchaseTokenze zprávy Pub/Sub. - Zkontrolujte si databázi, zda jste ji již zpracovali; každý token je globálně unikátníJe tedy perfektní jako primární klíč, aby se zabránilo duplikátům.
- Pokud je nový, zavolejte rozhraní Google Play Developer API s balíčkem, SKU a
purchaseToken. - Ověřte, zda odpověď uvádí stav nákupu. ZAKOUPENO (není ČEKAJÍCÍ ani zrušené).
- Pokud vše souhlasí, zaregistrujte token a udělte odpovídající oprávnění přidruženému uživateli.
Pro komunikaci s rozhraním Play Developer API z Javy můžete použít AndroidPublisher, inicializovaný s přihlašovacími údaji servisního účtu ve formátu JSON. Konfigurujete rozsah AndroidPublisherScopes.ANDROIDPUBLISHERVytvoříte klienta a zavoláte metodu purchases().products().get(...)Pokud se hovor nezdaří kvůli dočasnému problému se sítí nebo službou, doporučuje se implementovat opakované pokusy s exponenciálním odkladem abych o akci nepřišel/nepropásla.
Potvrďte nebo dokončete nákup ze serveru
Jakmile ověříte nákup a udělíte autorizaci ve vašem systému, dalším krokem je informovat Google o úspěšném zpracování transakce. U produktů s jednou položkou máte dvě možnosti: spotřebovat nákup nebo jednoduše poznat ji.
Spotřební zboží (např. virtuální měna, životy atd.) musí projít koncovým bodem. purchases.products:consumeTím se token označí jako použitý a uživateli se umožní bez konfliktu znovu zakoupit stejnou položku. U produktů, které nelze spotřebovat (například pro odemčení prémiové verze na celý život), je nutné zavolat purchases.products:acknowledge, což informuje Google, že uživatel již má příslušné právo.
Předplatné se používá purchases.subscriptions:acknowledgecož znamená, že předplatné bylo úspěšně zpracováno a přiřazeno uživateli. Pokud nákup nepotvrdíte v přiměřené lhůtě, Google může předpokládat, že došlo k problému, a transakci zrušit, proto je důležité, abyste zpět se provede ihned po udělení práva.
V pomocném modulu AndroidPublisher můžete přidat metody jako executeProductPurchasesConsume y executeProductPurchasesAcknowledge které volají odpovídající koncové body. Opět je vhodné implementovat opakované pokusy v případě občasných selhání, aby se zajistilo, že žádný token nezůstane v nebezpečném přechodném stavu.
Pokročilé testování s laboratoří Play Billing Lab
Jedním z aspektů, které mnoho vývojářů podceňuje, je fáze testování. Abyste mohli spustit systém s jakoukoli mírou jistoty, musíte být schopni simulovat síťové chyby, nestandardní odpovědi a okrajové případyA právě zde přichází na řadu Play Billing Lab, bezplatná aplikace na Google Play navržená speciálně pro testování integrací Play Billing Library.
Laboratoř fakturace Play zahrnuje simulátor odpovědí což umožňuje vynucovat různé BillingResponseCode ve voláních fakturační knihovny vaší aplikace. Tímto způsobem můžete znovu vytvořit scénáře, kdy například zákazník nemůže dokončit nákup kvůli problému se sítí, ale váš backend správně zpracuje RTDN a nakonec udělí nárok bez zásahu uživatele.
Aby vaše aplikace mohla komunikovat se simulátorem, je nutné povolit testování „přepsání fakturace“ pomocí metadat v AndroidManifest.xml:
<manifest ... >
<application ... >
...
<meta-data
android:name="com.google.android.play.largest_release_audience.NONPRODUCTION"
android:value="" />
<meta-data
android:name="com.google.android.play.billingclient.enableBillingOverridesTesting"
android:value="true" />
</application>
</manifest>
Štítek enableBillingOverridesTesting Aktivujte simulované testy odpovědí v knihovně fakturace. Značka NONPRODUCTION je jakousi připomínkou, že tato sestava by neměla jít do produkčního prostředí s aktivními přepsáními. Při přípravě finální verze pro uživatele se ujistěte, že Odstraňte tato metadata nebo použijte samostatný manifest.
Po konfiguraci se v aplikaci Play Billing Lab přihlaste pomocí účtu testera licencí, aktivujte možnost „Simulovat odpověď knihovny Play Billing“ a vyberte, které chybové kódy chcete pro každé rozhraní API vrátit (například konkrétní chybu v consumeAsyncPak jednoduše otevřete aplikaci a spusťte tok, který chcete otestovat: simulátor vrátí nakonfigurované odpovědi a vy můžete ověřit, zda se logika opakování, zpracování chyb a RTDN chovají podle očekávání.
Klíčové změny API při migraci na Play Billing Library 7
Kromě RTDN a testování zahrnuje migrace na PBL 7 řešení některých specifických bodů API. Pro ty, kteří přecházejí z PBL 5 nebo 6, je vhodné zkontrolovat nejrelevantnější změny, aby se zajistila hladká kompilace projektu a konzistence obchodní logiky.
Zaprvé, API související s ProrationMode Možnosti změny předplatného byly odstraněny. Nyní se používá následující: ReplacementMode pro správu změn tarifu (upgrady, downgrady atd.). Pokud stále používáte metody jako setReplaceProrationMode o setReplaceSkusProrationModeBudete je muset migrovat do nových variant setSubscriptionReplacementMode a upravte logiku dle aktualizované dokumentace.
API bylo také odstraněno launchPriceConfirmationFlowkterý již byl označen jako zastaralý. Chcete-li zvládnout změny cen předplatného, měli byste se řídit novými pracovními postupy a doporučeními v průvodci změnou cen, který podrobně popisuje, jak správně informovat uživatele a jak spravovat souhlas.
Dalším důležitým bodem je Alternativní fakturační APIMetody BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails zmizely ve prospěch sjednocenější nomenklatury: nyní musíte použít BillingClient.Builder.enableUserChoiceBilling() vedle UserChoiceBillingListener y UserChoiceDetailsPodle samotného Googlu se v podstatě jedná o změnu názvu bez změn v chování, a to v kontextu poznamenaném dohodami, jako je Google a Epic Games se dohodly na otevření Androidu.
Nakonec se zadá nový chybový kód. CHYBA_SÍTĚ en BillingResulta významy a podmínky SERVICE_TIMEOUT a SERVICE_NEDOSTUPNÁPokud máte vlastní logiku pro ošetřování chyb (například rozhodování o tom, kdy zobrazit uživateli zprávu, kdy provést tichý opakování atd.), je vhodné ji zkontrolovat a zohlednit tyto nové nuance.
Nevyřízené transakce a absence ID objednávky do doby, než bude provedeno ZAKOUPENÍ
Drobnou změnou v PBL 7 je, že knihovna již negeneruje ID objednávky pro čekající nákupy. V těchto případech je orderId Bude k dispozici až poté, co nákup dosáhne stavu ZAKOUPENO. To se týká zejména pracovních postupů, kde jste od začátku používali ID objednávky jako primární referenci.
Doporučení Googlu je, abyste se spoléhali na purchaseToken pro vaše záznamy a odsouhlaseníalespoň dokud je transakce vyřízena. Pokud najdete nákup, který zmizel z Play, zkontrolujte Co dělat, když nákup zmizí.
Pokud jste dosud nepracovali s neuhrazenými zůstatky, prostudujte si průvodce integrací Billing Library a dokumentaci k řízení životního cyklu zadávání veřejných zakázekNajdete tam různé stavy, jak na každý z nich reagovat a jak do této skládačky zapadají RTDN.
Nové volitelné funkce v PBL 7: virtuální splátky a předplacení
Mezi „příjemné“ nové funkce PBL 7 patří virtuální předplatné (virtuální splátkové předplatné) a rozšířená podpora pro čekající nákupy u předplacených předplatných. Tyto funkce nejsou povinné, ale mohou vám poskytnout větší flexibilitu při přizpůsobování vašeho obchodního modelu různým trhům.
Virtuální splátky umožňují uživateli platit za dlouhodobější předplatné v malé pravidelné platbyGoogle vysvětluje, že místo jednorázové velké platby pro účely fakturace vývojářů nadále dostáváte měsíční platby v rámci ročního tarifu s měsíčními splátkami. Pokud uživatel platbu zmešká, neměli byste se ani vy, ani Google pokoušet o vymáhání minulých splátek. Díky tomu je jeho praktické využití poměrně podobné standardnímu měsíčnímu předplatnému, alespoň zpočátku.
Prozatím jsou tyto poplatky za předplatné k dispozici pouze v Brazílie, Francie, Itálie a ŠpanělskoGoogle doporučuje sledovat Play Console v nově podporovaných zemích. Konfigurace se provádí prostřednictvím ProductDetails.InstallmentPlanDetails a podle konkrétního návodu je integrujte do své aplikace.
Souběžně se rozšiřuje podpora čekající nákupy předplacených předplatnýchNyní můžete nabídnout modely, kde uživatel zahájí nákup v aplikaci a platbu dokončí později jinými prostředky, a fakturační knihovna ví, jak tento proces správně zpracovat. Aktivace se provádí voláním. enablePendingPurchases() při inicializaci BillingClient a, konkrétně u předplacených tarifů, při použití PendingPurchasesParams.Builder.enablePrepaidPlans().
Období odpisování pro knihovnu fakturace Play 5 a 6
Vzhledem k tomu, že se chystá PBL 7, Google stanovil jasná data pro... ukončení podpory pro verze 5 a 6Pokud se v některém z nich stále nacházíte, musíte si v kalendáři označit červeně:
- Knihovna Google Play Billing Library 5 bude oficiálně ukončena 31. srpna 2024 pro nové aplikace a aktualizace. Je možné požádat o prodloužení do 1. listopadu 2024, ale na to byste se neměli dlouhodobě spoléhat.
- Knihovnu Google Play Billing Library 6 lze používat k publikování nových aplikací do 1. srpna 2025 a k aktualizaci stávajících aplikací do 1. listopadu 2025.
Po tomto datu, pokud jste nemigrovali alespoň na verzi 6 nebo ideálně na verzi 7, budete muset aktualizovat na nejnovější verzi. Verze 7V konzoli Play Console budou vaše aktualizace zablokovány. I když vaše aplikace bude i nadále fungovat na zařízeních uživatelů, budete zamrznuti a nebudete moci opravovat chyby ani přidávat nové funkce, které závisí na publikování v obchodě.
Případ .NET MAUI a současná omezení
Pokud pracujete s .NET MAUI a předplatným na Androidu, pravděpodobně jste si již přečetli nebo zažili, že to není tak jednoduché. Mnoho projektů používalo Plugin.InAppBilling od Jamese Montemagna, ale plugin je archivovaný a neudržovaný, takže nebude aktualizován pro podporu Billing Library 7. Zároveň oficiální balíček Xamarin.Android.Google.BillingClient Zůstal ukotvený v ekosystému Xamarin.Android a není přímo kompatibilní s .NET MAUI.
Praktickým důsledkem je, že Varování Play Console Vaše aplikace nepoužívá Billing Library 7.0.0 nebo vyšší, což blokuje aktualizace, pokud budete i nadále používat starší knihovny. Někteří vývojáři se rozhodli pro drastická řešení, jako je dočasné zakázání předplatného, aby bylo možné nahrát verzi, ale to samozřejmě není udržitelné, pokud váš obchodní model závisí na této monetizaci.
V této souvislosti mnoho týmů zvažuje alternativy, jako například Sady SDK třetích stran Tyto služby již podporují PBL 7 a poskytují stabilnější, multiplatformní API (například backendová řešení pro předplatné s SDK pro Android, iOS a další platformy). Tyto služby obvykle zvládají migrace verzí fakturační knihovny a poskytují stabilní obalový modul, což výrazně snižuje zátěž s každým novým ukončením podpory od Googlu.
Dokud Microsoft a tým MAUI nenabídnou Oficiální balíček aktualizovaný a plně kompatibilní S Billing Library 7 máte k dispozici tyto možnosti: implementaci vlastní vazby na nativní Billing Library, použití služby třetí strany nebo přehodnocení způsobu integrace nákupů v rámci vašeho projektu MAUI. V každém případě je nejlepší nenechávat rozhodnutí na poslední chvíli, protože termíny v Play jsou pevně dané.
Celkově vzato, aktualizace Google Play Billing Library v7 zahrnuje kontrolu závislostí, vyčištění zastaralých API, posílení logiky backendu s ověřováním nákupů a RTDN a využití testovacích nástrojů, jako je Play Billing Lab, k odhalení všech chyb před spuštěním. Ti, kteří si udělají čas na doladění této migrace, budou lépe schopni zvládat předplacené tarify, virtuální poplatky, síťové chyby a změny životního cyklu předplatného a budou mít mnohem větší šanci udržet si stabilní příjmy a propracovaný uživatelský zážitek na Google Play. Sdílejte informace, aby se o daném tématu dozvědělo více uživatelů.