Compras no aplicativo para Android, parte 4: os códigos de erro da biblioteca de faturamento e como evitar problemas com os testes.

Hoje vamos falar sobre os códigos de erro que encontramos na Biblioteca de Faturamento usando o método getResponseCode().

Um exemplo de como repassamos erros para nossas chamadas de retorno pode ser encontrado neste artigo. Já analisamos um dos erros em artigos anteriores — é o USER_CANCELED quando um usuário fecha a caixa de diálogo de compra sem comprar nada. Vamos conhecer os outros.

ERROR e DEVELOPER_ERROR

Vamos começar com os erros chamados ERROR (código de resposta 6) e DEVELOPER_ERROR (código de resposta 5). No primeiro caso, o Google escreve na documentação “Erro fatal durante a execução da API”, e para o segundo, “Os argumentos fornecidos à API” são inválidos”. Por exemplo, obtive um DEVELOPER_ERROR quando passei uma string vazia para o construtor em setType() para a solicitação querySkuDetailsAsync().

Mas não é assim tão simples. Fui além e no método launchBillingFlow() usei o SkuDetails modificado (puxei o JSON do SkuDetails do produto real, mudei a ID do produto e o passei para o novo construtor do SkuDetails). Na verdade, trata-se de um argumento inválido, e eu esperava obter um DEVELOPER_ERROR, mas … Obtive um ERROR.

É claro que esse foi um exemplo fictício. O caso em que o Google rejeitou o pagamento está muito mais próximo da realidade. Se você selecionar “cartão de teste, sempre recusado” na caixa de diálogo de compra ao testar compras com um cartão de teste, que iremos falar no final do artigo, o ERROR também retornará, mas com um texto adequado.

No terceiro artigo, onde foi descrita a mudança de assinatura, aumentamos quase 3 vezes o preço de uma assinatura anual para um dos modos de cobrança proporcional, mas deixamos de avisar sobre o tipo de erro que poderia ocorrer caso não tivéssemos feito essa alteração. Estamos corrigindo.

Considerando que o modo de cobrança proporcional incorreto foi especificado, devemos obter, logicamente, o mesmo DEVELOPER_ERROR. Em vez disso, obtemos um SERVICE_UNAVAILABLE (Código de resposta 2). Esse erro também pode ser obtido se digitarmos qualquer número incorreto como modo de cobrança proporcional (isso é um número inteiro, não enumeração, e ninguém nos impedirá) e se especificarmos o token de compra errado. Analisamos a documentação sobre SERVICE_UNAVAILABLE e … espere, o quê?! Verificamos que a “conexão de rede caiu”.

Ao mesmo tempo, notamos também um diálogo esquisito:

Outro ponto interessante no caso de ERROR é que ao fechar a caixa de diálogo NOT utilizando o botão “OK” (ou seja, algo que pode ser interpretado como “navegar de volta”), o ERROR aparece para onPurchasesUpdated(), e no caso de SERVICE_UNAVAILABLE em uma situação semelhante aparece USER_CANCELED (mas se você clicar “OK” na caixa de diálogo, aparecerá SERVICE_UNAVAILABLE, como esperado).

E no caso de perda de conexão com a Internet, de fato aparece SERVICE_UNAVAILABLE.

Códigos de erro

Confira mais alguns códigos de erro com pequenos comentários, digamos assim, citações honrosas.

