BlogRight arrowTutorialRight ArrowZakupy w aplikacji na Androida, część 4: kody błędów biblioteki rozliczeniowej i jak nie namieszać przy testach
BlogRight arrowTutorialRight ArrowZakupy w aplikacji na Androida, część 4: kody błędów biblioteki rozliczeniowej i jak nie namieszać przy testach

Zakupy w aplikacji na Androida, część 4: kody błędów biblioteki rozliczeniowej i jak nie namieszać przy testach

Zakupy w aplikacji na Androida, część 4: kody błędów biblioteki rozliczeniowej i jak nie namieszać przy testach
Listen to the episode
Zakupy w aplikacji na Androida, część 4: kody błędów biblioteki rozliczeniowej i jak nie namieszać przy testach

Dzisiaj porozmawiamy o kodach błędów, które możemy otrzymać z Billing Library w metodzie  getResponseCode().

Przykład jak przekazaliśmy błędy do naszych wywołań zwrotnych można znaleźć w tym artykule. Rozważaliśmy już jeden z błędów w poprzednich artykułach - chodzi o USER_CANCELED, czyli sytuację, gdy użytkownik zamyka okno zakupu bez kupowania czegokolwiek. Poznajmy teraz pozostałe.

⭐️ Download our guide on in-app techniques which will make in-app purchases in your app perfect

ERROR i DEVELOPER_ERROR

Zacznijmy od błędów zwanych ERROR (responseCode 6) oraz DEVELOPER_ERROR (responseCode 5). W pierwszym przypadku Google pisze w dokumentacji "Krytyczny błąd podczas działania API", w drugim – "Do API dostarczono niewłaściwe argumenty". Dla przykładu, uzyskałem DEVELOPER_ERROR, gdy przekazałem pusty ciąg do konstruktora w setType() dla żądania querySkuDetailsAsync().

Jednak nie jest to tak prosta sprawa. Poszedłem dalej i w metodzie launchBillingFlow() zastosowałem zmodyfikowane SkuDetails (wyciągnąłem json ze SkuDetails prawdziwego produktu, zamieniłem w nim productID i przekazałem go do nowego konstruktora SkuDetails). De facto jest to nieprawidłowy argument i spodziewałem się, że otrzymam DEVELOPER_ERROR ale... Efektem był ERROR.

To oczywiście był sztuczny przykład. Przypadek, w którym Google odrzuciło płatność, jest znacznie bliższy rzeczywistości. Jeśli podczas testowania zakupów za pomocą karty testowej wybierzesz "karta testowa, zawsze odrzucaj" w oknie dialogowym zakupu, o czym powiemy ci na końcu artykułu, również otrzymasz ERROR, ale z odpowiednim tekstem.

W trzecim artykule, gdzie opisano zmianę abonamentu, podwyższyliśmy cenę abonamentu rocznego prawie 3 razy dla jednego z trybów proraction (proporcjonalności), ale nie powiedzieliśmy, jaki błąd powinien tam powstać, gdybyśmy tego nie zrobili. Powiemy o tym teraz.

Ponieważ okazuje się, że określony jest tam niewłaściwy tryb proporcji (proration), powinniśmy logicznie uzyskać ten sam DEVELOPER_ERROR. Zamiast tego otrzymujemy SERVICE_UNAVAILABLE (responseCode 2). Otrzymujemy go również, jeśli wpiszemy dowolną liczbę niewłaściwą jako tryb proporcji (jest to int, nie enum, nic nas nie zatrzyma) i jeśli określimy niewłaściwy purchaseToken. Przeglądamy dokumentację dotyczącą SERVICE_UNAVAILABLE i ... zaraz, że co?! Widzimy, że "połączenie sieciowe nie działa".

Jednocześnie widzimy również dziwne okno dialogowe:

Inną ciekawą rzeczą w przypadku ERROR podczas zamykania okna dialogowego NIE za pomocą przycisku "OK" (ściślej, za pomocą środków, które są interpretowane jako "nawiguj z powrotem"), ERROR przychodzi do onPurchasesUpdated(), a w przypadku SERVICE_UNAVAILABLE w podobnej sytuacji pojawia się USER_CANCELED (ale jeśli klikniesz "OK" w oknie dialogowym, otrzymamy SERVICE_UNAVAILABLE, zgodnie z oczekiwaniami).

A w przypadku utraty połączenia z Internetem rzeczywiście przychodzi SERVICE_UNAVAILABLE.

Kody błędów

