Capturando Erros na Aplicação
Antes de coletar dados, é importante recordar algumas características principais do comportamento do SDK nos ambientes de homologação e produção, conforme discutido nas seções 3 e 6 deste documento.
Ambiente de Homologação
Erros na Etapa de Criação do Terminal
Apenas o status 'Jailbreak/Modo Root Ativado' impede o uso.
Erros na Etapa de Criação da Sessão
Não há erros de sessão, pois as credenciais internas não são verificadas.
Erros nas Etapas de Leitura do Cartão e Envio da Transação
Os erros seguem as descrições fornecidas na Seção 6 - Instruções para Implantação do App em Produção deste documento e podem ser capturados nos logs normalmente.
Ambiente de Produção
Erros na Etapa de Criação do Terminal
Verificações de permissão para o dispositivo, aplicativos maliciosos, modo desenvolvedor ativado, aplicativos instalados fora do Google Play e outras verificações extensivas mencionadas na Seção 6 - Instruções para Implantação do App em Produção deste documento devem ser observadas.
Erros de Sessão
As credenciais são verificadas de acordo com os detalhes fornecidos na Seção 6 - Instruções para Implantação do App em Produção deste documento
Erros nas Etapas de Leitura do Cartão e Envio da Transação
Erros nas Etapas de Leitura do Cartão e Envio da Transação
Tipos de logs
Redactable Log
Estes logs aparecem apenas no ambiente de produção e são criptografados pelo SDK, destinados exclusivamente para interpretação pela First Tech. Eles são essenciais para entender os erros e devem sempre ser enviados.
Exemplo de um Redactable Log
2025-01-09 13:37:57.009 19993-20669 TapOnPhoneLogger br.com.app D r.110002 : #0.0.1 #1.1. #2.1. #3.1. #4.1. #5.1. #6.1. #7.1. #8.1. #9.1. #10.1. #11.1. #12.0.1Logs de Erro Públicos do SDK
These logs are displayed as exceptions are generated within the viewData and shown on the screen. Essentially, they correspond to the exception classes described in Section 6 - Instructions for Deploying the App in Production of this document, containing guidelines for issue resolution.
They must be sent to First Tech, along with the Redactable Logs, when opening a support ticket.
Example of a Public SDK Error Log:
Eles devem ser enviados à First Tech, junto com os Logs Redatáveis, no momneto da abertu do ticket
Exemplo de um Log de Erro Público do SDK:
Logs da Aplicação
Logs criados pelo desenvolvedor da aplicação para monitorar seus próprios processos de negócio e indicadores de problemas. Estes logs normalmente não são analisados pela First Tech durante inspeções.
Os logs podem ser extremamente extensos; portanto, filtrá-los e organizá-los antes de enviar um ticket acelera significativamente o processo de resolução de problemas. Para uma análise eficaz, o log coletado deve ser limitado a um máximo de 100 linhas e focar exclusivamente na transação que causou o problema, removendo quaisquer registros irrelevantes ou entradas relacionadas a outros aspectos da aplicação.
Coletando Logs com o SDK de Homologação
Peça ao desenvolvedor para configurar as variantes de build no Android Studio para o ambiente de homologação (hml) ao usar nosso SDK de homologação. Com o projeto aberto, acesse a janela do console pressionando Alt + F12.
Se o desenvolvedor não estiver familiarizado com variantes de build, oriente-o a consultar a Seção 4: Preparação do Ambiente para Começar para mais informações.
Não se esqueça de solicitar que o modo desenvolvedor esteja ativado no dispositivo.
O dispositivo móvel deve estar conectado ao computador. Isso permite que você execute o seguinte comando no console para exibir apenas logs de erro criptografados e salvá-los em um arquivo contendo apenas logs criptografados e públicos:
O dispositivo móvel deve estar conectado ao computador. Isso permite que você execute o seguinte comando no console para exibir apenas logs de erro criptografados e salvá-los em um arquivo contendo apenas logs criptografados e públicos:
O comando gerará um arquivo chamado logs.txt na pasta especificada pelo caminho no console. O próximo passo é repetir a operação, coletando todos os erros e gerando um segundo arquivo contendo o conjunto completo de erros da aplicação durante o processo.
O comando irá gerar um arquivo chamado logs2.txt na pasta especificada pelo caminho no console.
A diferença entre os dois logs permitirá uma análise mais precisa, separando o contexto do SDK Tap to Phone dos logs públicos e logs da aplicação.
Analise ambos os arquivos e, se nenhum erro público coberto por este documento tiver um procedimento de resolução efetivo (consulte a Seção 6: Instruções para Liberação do Aplicativo para Produção), prossiga com a abertura de um ticket com a First Tech, incluindo esses dois arquivos de log.
Coletando Logs com o SDK de Produção//Collecting Logs with the Production SDK
O processo segue os mesmos passos descritos na Seção 5.1: Coletando Logs com o SDK de Homologação, mas atenção especial deve ser dada ao desligar e ligar o modo desenvolvedor no momento correto.
Peça ao desenvolvedor para configurar as variantes de build no Android Studio para o ambiente de homologação (hml) quando estiver usando nosso SDK de homologação. Com o projeto aberto, acesse a janela do console pressionando Alt + F12.
Se o desenvolvedor não estiver familiarizado com variantes de build, oriente-o a consultar a Seção 4: Preparação do Ambiente para Começar para obter mais informações.
O dispositivo móvel deve estar conectado ao computador. Isso permite que você execute o seguinte comando no console para exibir apenas logs de erro criptografados e salvá-los em um arquivo contendo apenas logs criptografados e públicos:
O comando acima limpará qualquer buffer ADB, evitando que logs de testes anteriores sejam incluídos. Agora, prossiga com seu teste normalmente até que o erro desejado ocorra.
Uma vez que o erro desejado tenha sido acionado, você pode habilitar o modo desenvolvedor novamente para continuar a coleta de logs. Com o modo desenvolvedor reativado, siga os próximos comandos como se estivesse no ambiente de homologação (Seção 5.1: Coletando Logs com o SDK de Homologação).
O comando irá gerar um arquivo chamado logs.txt na pasta especificada pelo caminho no console.
O próximo passo é repetir a operação, coletando todos os erros e gerando um segundo arquivo contendo o conjunto completo de erros da aplicação durante o processo.
O comando irá gerar um arquivo chamado logs2.txt na pasta especificada pelo caminho no console.
A diferença entre os dois logs permitirá uma análise mais precisa, separando o contexto do SDK Tap to Phone dos logs públicos e logs da aplicação.
É importante realizar esta tarefa em produção rapidamente, pois o buffer de log pode ser sobrescrito, potencialmente perdendo os dados de teste que acabaram de ser registrados.
Analise ambos os arquivos, e se nenhum erro público coberto por este documento tiver um procedimento de resolução efetivo (consulte a Seção 6: Instruções para Liberação do App para Produção), prossiga com a abertura de um ticket com o First Tech, incluindo estes dois arquivos de log.
Atualizado