Dacă lucrați cu achiziții în aplicație pe Android, mai devreme sau mai târziu va trebui să vă confruntați cu Biblioteca de facturare Google Play versiunea 7Nu este doar o altă actualizare: vine cu modificări ale API-ului, noi funcții pentru abonamente, cerințe pentru consolă și termene limită foarte clare din partea Google. Ignorarea acesteia nu mai este o opțiune dacă doriți să continuați să publicați sau să actualizați aplicația pe Google Play fără surprize.
Pe parcursul acestui articol veți vedea cum Actualizați și implementați Biblioteca de facturare Google Play v7 Pas cu pas: de la ce este diferit față de PBL 5 și 6, la cum să integrezi abonamente, achiziții unice, RTDN, testarea cu Play Billing Lab și cum să supraviețuiești în ecosisteme precum .NET MAUI, unde suportul oficial este în urmă. Ideea este că, atunci când termini de citit, poți pregăti migrarea cu încredere și fără a cheltui niciun ban.
Prezentare generală a Bibliotecii de facturare Google Play v7
Biblioteca de facturare Google Play 7 introduce îmbunătățiri semnificative în modul în care sunt gestionate facturile Plăți, abonamente și planuri specialeTotuși, este conceput pentru a face migrarea relativ lină. Vestea bună este că multe dintre noile API-uri sunt opționale: puteți actualiza dependența, puteți modifica câteva referințe și integrarea de bază va funcționa în continuare.
Această versiune se concentrează pe trei domenii cheie: noi opțiuni de abonament (cum ar fi cotele virtuale), un suport mai bun pentru achiziții în așteptare pentru abonamente preplătiteși modificări ale API-ului care elimină ceea ce era deja învechit în versiunile anterioare (PBL 5 și 6). În plus, Google ajustează unele aspecte legate de gestionarea erorilor și modul în care ar trebui să gestionați tranzacțiile în așteptare pentru a evita inconsecvențele.
Pentru început, în modulul aplicației trebuie să actualizați dependența din fișierul dvs. construi.gradle:
dependencies {
def billingVersion = "7.0.0"
implementation "com.android.billingclient:billing:$billingVersion"
}
După ce acest lucru este făcut, este timpul să revizuim codul care utilizează API-uri vechi. Multe apeluri legate de proporționalitatea abonamentului și facturarea alternativă Acestea au fost redenumite sau eliminate, așa că este o idee bună să analizați cu atenție toate referințele la BillingClient și BillingFlowParams înainte de a compila și încărca ceva în Play Console.
Strategii de monetizare cu achiziții unice și abonamente
Când vinzi produse digitale în aplicație, simpla lipire a dialogului de achiziție și încheierea activității nu este suficientă: proiectarea unui experiență utilizator fără probleme pe tot parcursul ciclului de cumpărareAcest lucru se aplică atât produselor individuale (consumabile sau neconsumabile), cât și abonamentelor. Cu cât procesul este mai natural și mai fluid, cu atât conversiile sunt mai mari și rata de anulare este mai mică.
Un flux tipic de achiziții cu Play Billing, fie pentru un abonament, fie pentru un singur articol, urmează de obicei aceste etape bine definite, de care backend-ul ar trebui să fie conștient:
- Utilizatorul explorează produsele disponibile și selectează unul.
- Aplicația inițiază procesul de facturare Google Play pentru a finaliza plata.
- Achiziția este finalizată și aplicația dvs. primește rezultatul.
- Serverul dvs. validează achiziția în funcție de API-ul pentru dezvoltatori Google Play.
- Conținutul sau dreptul corespunzător este acordat utilizatorului în sistemul dumneavoastră.
- Google este informat că achiziția a fost procesată (consumată sau confirmată).
În cazul produselor consumabile, este esențial ca consumă tokenul la momentul potrivit pentru a permite răscumpărări fără probleme și a ajuta Blocați achizițiile accidentale pe Google PlayÎn abonamente, trebuie să controlați reînnoirile, perioadele de grație, suspendările și anulările, astfel încât utilizatorul să primească exact ceea ce a plătit și nici cu o zi mai puțin.
Integrarea în aplicație este doar jumătate din sarcină: serverul tău trebuie să mențină un o evidență fiabilă a drepturilor și a stării achizițiilorAcest lucru este important mai ales dacă oferiți acces multi-platformă sau aveți nevoie de statistici detaliate privind veniturile, retenția și rata de abandon. Aici intervin notificările pentru dezvoltatori în timp real (RTDN), care acționează ca „cutia neagră” a ciclului de viață al achiziției.
Cu RTDN puteți reacționa aproape în timp real la evenimente critice: o achiziție nouă, o reînnoire nereușită, un abonament care intră în perioada de grație sau o achiziție anulată. Acest lucru vă permite să dezvoltați strategii pentru recuperarea abonaților și prevenirea fraudei, cum ar fi trimiterea automată de e-mailuri atunci când o plată eșuează sau ajustările drepturilor dacă clientul nu primește mesajul din cauza unor probleme de rețea.
Notificări pentru dezvoltatori în timp real (RTDN) și Google Cloud Pub/Sub
Utilizarea RTDN-urilor Google Cloud Pub/Sub ca sistem de mesagerie în timp real între Google Play și backend-ul dvs. Google Play publică evenimente despre un subiect Pub/Sub, iar dvs. vă abonați la subiectul respectiv pentru a primi mesaje de fiecare dată când se modifică starea unei achiziții sau a unui abonament.
Fluxul de bază este simplu: Google Play trimite un mesaj codificat în base64 către subiectul Pub/Sub, abonatul îl extrage, îl decodează și procesează notificarea. În câmpul data În mesaj veți găsi un obiect JSON Notificare pentru dezvoltatoricare include informații precum versiunea mesajului, numele pachetului, ora evenimentului și date specifice despre achiziții unice, abonamente, achiziții anulate sau perioade de probă.
{
"version": string,
"packageName": string,
"eventTimeMillis": long,
"oneTimeProductNotification": OneTimeProductNotification,
"subscriptionNotification": SubscriptionNotification,
"voidedPurchaseNotification": VoidedPurchaseNotification,
"testNotification": TestNotification
}
Datorită acestor mesaje poți Mențineți backend-ul sincronizat chiar dacă dispozitivul utilizatorului se defecteazăImaginați-vă că un utilizator efectuează cu succes o achiziție, Google Play o confirmă, dar dispozitivul mobil pierde conexiunea înainte ca aplicația dvs. să primească apelul invers de la Biblioteca de Facturare. Fără RTDN, s-ar putea să nu știți niciodată. Cu Pub/Sub, serverul dvs. primește o notificare separată și poate acorda dreptul independent de client.
Configurarea Cloud Pub/Sub pentru RTDN
Înainte de a activa RTDN în consola Google Play, trebuie să pregătiți un proiect în Platforma Google Cloud (GCP) și configurați Pub/Sub acolo. Procesul este relativ simplu, dar cel mai bine este să îl urmați cu atenție pentru a evita surprize legate de permisiuni sau nume de resurse.
Crearea subiectului
Mai întâi trebuie să creați un Subiect Publicare/Subscriere care va acționa ca punct de publicare pe Google Play. Din consola Google Cloud, selectați proiectul, accesați secțiunea Pub/Sub și creați un subiect nou urmând ghidul oficial „creați un subiect”. Rezultatul va avea un nume în formatul următor:
projects/{project_id}/topics/{topic_name}
Numele complet este cel pe care va trebui să îl inserați în Play Console atunci când activați notificările.
Crearea abonamentului
Pentru a citi mesajele din acest fir de discuție, aveți nevoie de un Abonament Pub/SubÎl poți configura ca împinge sau trageÎn laboratorul de codare de referință, lucrăm cu abonament de tip pull, unde backend-ul inițiază cererile de preluare a mesajelor.
Ar trebui să examinezi opțiunile din ghidul abonatului Cloud Pub/Sub pentru a decide dacă opțiunea de tip „push” sau „pull” este mai potrivită pentru arhitectura ta. După ce te-ai hotărât, urmează documentația „adăugați abonament” și conectează-l la subiectul pe care l-ai creat anterior. Din acel moment, orice mesaje pe care Google Play le publică în subiect vor fi accesibile abonatului tău.
Permisiuni pentru ca Google Play să publice în tema dvs.
Pub/Sub nu va permite Google Play să publice nimic decât dacă îi acordați permisiunea explicită. cont de serviciuÎn consola Google Cloud, trebuie să accesezi setările permisiunilor pentru subiecte și să adaugi permisiunea principală:
google-play-developer-notifications@system.gserviceaccount.com
Acordă acestui cont rolul de Editor Pub/Sub (Editor). Salvați modificările și, din acel moment, Google Play va putea trimite RTDN-uri către tema dvs. fără probleme de autorizare.
Activează RTDN în Google Play Console
După ce Pub/Sub este configurat, trebuie să indicați Play Console unde să trimită notificările. În aplicația dvs. din Google Play Console, accesați Monetizează cu Play > Setări de monetizare și localizați secțiunea de notificări pentru dezvoltatori în timp real.
Acolo va trebui să:
- Bifați caseta pentru a activa notificările în timp real.
- Introduceți numele complet al subiectului Pub/Sub în câmpul corespunzător, respectând formatul.
projects/{project_id}/topics/{topic_name}. - Trimiteți un mesaj de test folosind butonul de test.
Mesajul de test este esențial pentru a verifica dacă Integrarea este bine implementată.Dacă aveți un abonament de tip „pull”, puteți accesa consola Cloud, selecta abonamentul, da clic pe „Vizualizați mesajele” și extrage mesajul de test. Nu uitați să faceți acest lucru. ACK a oricărui mesaj pe care îl citiți pentru a evita recepționarea repetată.
Pentru abonamentele push, verificați dacă endpoint-ul primește mesajul și răspunde cu un cod HTTP valid. Dacă ceva nu merge bine, consola va afișa o eroare la publicarea testului, de obicei legată de numele subiectului sau de permisiunile contului de serviciu.
În cele din urmă, puteți configura ce tipuri de notificări doriți să primiți: doar abonamente și achiziții anulate sau toate notificările, inclusiv achizițiile unice (evenimente precum ONE_TIME_PRODUCT_PURCHASED și ONE_TIME_PRODUCT_CANCELED). Dacă utilizați și produse unice, este o practică obișnuită să activați întregul set pentru a menține vizibilitatea asupra tuturor elementelor.
Creează un abonament Pub/Sub în backend-ul tău
Cu tema și abonamentul gata, este timpul să implementăm o abonat care citește și procesează RTDN-uriGoogle oferă exemple în mai multe limbaje; un caz tipic în Java folosește bibliotecile client Cloud Pub/Sub pentru a porni un Subscriber care ascultă mesajele și sună MessageReceiver.
Modelul general este întotdeauna același: recuperezi mesajul, decodezi câmpul data Convertiți codul base64 în text, analizați JSON-ul și extrageți câmpurile relevante (cum ar fi packageName, oneTimeProductNotification o subscriptionNotification) și decideți ce să faceți în sistemul dvs. După procesarea cu succes a notificării, trebuie Confirmați mesajul cu un confirm astfel încât Pub/Sub să nu-l mai trimită.
Codul exemplu arată cum receptorul afișează versiunea și numele pachetului, dar într-o implementare reală ar trebui să mergeți mai departe: Ai valida achiziția, acordând dreptul utilizatorului corectAi actualiza baza de date și, dacă este necesar, ai apela API-ul Play Developer pentru a consuma sau a recunoaște achiziția.
Legarea notificărilor către utilizator: utilizarea obfuscatedAccountId
O problemă frecventă atunci când se gestionează achizițiile de pe server este cunoașterea utilizatorului căruia îi aparține o anumită notificare RTDN. Pentru aceasta, API-ul Billing Client vă permite să atașați un identificator de cont ofuscat când lansați fluxul de achiziție: obfuscatedAccountId.
Ideea este să folosești un identificator stabil din sistemul tău (de exemplu, ID-ul intern al utilizatorului), dar ofuscat din motive de confidențialitate și securitateAceastă valoare este asociată cu achiziția și apoi apare în informațiile returnate de API-ul pentru dezvoltatori Google Play, astfel încât, atunci când primiți RTDN-ul și verificați token-ul, veți ști fără echivoc cărui cont din baza de date ar trebui să îi acordați dreptul.
Din partea clientului, la pregătirea BillingFlowParamsTrebuie doar să construiești lista de ProductDetailsParams și sună setObfuscatedAccountId(obfuscatedAccountId) înainte de lansarea fluxului. Acest lucru nu schimbă experiența vizibilă a utilizatorului, dar simplifică considerabil procesul. logica de alocare a achizițiilor backend și ajută Google să detecteze fraudele.
Verificați achizițiile folosind API-ul pentru dezvoltatori Google Play
Înainte de a acorda orice drepturi asupra serverului dvs., este obligatoriu să verificați dacă achiziția este legitimă apelând la API-ul pentru dezvoltatori Google PlayNu este suficient să te bazezi pe ceea ce spune clientul sau chiar RTDN: trebuie să validezi purchaseToken direct față de punctele finale oficiale și, dacă este necesar gestionează rambursările.
În cazul produselor unice, veți utiliza endpoint-ul purchases.products:getPentru abonamente, calea trece prin purchases.subscriptionsv2:getDebitul recomandat este:
- Extrageți
purchaseTokendin mesajul Pub/Sub. - Verificați baza de date pentru a vedea dacă ați procesat-o deja; fiecare token este unic la nivel globalDeci este perfectă ca cheie primară pentru a evita duplicatele.
- Dacă este nou, apelați API-ul pentru dezvoltatori Google Play cu pachetul, SKU-ul și
purchaseToken. - Verificați dacă răspunsul indică o stare de achiziție CUMPARAT (nu este ÎN AȘTEPTARE sau anulat).
- Dacă totul se potrivește, înregistrați token-ul și acordați dreptul corespunzător utilizatorului asociat.
Pentru a comunica cu Play Developer API din Java, puteți utiliza AndroidPublisher, inițializat cu acreditările contului de serviciu în format JSON. Configurați domeniul de aplicare AndroidPublisherScopes.ANDROIDPUBLISHERConstruiești clientul și apelezi metoda purchases().products().get(...)Dacă apelul eșuează din cauza unei probleme temporare de rețea sau de serviciu, se recomandă implementați reîncercări cu backoff exponențial ca să nu rateze evenimentul.
Confirmați sau finalizați achiziția de pe server
După ce ați verificat achiziția și ați acordat autorizația în sistemul dvs., următorul pas este să notificați Google că tranzacția a fost procesată cu succes. Pentru produsele care conțin un singur articol, aveți două opțiuni: consumă achiziția sau pur și simplu recunoaște-o.
Produsele consumabile (de exemplu, monedă virtuală, vieți etc.) trebuie să treacă prin endpoint purchases.products:consumeAceasta marchează tokenul ca fiind utilizat și permite utilizatorului să răscumpere același articol fără conflicte. Pentru produsele neconsumabile (cum ar fi deblocarea versiunii premium pe viață), trebuie să apelați purchases.products:acknowledge, care informează Google că utilizatorul are deja dreptul asociat.
Abonamentele sunt folosite purchases.subscriptions:acknowledgeindicând faptul că abonamentul a fost procesat cu succes și atribuit utilizatorului. Dacă nu confirmați o achiziție într-un interval de timp rezonabil, Google poate presupune că există o problemă și anula tranzacția, așa că este important să înapoi se face imediat după acordarea dreptului.
În instrumentul de asistență AndroidPublisher puteți adăuga metode precum executeProductPurchasesConsume y executeProductPurchasesAcknowledge care apelează punctele finale corespunzătoare. Din nou, este recomandabil să se implementeze reîncercări în cazul unor eșecuri ocazionale, pentru a se asigura că niciun token nu rămâne într-o stare intermediară periculoasă.
Testare avansată cu Play Billing Lab
Un aspect pe care mulți dezvoltatori îl subestimează este faza de testare. Pentru a lansa cu un anumit grad de încredere, trebuie să puteți simula erori de rețea, răspunsuri nestandard și cazuri limităAici intervine Play Billing Lab, o aplicație gratuită de pe Google Play concepută special pentru testarea integrărilor cu Play Billing Library.
Laboratorul de facturare Play include un simulator de răspunsuri ceea ce permite forțarea diferitelor BillingResponseCode în apelurile aplicației dvs. către Biblioteca de facturare. În acest fel, puteți recrea scenarii în care, de exemplu, clientul nu poate finaliza achiziția din cauza unei probleme de rețea, dar backend-ul dvs. procesează corect RTDN-ul și, în cele din urmă, acordă dreptul fără intervenția utilizatorului.
Pentru ca aplicația dvs. să comunice cu simulatorul, trebuie să activați testarea „modificărilor facturării” folosind metadatele din 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>
Eticheta activați testarea suprasolicitărilor de facturare Activați testele de răspuns simulat ale Bibliotecii de Facturare. Eticheta NONPRODUCTION servește ca o reamintire că această versiune nu ar trebui implementată în producție cu suprascrierile active. Când pregătiți versiunea finală pentru utilizatori, asigurați-vă că Eliminați aceste metadate sau utilizați un manifest separat.
După configurare, din aplicația Play Billing Lab, conectați-vă cu un cont de tester de licențe, activați opțiunea „Simulați răspunsul din Biblioteca de facturare Play” și selectați codurile de eroare pe care doriți să le returnați pentru fiecare API (de exemplu, o eroare specifică în consumeAsyncApoi, pur și simplu deschideți aplicația și rulați fluxul pe care doriți să îl testați: simulatorul va returna răspunsurile configurate și puteți verifica dacă logica de reîncercare, gestionarea erorilor și RTDN se comportă conform așteptărilor.
Modificări cheie ale API-ului la migrarea către Play Billing Library 7
Dincolo de RTDN și testare, migrarea la PBL 7 implică abordarea unor puncte specifice API. Pentru cei care vin de la PBL 5 sau 6, merită să revizuiască cele mai relevante modificări pentru a se asigura că proiectul se compilează fără probleme și că logica de business rămâne consistentă.
În primul rând, API-urile legate de Mod de proporționalitate Opțiunile de modificare a abonamentului au fost eliminate. Acum se utilizează următoarele: Mod de înlocuire pentru a gestiona modificările planului (upgrade-uri, downgrade-uri etc.). Dacă încă utilizați metode precum setReplaceProrationMode o setReplaceSkusProrationModeVa trebui să le migrați către noile variante de setSubscriptionReplacementMode și ajustați logica conform documentației actualizate.
API-ul a fost, de asemenea, eliminat launchPriceConfirmationFlowcare era deja marcat ca învechit. Pentru a gestiona modificările prețurilor abonamentului, trebuie să consultați noile fluxuri de lucru și recomandări din ghidul de modificare a prețurilor, care detaliază cum să informați corect utilizatorul și cum să gestionați consimțământul.
Un alt punct important este API-uri alternative de facturareMetodele BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails au dispărut în favoarea unei nomenclaturi mai aliniate: acum trebuie să folosiți BillingClient.Builder.enableUserChoiceBilling() pe lângă UserChoiceBillingListener y UserChoiceDetailsPotrivit Google însuși, este practic o schimbare de nume fără modificări de comportament, într-un context marcat de acorduri precum Google și Epic Games au căzut de acord să lanseze Android.
În final, se introduce un nou cod de eroare. EROARE_REȚEA en BillingResultși semnificațiile și condițiile SERVICE_TIMEOUT și SERVICE_UNAVAILABLEDacă aveți o logică personalizată de gestionare a erorilor (de exemplu, pentru a decide când să se afișeze un mesaj utilizatorului, când să se reîncerce în mod silențios etc.), este recomandabil să o revizuiți pentru a lua în considerare aceste noi nuanțe.
Tranzacții în așteptare și absența ID-ului comenzii până la ACHIZIȚIE
O modificare subtilă în PBL 7 este că biblioteca nu mai generează un ID comandă pentru achizițiile în așteptare. În aceste cazuri, orderId Va fi disponibil doar după ce achiziția ajunge la starea ACHIZIȚIONATĂ. Acest lucru afectează în special fluxurile de lucru în care ați folosit ID-ul comenzii ca referință principală de la început.
Recomandarea Google este să vă bazați pe purchaseToken pentru înregistrările și reconcilierile dvs.cel puțin cât timp tranzacția este în așteptare. Dacă găsiți o achiziție care a dispărut din Play, verificați Ce trebuie făcut dacă achiziția dispare.
Dacă nu ați lucrat încă cu solduri restante, consultați ghidul și documentația de integrare a Bibliotecii de Facturare pe managementul ciclului de viață al achizițiilorAcolo veți găsi diferitele stări, cum să reacționați la fiecare dintre ele și cum se încadrează RTDN-urile în acest puzzle.
Noi funcționalități opționale în PBL 7: rate virtuale și plăți anticipate
Printre noile caracteristici „frumoase” ale PBL 7 se numără abonamente virtuale cu taxă (abonamente virtuale în rate) și asistență extinsă pentru achizițiile în așteptare pentru abonamentele preplătite. Aceste funcții nu sunt obligatorii, dar vă pot oferi mai multă flexibilitate atunci când vă adaptați modelul de afaceri la diferite piețe.
Ratele virtuale permit unui utilizator să plătească pentru un abonament pe termen lung în plăți periodice miciÎn loc de o singură plată mare, Google explică faptul că, în scopul facturării dezvoltatorilor, veți continua să primiți plăți lunare în cadrul unui plan anual cu rate lunare. Dacă un utilizator nu efectuează o plată, nici dumneavoastră, nici Google nu ar trebui să încercați să recuperați ratele anterioare. Acest lucru face ca utilizarea sa practică să fie destul de similară cu un abonament lunar standard, cel puțin inițial.
Deocamdată, aceste taxe de abonament sunt disponibile doar în Brazilia, Franța, Italia și SpaniaGoogle recomandă să fiți atenți la Play Console pentru țările nou acceptate. Configurarea se face prin ProductDetails.InstallmentPlanDetails și urmând ghidul specific pentru a le integra în aplicația dvs.
În paralel, sprijinul este extins achiziții în așteptare pentru abonamente preplătiteAcum puteți oferi modele în care utilizatorul începe achiziția în aplicație și finalizează plata ulterior prin alte mijloace, iar Biblioteca de Facturare știe cum să gestioneze corect acest flux. Activarea se face prin apelarea funcției enablePendingPurchases() la inițializarea BillingClient și, în special pentru planurile preplătite, la utilizarea PendingPurchasesParams.Builder.enablePrepaidPlans().
Perioadele de amortizare pentru Play Billing Library 5 și 6
Odată cu lansarea PBL 7, Google a stabilit date clare pentru retragerea suportului pentru versiunile 5 și 6Dacă vă aflați încă în oricare dintre ele, trebuie să marcați calendarul cu roșu:
- Biblioteca de facturare Google Play 5 va fi oficial retrasă pe 31 august 2024, pentru aplicațiile noi și actualizări. Este posibil să solicitați o prelungire până la 1 noiembrie 2024, dar nu este ceva pe care ar trebui să vă bazați pe termen lung.
- Biblioteca de facturare Google Play 6 poate fi utilizată pentru a publica aplicații noi până la 1 august 2025 și pentru a actualiza aplicațiile existente până la 1 noiembrie 2025.
După această dată, dacă nu ați migrat cel puțin la versiunea 6 sau, în mod ideal, la versiunea 7, va trebui să actualizați la cea mai recentă versiune. Versiunea 7Actualizările vor fi blocate în Play Console. Deși aplicația va continua să funcționeze pe dispozitivele utilizatorilor, veți fi blocată, neputând remedia erori sau adăuga funcții noi care depind de publicarea în magazin.
Cazul .NET MAUI și limitările actuale
Dacă lucrați cu .NET MAUI și abonamente pe Android, probabil ați citit sau ați experimentat deja că nu este atât de simplu. Multe proiecte au folosit Plugin.InAppBilling de James Montemagno, dar pluginul este arhivat și neîntreținut, deci nu va fi actualizat pentru a fi compatibil cu Billing Library 7. În același timp, pachetul oficial Xamarin.Android.Google.BillingClient A rămas ancorat în ecosistemul Xamarin.Android și nu este direct compatibil cu .NET MAUI.
Consecința practică este că Avertismente Play Console Aplicația ta nu folosește Biblioteca de Facturare 7.0.0 sau o versiune ulterioară, ceea ce blochează actualizările dacă continui să utilizezi biblioteci mai vechi. Unii dezvoltatori au optat pentru soluții drastice, cum ar fi dezactivarea temporară a abonamentelor pentru a putea încărca o versiune, dar evident că acest lucru nu este sustenabil dacă modelul tău de afaceri depinde de această monetizare.
În acest context, multe echipe iau în considerare alternative precum SDK-uri terțe Aceste servicii acceptă deja PBL 7 și prezintă o API mai stabilă, multiplatformă (de exemplu, soluții backend cu abonament și SDK-uri pentru Android, iOS și alte platforme). Aceste servicii gestionează de obicei migrările versiunilor Bibliotecii de Facturare și prezintă un wrapper stabil, reducând semnificativ stresul cu fiecare nouă depreciere Google.
Până când Microsoft și echipa MAUI nu oferă o Pachet oficial actualizat și complet compatibil Cu Billing Library 7, opțiunile includ: implementarea propriei legături cu Billing Library nativă, utilizarea unui serviciu terț sau regândirea modului în care integrați achizițiile în proiectul MAUI. În orice caz, este recomandat să nu lăsați decizia până în ultimul moment, deoarece termenele limită ale Play sunt fixe.
Per total, actualizarea versiunii 7 a Bibliotecii de Facturare Google Play implică revizuirea dependențelor, curățarea API-urilor învechite, consolidarea logicii backend cu verificarea achizițiilor și RTDN și utilizarea instrumentelor de testare precum Play Billing Lab pentru a descoperi toate erorile înainte de lansare. Cei care își fac timp să ajusteze această migrare vor putea gestiona mai bine planurile preplătite, taxele virtuale, erorile de rețea și modificările ciclului de viață al abonamentelor și vor avea șanse mult mai mari să mențină venituri stabile și o experiență de utilizare îmbunătățită pe Google Play. Distribuiți informațiile pentru ca mai mulți utilizatori să poată afla despre subiect.