Acquisti in-app per Android, parte 4: codici di errore della Libreria Fatturazione e come non sbagliare i test

Oggi parleremo dei codici d’errore che possiamo ottenere dalla Libreria Fatturazione con il metodo getResponseCode().

Un esempio di come abbiamo superato gli errori alle nostre callback si trova in questo articolo. Abbiamo già visto uno degli errori negli articoli precedenti:  USER_CANCELED, quando un utente chiude la finestra di dialogo per l’acquisto senza comprare nulla. Andiamo a vedere gli altri.

ERROR e DEVELOPER_ERROR

Cominciamo con gli errori chiamati ERROR (responseCode 6) e DEVELOPER_ERROR (responseCode 5). Nel primo caso, Google scrive nella documentazione “Errore irreversibile durante l’azione API (API)”, nel secondo, “Argomenti non validi forniti all’API”. Ad esempio, sono riuscito a ottenere un DEVELOPER_ERROR quando ho passato una stringa vuota al builder in setType() per la richiesta querySkuDetailsAsync().

Ma non è così semplice. Sono andato avanti e, nel metodo launchBillingFlow() ho usato gli SkuDetails modificati (ho prelevato il json dalle SkuDetails del prodotto reale, ho cambiato il productID e l’ho passato al nuovo builder di SkuDetails). In effetti, si tratta di un argomento non valido, e mi aspettavo di ottenere un DEVELOPER_ERROR, ma… mi è stato restituito un ERROR.

Questo, ovviamente, era un esempio artificiale. Il caso in cui Google ha rifiutato il pagamento è molto più vicino alla realtà. Se si seleziona “carta di prova, sempre rifiutata” nella finestra di dialogo dell’acquisto quando si testano gli acquisti da una carta di prova, ciò di cui vi parleremo alla fine dell’articolo, anche l’ERROR sarà restituito, ma con un testo adeguato.

Nel terzo articolo, in cui abbiamo descritto la modifica dell’abbonamento, abbiamo aumentato il prezzo di un abbonamento annuale di quasi tre volte per una delle modalità di ripartizione, ma non abbiamo detto quale errore avremmo dovuto vedere se non l’avessimo fatto. Ci torniamo sopra qui.

Poiché si è scoperto che in quel punto è stata specificata la modalità di ripartizione sbagliata, logicamente si dovrebbe ottenere lo stesso DEVELOPER_ERROR. Invece, ci viene restituito il messaggio SERVICE_UNAVAILABLE (responseCode 2). Lo si ottiene anche se si inserisce un numero inappropriato come modalità di ripartizione (si tratta di un int, non di un enum, nessuno ci fermerà) e se si specifica un purchaseToken sbagliato. Esaminiamo la documentazione relativa a SERVICE_UNAVAILABLE e… aspetta, cosa?! Vediamo un errore “Network connection is down”.

Allo stesso tempo, visualizziamo anche una strana finestra di dialogo:

Un’altra cosa interessante nel caso di un ERROR è che quando si chiude la finestra di dialogo NON premendo il pulsante “OK” (cioè con mezzi che vengono interpretati come “torna indietro”), l’ERROR diventa onPurchasesUpdated(), e in caso di SERVICE_UNAVAILABLE in una situazione simile, si visualizza USER_CANCELED (ma se si fa clic su “OK” nella finestra di dialogo, verrà restituito SERVICE_UNAVAILABLE, come atteso).

Nel caso in cui venga persa la connessione internet, verrà restituito un messaggio di SERVICE_UNAVAILABLE.

Codici d’errore

Ecco altri codici di errore con dei brevi commenti, per così dire, menzioni d’onore.