Oto kilka kodów błędów z małymi komentarzami, można się wyrazić, wyróżnieniami.

  • BILLING_UNAVAILABLE (responseCode 3). Google wyjaśnia, że "wersja API rozliczeń nie jest obsługiwana dla żądanego typu". Udało mi się odtworzyć ten błąd po wylogowaniu się z mojego konta Google, a także podczas korzystania z urządzenia Huawei bez usług Google Play. Może być również odtwarzany na starszych telefonach, w których Google Play nie został zaktualizowany.
  • SERVICE_DISCONNECTED (responseCode -1). Aplikacja jest czasami odłączana od usługi Google Play. Może się to zdarzyć, jeśli Play Store nieoczekiwanie się zaktualizuje. Dlatego radzę się zabezpieczać i połączyć się przed każdym wywołaniem metod Billing Library, jak w poprzednich artykułach. Ponadto, zarówno samo Google, jak i my osobiście radzimy dodać pewne zasady ponownej próby, jeśli ten błąd nadal pojawia się w odpowiedzi.
  • SERVICE_TIMEOUT (responseCode -3). Nazwa mówi sama za siebie: zbyt długo czekaliśmy na odpowiedź od Google Play.
  • FEATURE NOT SUPPORTED. Jest pięć konstant FeatureType w klasie BillingClient. Ich dostępność na tym urządzeniu można sprawdzić za pomocą metody  BillingClient.isFeatureSupported (BillingClient.FeatureType.A_NECESSARY_FEATURE). Na moim telefonie (Xiaomi Mi A2 Lite), FEATURE_NOT_SUPPORTED został zwrócony tylko dla SUBSCRIPTIONS_ON_VR. Jednocześnie dla IN_APP_ITEMS_ON_VR, jak również dla wszystkich innych funkcji, zwrócono OK.
  • ITEM_NOT_OWNED (responseCode 8). Występuje podczas próby konsumpcji zakupu, którego nie mamy. Być może, nawet wielokrotnie po udanej konsumpcji.
  • ITEM_ALREADY_OWNED (responseCode 7). Tutaj mamy sytuację wręcz przeciwną - błąd występuje podczas próby zakupu produktu, który już mamy. W takim przypadku wystarczy zaktualizować interfejs użytkownika i sprawić, aby przycisk zakupu nie był klikalny.
Start for free

Integrate in-app subscriptions in your Android app in 30 minutes with all side cases

Start for free

ITEM_UNAVAILABLE

Ostatnim i prawdopodobnie najpopularniejszym błędem na początku ścieżki implementacji zakupów w aplikacji jest ITEM_UNAVAILABLE (responseCode 4). Mówi nam to, że produkt nie jest dostępny w sprzedaży, ale nie wyjaśnia, dlaczego. Powody mogą być bardzo różne: od testowania na niewłaściwym koncie lub urządzeniu po zakup nieaktywnego produktu.

Oto lista kontrolna czynności, które należy wykonać, aby uniknąć tego błędu podczas testowania:

1.   Wyślij aplikację z Billing Library na ścieżkę testową. Jest to warunek obowiązkowy; w tym samym czasie można również przetestować kompilacje debugowania z tym samym identyfikatorem aplikacji, ale ważne jest, aby aplikacja z Billing Library została przesłana do Play Console co najmniej jeden raz.

2.   Dodaj konta testerów Google do tej ścieżki testowej, co jest szczególnie ważne w testach wewnętrznych lub zamkniętych alfa/beta. W sekcji Jak testerzy dołączają do testu, będzie też link, za pomocą którego testerzy powinni przyjąć zaproszenie.

3.   Możesz kupić tylko aktywowany produkt. Po utworzeniu produktu w Play Console pojawia się przycisk aktywuj. Proces tworzenia produktu opisaliśmy bardziej szczegółowo w pierwszym artykule.

4.   Upewnij się, że testowanie na urządzeniu odbywa się z konta Google testera (co oznacza, że musi być zarejestrowany jako tester na tej ścieżce testowej i musi mieć wszystkie niezbędne techniczne dostępy). Ten punkt wydaje się być oczywisty, ale różne rzeczy mogą się zdarzyć i musisz to również sprawdzić, jeśli otrzymałeś taki błąd.

5.   Identyfikator applicationid kompilacji, który jest używany do testowania zakupu, musi całkowicie odpowiadać identyfikatorowi applicationId z Play Console. Jest to szczególnie ważne dla tych, którzy mają dodany sufiks w swoich kompilacjach debugowania.

6.   Dodaj adresy e-mail testerów do sekcji Setup → License Testing w lewym menu konta (nie aplikacji), dzięki czemu będą kupować produkty za darmo z karty testowej, a nie z prawdziwej. Kolejną zaletą jest to, że subskrypcje w tym przypadku będą miały czasu trwania testu. Nie jest to związane z tym błędem, ale jest to również przydatna kwestia.

Wnioski

Błędy mogą znacznie skomplikować pracę, dlatego zawsze ważne jest, aby zrozumieć, w jaki sposób mogą one wystąpić. Biorąc pod uwagę, ile kroków musisz przejść, aby uzyskać dostęp do produktów, najprostszym sposobem jest złapanie ITEM_UNAVAILABLE. Dlatego mam nadzieję, że moja lista kontrolna ci pomoże.

ADAPTY SDK ułatwi obsługę błędów i zapewni wiele innych zalet: podstawową analitykę subskrypcji, analizę kohortową (cohort analysis), proste testowanie paywalli, integrację z usługami analityki, walidację błędów serwera. Wypróbuj teraz!

Further reading

Dark patterns in subscription apps
Dark patterns in subscription apps
October 17, 2022
45 min listen
Adapty October update 
Adapty October update 
November 4, 2020
3 min read
Over $1M MRR, millions of users, tons of insides
Over $1M MRR, millions of users, tons of insides
July 16, 2021
18 min read, 52 min listen