• BILLING_UNAVAILABLE (Código de resposta 3). O Google explica que “A versão da API de faturamento não é compatível com o tipo solicitado”. Consegui reproduzir o erro saindo da minha conta no Google, bem como ao usar um dispositivo Huawei sem os Serviços Google Play. Ele também pode ser reproduzido em celulares mais antigos onde o Google Play não foi atualizado.
• SERVICE_DISCONNECTED (Código de resposta -1). Às vezes, o aplicativo desconecta-se do serviço Google Play. É algo que pode acontecer se a Play Store for atualizada sem aviso. Portanto, recomendo que você aja com segurança e se conecte antes de cada chamada dos métodos da Biblioteca de Faturamento, como descrito nos artigos anteriores. Além disso, tanto o Google quanto nós sugerimos que você inclua uma política de nova tentativa caso este erro ainda apareça na resposta.
• SERVICE_TIMEOUT (Código de resposta -3). O nome já fala por si: há muito tempo que aguardamos uma resposta do Google Play.
• FEATURE NOT SUPPORTED. Existem cinco constantes FeatureType na classe BillingClient. Sua disponibilidade neste dispositivo pode ser verificada usando o método  BillingClient.isFeatureSupported(BillingClient.FeatureType.A_NECESSARY_FEATURE). No meu celular (Xiaomi Mi A2 Lite), FEATURE_NOT_SUPPORTED retornou apenas para SUBSCRIPTIONS_ON_VR. Paralelamente, para IN_APP_ITEMS_ON_VR, bem como para todas as outras funcionalidades, retornou um OK.
• ITEM_NOT_OWNED (Código de resposta 8). Ocorre enquanto tentamos fazer uma compra que não existe. É possível, mesmo após uma compra realizada com sucesso.
• ITEM_ALREADY_OWNED (Código de resposta 7). Neste caso, pelo contrário, o erro ocorre ao tentar comprar um produto que já temos. Nesse caso, você só precisa atualizar a interface do usuário e tornar o botão de compra inacessível.

ITEM_UNAVAILABLE

O último erro e provavelmente o mais comum observado no início da jornada de implementação de compras no aplicativo é  ITEM_UNAVAILABLE (Código de resposta 4). Afirma que o produto não está disponível para compra, mas não explica por quê. Os motivos podem ser variados: desde testes na conta ou dispositivo errado até a compra de um produto inativo.

Apresentamos a seguir uma lista de verificação sobre o que você precisa fazer para evitar este erro durante os testes:

1.   Envie um aplicativo integrado com a Biblioteca de Faturamento para sua faixa de testes. Trata-se de uma condição obrigatória; paralelamente, você também pode testar em builds de depuração com o mesmo applicationId, mas é importante que o aplicativo integrado com a Biblioteca de Faturamento seja carregado no Play Console pelo menos uma vez.

2.   Adicione contas do Google de testadores a esta faixa de testes, o que é especialmente importante para a realização de testes internos ou alfa/beta fechados. Haverá também um link na seção Como os testadores participam dos testes, onde os testadores devem aceitar o convite.

3.   Você só pode comprar um produto ativado. Depois de criar um produto, há um botão de ativação no Play Console. Descrevemos o processo de criação de um produto com mais detalhes no primeiro artigo.

4.   Assegure-se de que o teste no dispositivo seja realizado com a conta do Google de um testador (o que significa que ele deve estar inscrito como testador nesta faixa de testes e deve ter todo o acesso técnico necessário). Este ponto parece bastante óbvio, mas tudo pode acontecer, e você também precisa verificar esse ponto em particular caso tenha recebido um erro desse tipo.

5.   O applicationId da versão usada para realizar testes de compra deve corresponder totalmente ao applicationId do Play Console. Este aspecto é especialmente importante para aqueles que têm um sufixo adicionado em seus builds de depuração.

6.   Adicione os endereços de e-mail dos testadores à seção Setup → License Testing no menu esquerdo da conta (não da aplicação), para que eles possam comprar produtos gratuitamente com um cartão de teste, não um cartão real. Outra vantagem é que, neste caso, as assinaturas terão um prazo limite para a realização do teste. Trata-se de uma informação que não está relacionada a esse erro, mas é útil.

Conclusão

Os erros podem dificultar muito o trabalho, por isso é sempre importante entender como eles podem ocorrer. Considerando o número de etapas necessárias para ter acesso aos produtos, a maneira mais fácil é capturar o ITEM_UNAVAILABLE. Portanto, espero que a minha lista de verificação seja útil para você.

O SDK da Adapty facilita o tratamento de erros e oferece muitas outras vantagens: analytics básico de assinaturas, análise de coorte, teste paywall simples, integração com serviços de analytics, validação de erros do servidor. Experimente já!