• BILLING_UNAVAILABLE (responseCode 3). Google spiega che “la versione dell’API di fatturazione non è supportata per il tipo richiesto”. Sono riuscito a riprodurre questo errore quando sono uscito dal mio account Google e quando ho utilizzato un dispositivo Huawei senza Google Play Services. Il problema può essere riprodotto anche sui telefoni più vecchi, dove Google Play non è stato aggiornato.
• SERVICE_DISCONNECTED (responseCode -1). A volte, l’applicazione si disconnette dal servizio Google Play. Questo può accadere se il Play Store si aggiorna inaspettatamente. Quindi, ti consiglio di andare sul sicuro e di connetterti prima di ogni chiamata ai metodi della Libreria Fatturazione, come negli articoli precedenti. Inoltre, sia noi che Google consigliamo, se nella risposta continua a ripresentarsi l’errore, di aggiungere una policy di “nuovo tentativo”.
• SERVICE_TIMEOUT (responseCode -3). Il nome parla da sé: è da troppo tempo che aspettiamo una risposta da Google Play.
• FEATURE NOT SUPPORTED. Ci sono cinque costanti FeatureType, nella classe BillingClient. La loro disponibilità su questo dispositivo, può essere verificata usando il metodo  BillingClient.isFeatureSupported(BillingClient.FeatureType.A_NECESSARY_FEATURE). Sul mio telefono (Xiaomi Mi A2 Lite), FEATURE_NOT_SUPPORTED è stato restituito solo per SUBSCRIPTIONS_ON_VR. Allo stesso tempo, per IN_APP_ITEMS_ON_VR, così come per tutte le altre funzionalità, è tornato l’OK.
• ITEM_NOT_OWNED (responseCode 8). Si verifica quando si cerca di consumare un acquisto che non si ha. Può capitare anche, ripetutamente, dopo un consumo riuscito.
• ITEM_ALREADY_OWNED (responseCode 7). Qui, al contrario, l’errore si verifica durante il tentativo di acquistare un prodotto già in nostro possesso. In questo caso, è sufficiente aggiornare l’interfaccia utente e rendere il pulsante di acquisto non cliccabile.

ITEM_UNAVAILABLE

L’ultimo errore, probabilmente il più diffuso all’inizio del percorso di implementazione degli acquisti in-app, è  ITEM_UNAVAILABLE (responseCode 4). Dice che il prodotto non è disponibile per l’acquisto, ma non ne spiega il motivo. I motivi possono essere diversi: dal test sull’account o sul dispositivo sbagliato all’acquisto di un prodotto inattivo.

Ecco una lista di controllo di ciò che è necessario fare per evitare questo errore durante i test:

1.   Invia un’applicazione con la libreria di fatturazione al tuo percorso di test. Questa è una condizione obbligatoria; allo stesso tempo, è possibile eseguire il test anche su build di debug con lo stesso applicationId, ma è importante che l’app con la Libreria Fatturazione venga caricata su Play Console almeno una volta.

2.   Aggiungi gli account Google dei tester a questo percorso di test, che è particolarmente importante per i test interni o per l’alfa/beta chiuso. Sarà disponibile anche un link nella sezione Come i tester possono partecipare al test, dove i tester dovranno accettare l’invito.

3.   È possibile acquistare solo un prodotto attivato. Dopo aver creato un prodotto, nella Play Console, si visualizzerà un pulsante activate. Descriviamo il processo di creazione di un prodotto in modo più dettagliato nel primo articolo.

4.   Assicurati che il test sul dispositivo avvenga dall’account Google di un tester (il che significa che deve essere iscritto come tester in questo percorso di test e che deve disporre di tutti gli accessi tecnici necessari). Questo punto sembra essere ovvio, ma tutto può succedere e bisogna controllare anche questo, se si è ricevuto questo tipo di errore.

5.   L’ApplicationId della build utilizzata per il test di acquisto deve corrispondere completamente all’ApplicationId della Play Console. Questo è particolarmente importante per coloro che hanno aggiunto un suffisso nelle loro build di debug.

6.   Aggiungi gli indirizzi e-mail dei tester alla sezione Setup → License Testing nel menu di sinistra dell’account (non dell’applicazione), in modo da acquistare gratuitamente i prodotti con  una carta di prova e non con una reale. Un altro vantaggio è che le sottoscrizioni, in questo caso, avranno una durata del test. Non è correlato a questo errore, ma è utile saperlo.

Conclusione

Gli errori possono complicare notevolmente il lavoro, quindi è sempre importante capire come possono verificarsi. Considerando i numerosi passaggi necessari per ottenere l’accesso ai prodotti, l’errore che si presenta più di frequente è ITEM_UNAVAILABLE. Spero che la mia lista di controllo ti sia d’aiuto.

L’SDK (SDK) Adapty renderà più semplice gestire gli errori e offre molti altri vantaggi: analisi di base degli abbonamenti, analisi di coorte (cohort analysis), test semplice dei paywall, integrazione (integration) con i servizi di analisi, convalida degli errori del server. Provalo subito!