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.
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
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.1Public 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:
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_FAILUREApplication 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.
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
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.
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 -cThe 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.txtThe 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.txtThe 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.
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 -cThe 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.txtThe 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.txtThe 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.
Last updated