> For the complete documentation index, see [llms.txt](https://ftcoders.first-tech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ftcoders.first-tech.com/first-tech-ttp-sdk-pt/utilitarios/capturando-erros-na-aplicacao.md).

# 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.

<details>

<summary>Ambiente de Homologação</summary>

* 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.<br>

</details>

<details>

<summary>Ambiente de Produção</summary>

* 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

</details>

### 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

{% code overflow="wrap" %}

```
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.1
```

{% endcode %}

Logs 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:

{% code overflow="wrap" %}

```
2025-01-09 13:37:57.042 19993-19993 TapOnPhoneModule br.com.app E Terminal created error: java.lang.Exception: Terminal creation failed: DEVICE_STATE_FAILURE
```

{% endcode %}

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.

{% code overflow="wrap" %}

```
01-20 13:56:13.429  1724  1814 I NSLocationMonitor: getGPSUsingApps() called
01-20 13:56:13.447  2984 28852 I NSLocationManager_FLP: getGPSUsingApps, NO_FREEZE={5013} / FREEZE={10207}
01-20 13:56:13.861  1559  2237 I bauth_FPBAuthService: pcf : 0x1012, 0 ,1 ,0 ,0 ,0 ,0, 7.0.0.1

```

{% endcode %}

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.&#x20;

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.&#x20;

Não se esqueça de solicitar que o modo desenvolvedor esteja ativado no dispositivo.

<figure><img src="/files/W2VUl2n5V8BO8Pn5qIsI" alt=""><figcaption><p><strong>Figure 17: Console Screen Open in a Sample Android Project</strong></p></figcaption></figure>

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:

```
adb logcat -c
```

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:

```
adb logcat -s TapOnPhoneLogger > logs.txt
```

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.

```
adb logcat > logs2.txt
```

O comando irá gerar um arquivo chamado logs2.txt na pasta especificada pelo caminho no console.&#x20;

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.&#x20;

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.

<figure><img src="/files/5KBnHR92GbNJG60BCgPL" alt=""><figcaption><p><strong>Figure 18: Console Screen Open in a Sample Android Project</strong></p></figcaption></figure>

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:

```
adb logcat -c
```

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).

```
adb logcat -s TapOnPhoneLogger > logs.txt
```

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.

```
adb logcat > logs2.txt
```

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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ftcoders.first-tech.com/first-tech-ttp-sdk-pt/utilitarios/capturando-erros-na-aplicacao.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
