{"id":137945,"date":"2021-09-29T00:00:00","date_gmt":"2021-09-29T00:00:00","guid":{"rendered":"https:\/\/adapty.io\/pt-android-in-app-purchases-part-4-billing-library-error-codes-and-how-not-to-fail-testing\/"},"modified":"2021-09-29T00:00:00","modified_gmt":"2021-09-29T00:00:00","slug":"android-in-app-purchases-part-4-billing-library-error-codes-and-how-not-to-fail-testing","status":"publish","type":"post","link":"https:\/\/adapty.io\/pt\/blog\/android-in-app-purchases-part-4-billing-library-error-codes-and-how-not-to-fail-testing\/","title":{"rendered":"Compras no aplicativo para Android, parte 4: os c\u00f3digos de erro da biblioteca de faturamento e como evitar problemas com os testes."},"content":{"rendered":"\n

Hoje vamos falar sobre os c\u00f3digos de erro<\/a> que encontramos na Biblioteca de Faturamento usando o m\u00e9todo getResponseCode()<\/a>.<\/p>\n\n\n\n

Um exemplo de como repassamos erros para nossas chamadas de retorno pode ser encontrado neste artigo<\/a>. J\u00e1 analisamos um dos erros em artigos anteriores \u2014 \u00e9 o USER_CANCELED<\/strong><\/a> quando um usu\u00e1rio fecha a caixa de di\u00e1logo de compra sem comprar nada. Vamos conhecer os outros.<\/p>\n\n\n\n\n\n

ERROR e DEVELOPER_ERROR<\/h2>\n\n\n\n

Vamos come\u00e7ar com os erros chamados ERROR<\/strong><\/a> (c\u00f3digo de resposta 6) e DEVELOPER_ERROR<\/strong><\/a> (c\u00f3digo de resposta 5). No primeiro caso, o Google escreve na documenta\u00e7\u00e3o \u201cErro fatal durante a execu\u00e7\u00e3o da API\u201d, e para o segundo, \u201cOs argumentos fornecidos \u00e0 API\u201d s\u00e3o inv\u00e1lidos\u201d. Por exemplo, obtive um DEVELOPER_ERROR quando passei uma string vazia para o construtor em setType()<\/a> para a solicita\u00e7\u00e3o querySkuDetailsAsync()<\/a>.<\/p>\n\n\n\n

Mas n\u00e3o \u00e9 assim t\u00e3o simples. Fui al\u00e9m e no m\u00e9todo launchBillingFlow()<\/a> usei o SkuDetails<\/a> 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\u00e1lido, e eu esperava obter um DEVELOPER_ERROR<\/strong>, mas … Obtive um ERROR<\/strong>.<\/p>\n\n\n\n

\u00c9 claro que esse foi um exemplo fict\u00edcio. O caso em que o Google rejeitou o pagamento est\u00e1 muito mais pr\u00f3ximo da realidade. Se voc\u00ea selecionar “cart\u00e3o de teste, sempre recusado” na caixa de di\u00e1logo de compra ao testar compras com um cart\u00e3o de teste, que iremos falar no final do artigo, o ERROR<\/strong> tamb\u00e9m retornar\u00e1, mas com um texto adequado.<\/p>\n\n\n\n

No terceiro artigo<\/a>, onde foi descrita a mudan\u00e7a de assinatura, aumentamos quase 3 vezes o pre\u00e7o de uma assinatura anual para um dos modos de cobran\u00e7a proporcional, mas deixamos de avisar sobre o tipo de erro que poderia ocorrer caso n\u00e3o tiv\u00e9ssemos feito essa altera\u00e7\u00e3o. Estamos corrigindo.<\/p>\n\n\n\n

Considerando que o modo de cobran\u00e7a proporcional incorreto foi especificado, devemos obter, logicamente, o mesmo DEVELOPER_ERROR<\/strong>. Em vez disso, obtemos um SERVICE_UNAVAILABLE<\/strong><\/a> (C\u00f3digo de resposta 2). Esse erro tamb\u00e9m pode ser obtido se digitarmos qualquer n\u00famero incorreto como modo de cobran\u00e7a proporcional (isso \u00e9 um n\u00famero inteiro, n\u00e3o enumera\u00e7\u00e3o, e ningu\u00e9m nos impedir\u00e1) e se especificarmos o token de compra errado. Analisamos a documenta\u00e7\u00e3o sobre SERVICE_UNAVAILABLE<\/strong> e \u2026 espere, o qu\u00ea?! Verificamos que a \u201cconex\u00e3o de rede caiu\u201d.<\/p>\n\n\n\n

Ao mesmo tempo, notamos tamb\u00e9m um di\u00e1logo esquisito:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Outro ponto interessante no caso de ERROR<\/strong> \u00e9 que ao fechar a caixa de di\u00e1logo NOT<\/strong> utilizando o bot\u00e3o \u201cOK\u201d (ou seja, algo que pode ser interpretado como \u201cnavegar de volta\u201d), o ERROR <\/strong>aparece para onPurchasesUpdated()<\/a>, e no caso de SERVICE_UNAVAILABLE<\/strong> em uma situa\u00e7\u00e3o semelhante aparece USER_CANCELED<\/strong> (mas se voc\u00ea clicar \u201cOK\u201d na caixa de di\u00e1logo, aparecer\u00e1 SERVICE_UNAVAILABLE<\/strong>, como esperado).<\/p>\n\n\n\n

E no caso de perda de conex\u00e3o com a Internet, de fato aparece SERVICE_UNAVAILABLE<\/strong>.<\/p>\n\n\n\n

C\u00f3digos de erro<\/h2>\n\n\n\n

Confira mais alguns c\u00f3digos de erro com pequenos coment\u00e1rios, digamos assim, cita\u00e7\u00f5es honrosas.<\/p>\n\n\n\n