Jeśli korzystasz z zakupów w aplikacji na Androidzie, prędzej czy później będziesz musiał zmierzyć się z Biblioteka rozliczeń Google Play v7To nie jest kolejna aktualizacja: wprowadza zmiany w API, nowe funkcje subskrypcji, wymagania dotyczące konsoli i bardzo jasne terminy od Google. Ignorowanie jej nie jest już możliwe, jeśli chcesz kontynuować publikowanie lub aktualizowanie swojej aplikacji w Google Play bez żadnych niespodzianek.
W tym artykule zobaczysz, jak Aktualizacja i wdrożenie biblioteki rozliczeń Google Play v7 Krok po kroku: od różnic w porównaniu z PBL 5 i 6, przez integrację subskrypcji, zakupów jednorazowych, RTDN, testowanie z Play Billing Lab, po przetrwanie w ekosystemach takich jak .NET MAUI, gdzie oficjalne wsparcie techniczne jest opóźnione. Chodzi o to, aby po przeczytaniu artykułu można było przygotować migrację z pewnością siebie i bez wydawania ani grosza.
Przegląd biblioteki rozliczeń Google Play w wersji 7
Biblioteka rozliczeń Google Play 7 wprowadza znaczące usprawnienia w sposobie zarządzania rachunkami Płatności, subskrypcje i plany specjalneZostał on jednak zaprojektowany tak, aby migracja przebiegała względnie płynnie. Dobrą wiadomością jest to, że wiele nowych interfejsów API jest opcjonalnych: można zaktualizować zależności, zmodyfikować kilka odwołań, a podstawowa integracja nadal będzie działać.
Wersja ta skupia się na trzech kluczowych obszarach: nowe opcje subskrypcji (takich jak wirtualne kwoty), lepsze wsparcie dla oczekujące zakupy w ramach planów przedpłaconychoraz zmiany w API, które usuwają to, co było już przestarzałe w poprzednich wersjach (PBL 5 i 6). Dodatkowo Google dostosowuje obsługę niektórych błędów i sposób obsługi oczekujących transakcji, aby uniknąć niespójności.
Na początek w module aplikacji należy zaktualizować zależność w pliku poziom kompilacji:
dependencies {
def billingVersion = "7.0.0"
implementation "com.android.billingclient:billing:$billingVersion"
}
Po wykonaniu tej czynności czas przejrzeć kod korzystający ze starszych interfejsów API. Wiele wywołań związanych z proporcjonalne rozliczenie subskrypcji i alternatywne rozliczenia Zostały one przemianowane lub usunięte, dlatego warto dokładnie przejrzeć wszystkie odniesienia do BillingClient i BillingFlowParams przed skompilowaniem i przesłaniem czegokolwiek do Konsoli Play.
Strategie monetyzacji z jednorazowymi zakupami i subskrypcjami
Jeśli sprzedajesz produkty cyfrowe w swojej aplikacji, samo wklejenie okna dialogowego zakupu i zakończenie sprzedaży nie wystarczy: zaprojektowanie płynne doświadczenie użytkownika przez cały cykl zakupuDotyczy to zarówno pojedynczych produktów (konsumpcyjnych lub niekonsumpcyjnych), jak i subskrypcji. Im bardziej naturalny i bezproblemowy jest ten proces, tym wyższy wskaźnik konwersji i niższy wskaźnik rezygnacji.
Typowy proces zakupu w ramach usługi Play Billing, niezależnie od tego, czy dotyczy subskrypcji czy pojedynczego produktu, zwykle przebiega według następujących, ściśle określonych etapów, o których powinien wiedzieć także Twój dział zaplecza:
- Użytkownik przegląda dostępne produkty i wybiera jeden.
- Aplikacja inicjuje proces rozliczeniowy Google Play w celu dokończenia płatności.
- Zakup został sfinalizowany, a Twoja aplikacja otrzymała wynik.
- Twój serwer weryfikuje zakup za pomocą interfejsu API programisty Google Play.
- Użytkownikowi w Twoim systemie przyznawane są odpowiednie treści lub prawa.
- Google zostaje poinformowane, że zakup został przetworzony (zrealizowany lub potwierdzony).
W przypadku produktów konsumpcyjnych kluczowe jest, aby zużyj token we właściwym czasie aby umożliwić bezproblemowe odkupy i pomóc Blokuj przypadkowe zakupy w Google PlayW przypadku subskrypcji musisz kontrolować odnowienia, okresy karencji, zawieszenia i anulowania, aby użytkownik otrzymał dokładnie to, za co zapłacił, ani jednego dnia mniej.
Integracja z aplikacją to dopiero połowa zadania: Twój serwer musi utrzymywać wiarygodny zapis praw i statusów zakupówJest to szczególnie ważne, jeśli oferujesz dostęp międzyplatformowy lub potrzebujesz szczegółowych statystyk dotyczących przychodów, retencji i odejść. W tym miejscu z pomocą przychodzą powiadomienia dla deweloperów w czasie rzeczywistym (RTDN), które działają jak „czarna skrzynka” w cyklu życia zakupu.
Dzięki RTDN możesz reagować niemal w czasie rzeczywistym na krytyczne zdarzenia: nowy zakup, nieudane odnowienie, wejście subskrypcji w okres karencji lub anulowanie zakupu. Pozwala to na opracowanie strategii odzyskiwanie abonentów i zapobieganie oszustwomtakie jak automatyczne wysyłanie wiadomości e-mail w przypadku nieudanej płatności lub dostosowywanie praw w przypadku, gdy klient nie otrzyma wiadomości z powodu problemów z siecią.
Powiadomienia dla programistów w czasie rzeczywistym (RTDN) i usługa Google Cloud Pub/Sub
RTDN używają Google Cloud Pub/Sub jako system przesyłania wiadomości w czasie rzeczywistym między Google Play a Twoim zapleczem. Google Play publikuje zdarzenia dotyczące tematu Pub/Sub, a Ty subskrybujesz ten temat, aby otrzymywać wiadomości za każdym razem, gdy zmieni się status zakupu lub subskrypcji.
Podstawowy schemat działania jest prosty: Google Play wysyła wiadomość zakodowaną w formacie Base64 do tematu Pub/Sub, a subskrybent ją wyodrębnia, dekoduje i przetwarza powiadomienie. W polu data W wiadomości znajdziesz obiekt JSON Powiadomienie programistyzawierające informacje takie jak wersja wiadomości, nazwa pakietu, czas zdarzenia oraz szczegółowe dane dotyczące jednorazowych zakupów, subskrypcji, anulowanych zakupów lub wersji próbnych.
{
"version": string,
"packageName": string,
"eventTimeMillis": long,
"oneTimeProductNotification": OneTimeProductNotification,
"subscriptionNotification": SubscriptionNotification,
"voidedPurchaseNotification": VoidedPurchaseNotification,
"testNotification": TestNotification
}
Dzięki tym wiadomościom możesz Zachowaj synchronizację zaplecza, nawet jeśli urządzenie użytkownika ulegnie awariiWyobraź sobie, że użytkownik pomyślnie dokonał zakupu, Google Play go potwierdza, ale urządzenie mobilne traci połączenie, zanim Twoja aplikacja otrzyma wywołanie zwrotne z Biblioteki Rozliczeń. Bez RTDN możesz nigdy się o tym nie dowiedzieć. Dzięki Pub/Sub serwer otrzymuje osobne powiadomienie i może przyznać uprawnienie niezależnie od klienta.
Konfiguracja Cloud Pub/Sub dla RTDN
Przed aktywacją RTDN w konsoli Google Play należy przygotować projekt w Google Cloud Platform (GCP) i skonfiguruj tam Pub/Sub. Proces jest stosunkowo prosty, ale najlepiej go dokładnie przestrzegać, aby uniknąć niespodzianek związanych z uprawnieniami lub nazwami zasobów.
Tworzenie tematu
Najpierw musisz utworzyć Temat Pub/Sub który będzie pełnił funkcję Twojego punktu publikacji w Google Play. W konsoli Google Cloud wybierz swój projekt, przejdź do sekcji Pub/Sub i utwórz nowy temat, postępując zgodnie z oficjalnym przewodnikiem „Tworzenie tematu”. Wynik będzie miał nazwę w następującym formacie:
projects/{project_id}/topics/{topic_name}
Tę pełną nazwę należy wkleić do Konsoli Play po aktywowaniu powiadomień.
Tworzenie subskrypcji
Aby przeczytać wiadomości w tym wątku, potrzebujesz: Subskrypcja Pub/SubMożna to skonfigurować jako naciskać lub jako CiągnąćW referencyjnym codelab pracujemy z subskrypcją typu pull, w której to zaplecze inicjuje żądania pobrania wiadomości.
Zapoznaj się z opcjami w przewodniku subskrybenta Cloud Pub/Sub, aby zdecydować, czy push, czy pull lepiej pasuje do Twojej architektury. Po podjęciu decyzji postępuj zgodnie z dokumentacją „Dodaj subskrypcję” i połącz ją z utworzonym wcześniej tematem. Od tego momentu wszystkie wiadomości publikowane w temacie przez Google Play będą dostępne dla subskrybenta.
Uprawnienia dla Google Play do publikowania w Twoim motywie
Funkcja Pub/Sub nie pozwoli Google Play na publikację czegokolwiek, jeśli nie udzielisz mu wyraźnej zgody. konto usługoweW konsoli Google Cloud należy przejść do ustawień uprawnień tematu i dodać uprawnienia główne:
[email protected]
Nadaj temu kontu rolę Wydawca Pub/Sub (Wydawca). Zapisz zmiany i od tego momentu Google Play będzie mógł wysyłać RTDN do Twojego motywu bez problemów z autoryzacją.
Aktywuj RTDN w Konsoli Google Play
Po skonfigurowaniu funkcji Pub/Sub musisz wskazać Konsoli Play, gdzie mają być wysyłane powiadomienia. W swojej aplikacji w Konsoli Google Play przejdź do Monetyzuj za pomocą Play > Ustawienia monetyzacji i znajdź sekcję powiadomień dla deweloperów w czasie rzeczywistym.
Tam będziesz potrzebować:
- Zaznacz pole, aby włączyć powiadomienia w czasie rzeczywistym.
- Wprowadź pełną nazwę tematu Pub/Sub w odpowiednim polu, przestrzegając formatu
projects/{project_id}/topics/{topic_name}. - Wyślij wiadomość testową używając przycisku testowego.
Wiadomość testowa jest niezbędna do sprawdzenia, czy Integracja jest dobrze wdrożona.Jeśli masz subskrypcję typu pull, możesz przejść do konsoli Cloud, wybrać subskrypcję, kliknąć „Wyświetl wiadomości” i wyodrębnić wiadomość testową. Nie zapomnij o… ack każdej wiadomości, którą czytasz, aby uniknąć jej ponownego odbioru.
W przypadku subskrypcji push sprawdź, czy punkt końcowy odbiera wiadomość i odpowiada prawidłowym kodem HTTP. Jeśli coś pójdzie nie tak, konsola wyświetli błąd podczas publikowania testu, zazwyczaj związany z nazwą tematu lub uprawnieniami konta usługi.
Na koniec możesz skonfigurować, jakie rodzaje powiadomień chcesz otrzymywać: tylko o subskrypcjach i anulowanych zakupach lub wszystkie powiadomienia, w tym te dotyczące jednorazowych zakupów (zdarzenia takie jak ONE_TIME_PRODUCT_PURCHASED i ONE_TIME_PRODUCT_CANCELED). Jeśli używasz również unikalnych produktów, powszechną praktyką jest aktywowanie całego zestawu, aby zachować przejrzystość wszystkich informacji.
Zbuduj subskrybenta Pub/Sub w swoim zapleczu
Mając gotowy motyw i subskrypcję, czas wdrożyć abonent, który odczytuje i przetwarza RTDNGoogle udostępnia przykłady w kilku językach; typowym przypadkiem w Javie jest użycie bibliotek klienta Cloud Pub/Sub do uruchomienia Subscriber który słucha wiadomości i dzwoni MessageReceiver.
Ogólny schemat jest zawsze taki sam: pobierasz wiadomość, dekodujesz pole data Konwertujesz dane base64 na tekst, analizujesz JSON i wyodrębniasz odpowiednie pola (takie jak packageName, oneTimeProductNotification o subscriptionNotification) i zdecyduj, co zrobić w swoim systemie. Po pomyślnym przetworzeniu powiadomienia musisz Potwierdź wiadomość potwierdzeniem aby Pub/Sub nie wysłał go ponownie.
Przykładowy kod pokazuje, jak odbiornik wyświetla wersję i nazwę pakietu, ale w rzeczywistej implementacji można pójść dalej: Potwierdzisz zakup, udzielając prawa właściwemu użytkownikowiNależy zaktualizować bazę danych i w razie potrzeby wywołać interfejs API Play Developer, aby dokonać zakupu lub go rozpoznać.
Powiadomienia o linkach do użytkownika: użycie obfuscatedAccountId
Częstym problemem podczas zarządzania zakupami z serwera jest ustalenie, do którego użytkownika należy dane powiadomienie RTDN. W tym celu API klienta rozliczeń pozwala na dołączenie zaciemniony identyfikator konta gdy uruchamiasz proces zakupu: obfuscatedAccountId.
Chodzi o to, aby użyć stabilnego identyfikatora z systemu (na przykład wewnętrznego identyfikatora użytkownika), ale zaciemnione ze względów prywatności i bezpieczeństwaWartość ta jest powiązana z zakupem, a następnie pojawia się w informacjach zwróconych przez Google Play Developer API, dzięki czemu po otrzymaniu RTDN i zweryfikowaniu tokena będziesz wiedzieć jednoznacznie, któremu kontu w swojej bazie danych powinieneś przyznać uprawnienie.
Po stronie klienta, podczas przygotowywania BillingFlowParamsWystarczy, że zbudujesz listę ProductDetailsParams i zadzwoń setObfuscatedAccountId(obfuscatedAccountId) przed uruchomieniem przepływu. Nie zmienia to wizualnego doświadczenia użytkownika, ale znacznie upraszcza proces. logika alokacji zakupów w zapleczu i pomaga Google wykrywać oszustwa.
Weryfikuj zakupy za pomocą interfejsu API dla programistów Google Play
Przed udzieleniem jakichkolwiek praw na serwerze należy obowiązkowo sprawdzić, czy zakup jest legalny, dzwoniąc pod numer Interfejs API dla programistów Google PlayNie wystarczy polegać na tym, co mówi klient, a nawet RTDN: trzeba to zweryfikować purchaseToken bezpośrednio w stosunku do oficjalnych punktów końcowych i w razie potrzeby zarządzać zwrotami.
W przypadku produktów unikalnych należy użyć punktu końcowego purchases.products:getW przypadku subskrypcji ścieżka prowadzi przez purchases.subscriptionsv2:getZalecany przepływ to:
- wyodrębnić
purchaseTokenz wiadomości Pub/Sub. - Sprawdź swoją bazę danych, aby zobaczyć, czy już ją przetworzyłeś; każdy token jest unikalny na skalę światowąDlatego doskonale nadaje się jako klucz podstawowy, pozwalający uniknąć duplikatów.
- Jeśli jest to nowe, wywołaj interfejs API programisty Google Play, podając pakiet, kod SKU i
purchaseToken. - Sprawdź, czy odpowiedź wskazuje status zakupu ZAKUPIONE (nie OCZEKUJĄCE ani anulowane).
- Jeżeli wszystko się zgadza, zarejestruj token i przyznaj odpowiednie uprawnienia powiązanemu z nim użytkownikowi.
Aby komunikować się z API Play Developer z poziomu Java, możesz użyć AndroidPublisher, zainicjowane danymi uwierzytelniającymi konta usługi w formacie JSON. Zakres konfigurujesz samodzielnie. AndroidPublisherScopes.ANDROIDPUBLISHERTworzysz klienta i wywołujesz metodę purchases().products().get(...)Jeżeli połączenie nie powiedzie się z powodu chwilowego problemu z siecią lub usługą, zaleca się wdrożyć ponowne próby z wykładniczym wycofywaniem aby nie przegapić wydarzenia.
Potwierdź lub zakończ zakup z serwera
Po zweryfikowaniu zakupu i udzieleniu autoryzacji w systemie, kolejnym krokiem jest powiadomienie Google o pomyślnym przetworzeniu transakcji. W przypadku produktów jednoelementowych masz dwie opcje: skonsumować zakup lub po prostu rozpoznaj ją.
Produkty konsumpcyjne (np. wirtualna waluta, życie itp.) muszą przejść przez punkt końcowy purchases.products:consumeOznacza to, że token został wykorzystany i umożliwia użytkownikowi ponowny zakup tego samego przedmiotu bez konfliktu. W przypadku produktów nie podlegających zużyciu (takich jak odblokowanie wersji premium na całe życie) należy zadzwonić pod numer purchases.products:acknowledge, która informuje Google, że użytkownik ma już powiązane uprawnienie.
Subskrypcje są używane purchases.subscriptions:acknowledgewskazujący, że subskrypcja została pomyślnie przetworzona i przypisana użytkownikowi. Jeśli nie potwierdzisz zakupu w rozsądnym terminie, Google może założyć, że wystąpił problem i anulować transakcję, dlatego ważne jest, aby… powrót jest zrobiony zaraz po udzieleniu prawa.
W swoim pomocniku AndroidPublisher możesz dodać metody takie jak executeProductPurchasesConsume y executeProductPurchasesAcknowledge które wywołują odpowiednie punkty końcowe. Ponownie, zaleca się wdrożenie ponownych prób w przypadku sporadycznych awarii, aby upewnić się, że żaden token nie pozostanie w niebezpiecznym stanie pośrednim.
Zaawansowane testowanie z Play Billing Lab
Jednym z aspektów, który wielu deweloperów bagatelizuje, jest faza testowania. Aby uruchomić produkt z jakimkolwiek stopniem pewności, musisz być w stanie symulować błędy sieciowe, niestandardowe odpowiedzi i przypadki skrajneTutaj właśnie pojawia się Play Billing Lab, bezpłatna aplikacja w Google Play zaprojektowana specjalnie do testowania integracji z Biblioteką rozliczeń Play.
Play Billing Lab zawiera symulator odpowiedzi co pozwala na wymuszenie różnych BillingResponseCode w wywołaniach Twojej aplikacji do Biblioteki Rozliczeń. W ten sposób możesz odtworzyć scenariusze, w których na przykład klient nie może sfinalizować zakupu z powodu problemu z siecią, ale Twój system zaplecza poprawnie przetwarza RTDN i ostatecznie przyznaje uprawnienie bez interwencji użytkownika.
Aby Twoja aplikacja mogła komunikować się z symulatorem, musisz włączyć testowanie „nadpisów rozliczeń” za pomocą metadanych w 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>
Etykieta włącz testowanie nadpisów rozliczeń Aktywuj testy symulowanej odpowiedzi w bibliotece rozliczeń. Tag NONPRODUCTION to swego rodzaju przypomnienie, że ta kompilacja nie powinna trafić do produkcji z aktywnymi nadpisaniami. Przygotowując wersję finalną dla użytkowników, upewnij się, że… Usuń te metadane lub użyj osobnego manifestu.
Po skonfigurowaniu w aplikacji Play Billing Lab zaloguj się na konto testera licencji, aktywuj opcję „Symuluj odpowiedź biblioteki Play Billing” i wybierz, jakie kody błędów chcesz zwracać dla każdego interfejsu API (na przykład konkretny błąd w consumeAsyncNastępnie wystarczy otworzyć aplikację i uruchomić przepływ, który chcesz przetestować: symulator zwróci skonfigurowane odpowiedzi, a Ty będziesz mógł sprawdzić, czy logika ponawiania prób, obsługa błędów i RTDN zachowują się zgodnie z oczekiwaniami.
Kluczowe zmiany w API podczas migracji do biblioteki rozliczeń Play 7
Poza RTDN i testowaniem, migracja do PBL 7 wymaga rozwiązania pewnych problemów z API. Osoby, które przechodzą z PBL 5 lub 6, powinny zapoznać się z najważniejszymi zmianami, aby upewnić się, że projekt kompiluje się płynnie, a logika biznesowa pozostaje spójna.
Po pierwsze, interfejsy API związane z Tryb proporcjonalny Opcje zmiany subskrypcji zostały usunięte. Teraz używane są następujące opcje: Tryb wymiany aby zarządzać zmianami planu (podwyższenia, obniżenia itp.). Jeśli nadal korzystasz z metod takich jak setReplaceProrationMode o setReplaceSkusProrationModeBędziesz musiał przenieść je do nowych wariantów setSubscriptionReplacementMode i dostosuj logikę zgodnie z zaktualizowaną dokumentacją.
API również zostało usunięte launchPriceConfirmationFlowktóry został już oznaczony jako przestarzały. Aby poradzić sobie ze zmianami cen subskrypcji, należy zapoznać się z nowymi procedurami i zaleceniami zawartymi w przewodniku po zmianach cen, który szczegółowo opisuje, jak prawidłowo informować użytkownika i jak zarządzać jego zgodą.
Kolejnym ważnym punktem jest Alternatywne interfejsy API do rozliczeńMetody BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails zniknęły na rzecz bardziej spójnej nomenklatury: teraz musisz używać BillingClient.Builder.enableUserChoiceBilling() obok UserChoiceBillingListener y UserChoiceDetailsWedług samego Google jest to w zasadzie zmiana nazwy bez żadnych zmian w zachowaniu, w kontekście naznaczonym umowami takimi jak Google i Epic Games zgadzają się na udostępnienie platformy Android.
Na koniec wprowadzany jest nowy kod błędu. BŁĄD_SIECIOWY en BillingResultoraz znaczenia i warunki PRZEKROCZENIE_CZASOWEGO_USŁUGI i NIEDOSTĘPNA_USŁUGAJeśli masz niestandardową logikę obsługi błędów (na przykład decydującą, kiedy wyświetlić użytkownikowi wiadomość, kiedy ponowić próbę itp.), zaleca się jej przejrzenie pod kątem uwzględnienia tych nowych niuansów.
Oczekujące transakcje i brak identyfikatora zamówienia do momentu ZAKUPU
Subtelna zmiana w PBL 7 polega na tym, że biblioteka nie generuje już Identyfikator zamówienia dla oczekujących zakupów. W takich przypadkach orderId Będzie on dostępny dopiero po osiągnięciu przez zakup statusu „ZAKUPIONY”. Dotyczy to szczególnie przepływów pracy, w których od początku jako główny punkt odniesienia użyto identyfikatora zamówienia.
Google zaleca, abyś polegał na purchaseToken do Twoich zapisów i uzgodnieńprzynajmniej do momentu, gdy transakcja jest w toku. Jeśli znajdziesz zakup, który zniknął z Play, sprawdź Co zrobić, jeśli zakup zniknie.
Jeśli jeszcze nie pracowałeś z zaległymi saldami, zapoznaj się z przewodnikiem integracji Biblioteki rozliczeń i dokumentacją na stronie zarządzanie cyklem życia zamówieńZnajdziesz tam informacje o różnych stanach, jak reagować na każdy z nich i jaką rolę w tej układance odgrywają RTDN.
Nowe opcjonalne możliwości w PBL 7: wirtualne raty i przedpłaty
Wśród „fajnych” nowych funkcji PBL 7 znajdują się: wirtualne opłaty abonamentowe (wirtualne subskrypcje ratalne) oraz rozszerzone wsparcie dla oczekujących zakupów w ramach subskrypcji przedpłaconych. Funkcje te nie są obowiązkowe, ale mogą zapewnić większą elastyczność w dostosowywaniu modelu biznesowego do różnych rynków.
Wirtualne raty pozwalają użytkownikowi płacić za subskrypcję długoterminową małe okresowe płatnościGoogle wyjaśnia, że zamiast jednorazowej dużej płatności, w przypadku rozliczeń z deweloperami, nadal otrzymujesz miesięczne płatności w ramach planu rocznego z miesięcznymi ratami. Jeśli użytkownik nie dokona płatności, ani Ty, ani Google nie powinniście podejmować prób odzyskania wcześniejszych rat. Dzięki temu praktyczne zastosowanie tej opcji jest dość podobne do standardowej miesięcznej subskrypcji, przynajmniej na początku.
Na razie te opłaty abonamentowe są dostępne tylko w Brazylia, Francja, Włochy i HiszpaniaGoogle zaleca śledzenie Konsoli Play w przypadku nowych krajów objętych wsparciem. Konfigurację przeprowadza się za pomocą ProductDetails.InstallmentPlanDetails i postępuj zgodnie ze szczegółowymi instrukcjami, aby zintegrować je ze swoją aplikacją.
Równolegle rozszerzane jest wsparcie oczekujące zakupy w ramach subskrypcji przedpłaconychTeraz możesz oferować modele, w których użytkownik rozpoczyna zakup w aplikacji, a następnie dokonuje płatności w inny sposób, a Biblioteka Rozliczeń wie, jak prawidłowo obsłużyć ten proces. Aktywacja odbywa się poprzez wywołanie enablePendingPurchases() podczas inicjowania BillingClient, a w szczególności w przypadku planów przedpłaconych, za pomocą PendingPurchasesParams.Builder.enablePrepaidPlans().
Okresy amortyzacji dla biblioteki rozliczeń Play 5 i 6
Wraz z wprowadzeniem PBL 7 firma Google ustaliła jasne daty wycofanie wsparcia dla wersji 5 i 6Jeśli nadal znajdujesz się w którymś z nich, musisz zaznaczyć kalendarz na czerwono:
- Biblioteka rozliczeń Google Play 5 zostanie oficjalnie wycofana 31 sierpnia 2024 r. w przypadku nowych aplikacji i aktualizacji. Można poprosić o przedłużenie do 1 listopada 2024 r., ale nie jest to rozwiązanie, na którym warto polegać długoterminowo.
- Bibliotekę rozliczeń Google Play w wersji 6 można wykorzystywać do publikowania nowych aplikacji do 1 sierpnia 2025 r. oraz do aktualizowania istniejących aplikacji do 1 listopada 2025 r.
Po tej dacie, jeśli nie dokonano migracji co najmniej do wersji 6, a najlepiej do wersji 7, konieczne będzie przeprowadzenie aktualizacji do najnowszej wersji. Wersja 7Aktualizacje w Konsoli Play zostaną zablokowane. Chociaż Twoja aplikacja będzie nadal działać na urządzeniach użytkowników, zostanie ona zawieszona i nie będzie można naprawiać błędów ani dodawać nowych funkcji, które wymagają publikacji w sklepie.
Przypadek .NET MAUI i obecne ograniczenia
Jeśli pracujesz z .NET MAUI i subskrypcjami na Androidzie, prawdopodobnie już czytałeś lub doświadczyłeś, że to nie jest takie proste. Wiele projektów korzysta z Plugin.InAppBilling autorstwa Jamesa Montemagno, ale wtyczka jest zarchiwizowana i nie jest utrzymywana, więc nie będzie aktualizowana w celu obsługi Billing Library 7. Jednocześnie oficjalny pakiet Xamarin.Android.Google.BillingClient Nadal jest on zakotwiczony w ekosystemie Xamarin.Android i nie jest bezpośrednio kompatybilny z .NET MAUI.
Praktyczną konsekwencją jest to, że Konsola Play ostrzega Twoja aplikacja nie korzysta z biblioteki Billing Library w wersji 7.0.0 lub nowszej, co blokuje aktualizacje, jeśli nadal korzystasz ze starszych bibliotek. Niektórzy deweloperzy zdecydowali się na drastyczne rozwiązania, takie jak tymczasowe wyłączenie subskrypcji, aby móc przesłać wersję, ale oczywiście nie jest to rozwiązanie trwałe, jeśli Twój model biznesowy opiera się na tej monetyzacji.
W tym kontekście wiele zespołów rozważa alternatywy, takie jak: Zestawy SDK innych firm Usługi te już teraz obsługują PBL 7 i udostępniają bardziej stabilny, wieloplatformowy interfejs API (na przykład rozwiązania subskrypcyjne z pakietami SDK dla systemów Android, iOS i innych). Zazwyczaj obsługują one migracje wersji biblioteki rozliczeń i udostępniają stabilny wrapper, co znacznie zmniejsza obciążenie związane z każdym kolejnym wycofaniem funkcji przez Google.
Dopóki Microsoft i zespół MAUI nie zaoferują Oficjalny pakiet zaktualizowany i w pełni kompatybilny W przypadku Billing Library 7 opcje obejmują: wdrożenie własnego powiązania z natywną Biblioteką Rozliczeń, skorzystanie z usługi zewnętrznej lub przemyślenie sposobu integracji zakupów w projekcie MAUI. W każdym razie najlepiej nie odkładać decyzji na ostatnią chwilę, ponieważ terminy w Play są stałe.
Ogólnie rzecz biorąc, aktualizacja do Google Play Billing Library v7 obejmuje weryfikację zależności, usunięcie przestarzałych interfejsów API, wzmocnienie logiki zaplecza poprzez weryfikację zakupów i RTDN oraz wykorzystanie narzędzi testowych, takich jak Play Billing Lab, w celu wykrycia wszystkich błędów przed uruchomieniem. Osoby, które poświęcą czas na dopracowanie tej migracji, będą lepiej radzić sobie z planami przedpłaconymi, opłatami wirtualnymi, błędami sieciowymi i zmianami w cyklu życia subskrypcji, a także będą miały znacznie większe szanse na utrzymanie stabilnych przychodów i dopracowanego doświadczenia użytkownika w Google Play. Udostępnij informacje, aby więcej użytkowników mogło dowiedzieć się więcej na ten temat.