Debug Mode

Defined under the namespace Scandit.Datacapture.Core

The Scandit Data Capture SDK can record what it is doing while your application runs: the calls your code makes into the native SDK, how long each one took, mode and view lifecycle, listener registrations, and per-frame events. Use it to investigate an integration problem, and to attach evidence to a support ticket.

Everything described here stays on the device. See Privacy below.

Setup

Two calls are all it takes. Raise the level before you reproduce the problem, then write the log once it has happened:

ScanditLogger.setLevel(LogLevel.Debug);

// reproduce the problem, then:
const path = await ScanditLogger.writeLogs();

LogLevel.Debug is the level to start from. Raise it to LogLevel.Trace to also record the per-frame event callbacks, which a running scanner produces continuously. Every record carries a LogCategory label that says what it is about; the label does not filter anything.

While the level is above Off the SDK stores the records in your application’s private storage, excluded from device backups, so the log is still there after the application restarts. ScanditLogger.writeLogs() resolves with the absolute path of a JSON-lines file holding those records, oldest first, with a one-line header in front. It rejects if no record is stored yet, in which case call ScanditLogger.setLevel() first, if the SDK is not initialized yet, or if the destination cannot be written.

Choosing the file

Without an argument the file is scandit-debug-log.jsonl in the application’s cache directory, and every call replaces the previous one. To keep an export, pass a path:

const path = await ScanditLogger.writeLogs('logs/before-fix.jsonl');

An app can only write inside its own storage, so pass a path under the app container on iOS (Documents, Library or the temporary directory), or under Context.getFilesDir() or Context.getExternalFilesDir() on Android; anywhere else needs the Storage Access Framework or MediaStore on Android 10 and later. A relative path, as above, is resolved against the app’s documents/files directory and works on both platforms. A file already at that path is replaced.

The rejection carries a message saying which condition failed, except on Cordova iOS, where only the error code reaches the caller.

Reading the records

Records go to the platform console as they are produced, and into an in-memory ring buffer holding the most recent 1000 entries. Read the buffer with ScanditLogger.getRecentLogs(), or observe records live with ScanditLogger.subscribe():

const unsubscribe = ScanditLogger.subscribe(record => {
  console.log(ScanditLogger.format(record));
});

Each entry is a LogRecord. ScanditLogger.format() renders one as the same single-line string the SDK writes to the console.

What appears in a record

A record identifies the method or event it describes, where it came from, and how long it took, and it carries the arguments of the call under fields.

Those arguments pass through a fixed redaction floor first, on the native side and before anything is stored. Imagery, license keys, device identifiers and captured-document fields — barcode, MRZ, VIZ, NFC and verification results, names, dates of birth, document numbers — are replaced with [redacted], and parser payloads are redacted wholesale. Redaction is recursive and descends into JSON strings, so a key nested inside a serialized payload is caught too.

The floor is fixed. Error stack traces are never recorded, because they can contain file paths from your own binary.

Privacy

While the level is above Off the SDK writes records to log files in your application’s private storage, which no other app can read. The files keep at most about 10 MB and stay until you call ScanditLogger.clear(), which deletes them. Records are also held in memory in your application process and written to the platform console.
ScanditLogger.writeLogs() copies the stored records into the export file, in the cache directory unless you name a path, where it stays until you delete it or the system clears the cache.
Nothing is transmitted. The SDK does not upload log data to Scandit, and enabling debug mode does not start any reporting.
Call arguments are redacted against a built-in floor covering imagery, license keys, device identifiers and captured-document fields.
Error stack traces are never recorded, because they can contain file paths from your own application binary.

The only way records leave the device is if you export them yourself.