For the complete documentation index, see llms.txt. You can also append .md to any page URL to get its markdown version.
Skip to main content
For the complete documentation index, see llms.txt.

For the complete documentation index, see llms.txt

Mobile client diagnostics

Our mobile client diagnostics feature provides you with two different methods to gather diagnostic information from the devices of your end-users.

The table below provides you with a high-level overview of what the methods are and how to use them:

Client debug data

Our client debug data feature enables the Encap server to receive debug information from elements and sensors available on the mobile device, such as disk space and available memory.

It is designed to be enabled during error or support situations where additional data can help in finding the error; it is not intended to be enabled continuously.

About client debug data

  • It is configured in the application configuration and is disabled by default.
  • The data is logged to a separate file on the Encap server.
  • It is possible to enable the feature for Android and iOS devices independently, or for both platforms simultaneously.

Example data

Examples of data that can be logged using this feature include:

  • The amount of disk space available.
  • The amount of memory left on the mobile device, given in megabytes (MB).
  • The process ID of the app performing the operation.
  • The thread ID performing the operation.
  • Whether or not the mobile device is currently in battery-saver/low-power mode.
  • Whether the operation is performed over a Wi-Fi or cellular connection.
  • The timestamp of the request as reported from the mobile device.

How to implement it

1. Configure the application configuration

To enable client debug data, you need to enable it in your application configuration with the following parameter on the Encap server.

2. Configure the logback file

To write the data to the logs, you need to ensure that the logback.xml file is configured correctly.

  • If you are using a new installation of the Encap server, then the default configuration writes all client debug data to logs/clientDebugData.log.
  • If you are upgrading and already have a custom logback.xml file, then you can enable client debug data by updating it with the configuration below:
    Example: Configure logback file for client debug data
    <!-- Client debug data log appender -->
    <appender name="clientDebugData" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>./logs/clientDebugData.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
    <fileNamePattern>./logs/clientDebugData.%i.log.gz</fileNamePattern>
    <minIndex>1</minIndex>
    <maxIndex>10</maxIndex>
    </rollingPolicy>
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
    <maxFileSize>10MB</maxFileSize>
    </triggeringPolicy>
    <encoder>
    <Pattern>%d %X{requestCorrelationId} %m%n</Pattern>
    </encoder>
    </appender>
    <logger name="ClientDebugDataLogger" level="INFO" additivity="false">
    <appender-ref ref="clientDebugData"/>
    </logger>

3. Configure the mobile SDK

The mobile SDK will never send any debug data without it being configured on the Encap server. In addition, each registration on a device can opt out from sending debug data. To do this, the app needs to set the allowDebugData parameter to false in its configuration:

Technical details

Log output

The log output for client debug data is configured in the logback.xml file. This gives an opportunity to add the logs to any appender and adjust the output format to fit into any external log analysis tool.

By default, the data is stored in the clientDebugData.log file in the same folder as the other logs. The appender is set up to roll over after 10 MB and stores the previous log file as a compressed gz file.

Note

The 10 last files are stored.

Log size

Client debug data is logged for each operation:

  • Activation
  • Authentication
  • Recovery

Depending on the number of mobile devices, this can potentially produce many entries. To limit or extend the amount of data stored on the server, you can update the configuration in the logback.xml file.

Log format

Client debug data is stored in the following format:

Example: Client debug data format
date correlationId registrationId clientDebugData

2022-05-18 13:06:31,410 561570bb-d6ab-11ec-8a74-0a2622afb44b 0028211c-6512-4f44-8fd6-6fbb1d0a55d7 {"processId":"24057","threadId":"123","connectionType":"WiFi","applicationState":"active","clientRequestTime":"15:05:20 + 2060","isProtectedDataAvailable":"true","lowPowerMode":"false","isIosAppOnMac":"false","freeDiskSpace":"21,454"}
2022-05-18 13:06:31,622 5637ecdc-d6ab-11ec-8a74-0a2622afb44b 0028211c-6512-4f44-8fd6-6fbb1d0a55d7 {"isIosAppOnMac":"false","connectionType":"WiFi","processId":"24057","threadId":"123","freeDiskSpace":"21,454","applicationState":"active","lowPowerMode":"false","isProtectedDataAvailable":"true","clientRequestTime":"15:05:42 + 4290"}
Note

The correlationId is used to correlate all log entries during a request.

Logged data

If client debug data is enabled, then all available debug information is sent to the Encap server. The list of available attributes varies depending on the mobile platform.

You can see which attributes are returned in the Collected data appendix in our SDK documentation:

Client error reporting

For continuous reporting of unexpected errors occurring on the mobile devices, you can use client error reporting.

It is designed to be enabled continuously so that you can monitor and gather information about unexpected errors, helping you to find the cause of bugs.

About client error reporting

  • It is enabled by default.
  • The data is logged to a separate file on the Encap server.

How to implement it

To write the error reports data to the logs, you need to update the logback.xml file.

  • If you are using a new installation of the Encap server, then the default configuration writes all client error reporting data to logs/clientError.log.
  • If you are upgrading and already have a custom logback.xml file, then you can enable client error reporting data by updating it with the configuration below:
    Example: Configure logback file for client error reporting data
    <!-- Days to keep client error logs before deleting them-->
    <property name="CLIENT_ERROR_LOG_RETAIN_DAYS" value="30"/>

    <!-- Client error reporting data log appender -->
    <appender name="clientError" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>./logs/clientError.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    <!-- daily rollover -->
    <fileNamePattern>./logs/clientError.%d{yyyy-MM-dd}.log</fileNamePattern>
    <maxHistory>${CLIENT_ERROR_LOG_RETAIN_DAYS}</maxHistory>
    </rollingPolicy>
    <encoder>
    <Pattern>%d %X{requestCorrelationId} %m%n</Pattern>
    </encoder>
    </appender>

    <logger name="ClientErrorLogger" level="INFO" additivity="false">
    <appender-ref ref="clientError"/>
    </logger>

Technical details

Log output

The log output for client error reporting is configured in the logback.xml file. This gives an opportunity to add the logs to any appender and adjust the output format to fit into any external log analysis tool.

By default, the data is stored in the clientError.log file in the same folder as the other logs. The appender is set up to roll over daily and stores the logs for the number of days configured in the CLIENT_ERROR_LOG_RETAIN_DAYS property.

Log retention

The number of days to retain the logs is configured by the CLIENT_ERROR_LOG_RETAIN_DAYS property in the logback.xml file. In the example configuration above, this is set to 30 days.