> 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/developer-zone/capturing-errors-in-the-application.md).
# Capturing Errors in the Application
Before collecting data, it is important to recall some key characteristics of the SDK's behavior in the staging and production environments, as discussed in sections 3 and 6 of this document.
Staging Environment
* **Errors in the Terminal Creation Step**
* Only the status *'Jailbreak/Root Mode Enabled'* prevents usage.
* **Errors in the Session Creation Step**
* There are no session errors, as internal credentials are not verified.
* **Errors in the Card Reading and Transaction Submission Steps**
* Errors follow the descriptions provided in *Section 6 - Instructions for Deploying the App in Production* of this document and can be captured in the logs as usual. Production Environment
* **Errors in the Terminal Creation Step**
* Permission checks for the device, malicious applications, enabled developer mode, apps installed outside Google Play, and other extensive verifications mentioned in *Section 6 - Instructions for Deploying the App in Production* of this document must be observed.
* **Session Errors**
* Credentials are verified according to the details provided in *Section 6 - Instructions for Deploying the App in Production* of this document.
* **Errors in the Card Reading and Transaction Submission Steps**
* Errors follow the descriptions provided in *Section 6 - Instructions for Deploying the App in Production* of this document and can be captured in the logs as usual.
### Types of logs
**Redactable Log**
These logs appear only in the production environment and are encrypted by the SDK, intended exclusively for interpretation by **First Tech**. They are essential for understanding errors and must always be sent.
Example of a 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 %}
**Public SDK Error Logs**
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:
{% 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 %}
**Application Logs**
Logs created by the application developer to monitor their own business processes and problem indicators. These logs are typically not analyzed by First Tech during inspections.
{% 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 %}
Logs can be extremely extensive; therefore, filtering and organizing them before submitting a ticket significantly accelerates the problem resolution process. For an effective analysis, the collected log should be limited to a maximum of 100 lines and focus exclusively on the transaction that caused the issue, removing any irrelevant records or entries related to other aspects of the application.
***
### **Collecting Logs with the Staging SDK**
Ask the developer to configure the build variants in Android Studio for the staging environment (**hml**) when using our staging SDK. With the project open, access the console window by pressing **Alt + F12**.
If the developer is not familiar with build variants, guide them to refer to **Section 4: Environment Preparation to Get Started** for more information.
Don't forget to request that **developer mode** is enabled on the device.
Figure 17: Console Screen Open in a Sample Android Project
The mobile device must be connected to the computer. This allows you to run the following command in the console to display only encrypted error logs and save them to a file containing only encrypted and public logs:
```
adb logcat -c
```
The command above will clear any ADB buffer, preventing logs from previous tests from being included. Then, proceed with recording the application log using the next command in the console:
```
adb logcat -s TapOnPhoneLogger > logs.txt
```
The command will generate a file named **logs.txt** in the folder specified by the path in the console.
The next step is to repeat the operation, collecting all errors and generating a second file containing the complete set of application errors during the process.
```
adb logcat > logs2.txt
```
The command will generate a file named **logs2.txt** in the folder specified by the path in the console.
The difference between the two logs will allow for a more accurate analysis, separating the **Tap to Phone SDK** context from the **public logs** and **application logs**.
Analyze both files, and if no public error covered by this document has an effective resolution procedure (refer to **Section 6: Instructions for Releasing the App to Production**), proceed with opening a ticket with **First Tech**, including these two log files.
***
### **Collecting Logs with the Production SDK**
The process follows the same steps as described in **Section 5.1: Collecting Logs with the Staging SDK**, but special attention must be given to **turning developer mode off and on** at the correct time.
Ask the developer to configure the build variants in **Android Studio** for the **staging environment (hml)** when using our **staging SDK**. With the project open, access the console window by pressing **Alt + F12**.
If the developer is not familiar with build variants, guide them to refer to **Section 4: Environment Preparation to Get Started** for more information.
Figure 18: Console Screen Open in a Sample Android Project
The mobile device must be connected to the computer. This allows you to run the following command in the console to display only **encrypted error logs** and save them to a file containing only **encrypted and public logs**:
```
adb logcat -c
```
The command above will clear any **ADB buffer**, preventing logs from previous tests from being included. Now, proceed with your test normally until the desired error occurs.
Once the desired error has been triggered, you can **enable developer mode again** to continue log collection. With developer mode reactivated, follow the next commands as if you were in the **staging environment** (**Section 5.1: Collecting Logs with the Staging SDK**).
```
adb logcat -s TapOnPhoneLogger > logs.txt
```
The command will generate a file named **logs.txt** in the folder specified by the path in the console.
The next step is to repeat the operation, collecting all errors and generating a **second file** containing the **complete set of application errors** during the process.
```
adb logcat > logs2.txt
```
The command will generate a file named **logs2.txt** in the folder specified by the path in the console.
The difference between the two logs will allow for a **more accurate analysis**, separating the **Tap to Phone SDK** context from the **public logs** and **application logs**.
It is important to perform this task in **production quickly**, as the log buffer may be overwritten, potentially losing the test data that was just recorded.
Analyze both files, and if no **public error** covered by this document has an effective resolution procedure (refer to **Section 6: Instructions for Releasing the App to Production**), proceed with **opening a ticket with First Tech**, including these two log files.
---
# 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/developer-zone/capturing-errors-in-the-application.md?ask=&goal=
```
`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.