Skip to main content

​
Enabling SDK logging

The Desmo Android SDK includes lightweight logging to help you understand what it’s doing. Logging is controlled by the loggingEnabled flag on DesmoConfig, which defaults to true. When enabled, the SDK prints messages such as:
  • When Desmo.setup succeeds or fails.
  • When sessions start and stop.
  • When HTTP requests are sent and responses are received.
Because DesmoConfig is created internally when you call Desmo.setup, you typically control logging by choosing whether you’re in a debug or release build and, if needed, exposing a small wrapper around setup. Example (simple setup using defaults): 
Desmo.setup(
    context = applicationContext,
    apiKey = "pk_sandbox_XXXXXXXXXXXXXXXX",
    environment = DesmoEnvironment.SANDBOX
    // loggingEnabled defaults to true in DesmoConfig
)
You will see messages like: 
[DesmoSDK] Setup successful pointing to: https://api.getdesmo.io
[DesmoSDK] Starting session for delivery: DELIVERY_123
[DesmoSDK] Session started successfully: SESSION_ID
To turn logging off (for example, in production builds), you can introduce a small wrapper that only calls Desmo.setup when you want logs enabled, or use a future SDK option to control loggingEnabled explicitly once exposed.

​
Where logs appear

Logs are printed using println, so they show up in:
  • Android Studio’s Logcat when you run the app from Android Studio.
  • Device logs collected via your logging/observability pipeline.
During integration, keep logging enabled in sandbox builds so you can verify what the SDK is doing.

​
Debugging common issues

​
1. Desmo.client is null

Symptom:
  • Your code prints "Desmo SDK is not configured" when you try to use Desmo.client.
Checklist:
  • Ensure Desmo.setup is called:
    • Exactly once.
    • Early in the app lifecycle (e.g. in your Application onCreate).
  • Confirm the key starts with pk_ and is not empty.
  • Look for a log like:
[DesmoSDK] Setup failed: ...
If setup fails, fix the key and rebuild.

​
2. Session start fails

Symptom:
  • startSession or startSessionWithDeviceInfo throws an error inside your coroutine.
Checklist:
  • Confirm the publishable key you are using is:
    • Valid and not revoked.
    • Created for the environment you selected (SANDBOX vs LIVE).
  • Confirm the device has network connectivity.
  • Check your backend/logs for more detailed error messages tied to that key.

​
3. Session stop fails

Symptom:
  • stopSession throws an error.
What the SDK does:
  • Flushes telemetry via telemetry.flush() and telemetry.stop() before notifying Desmo’s backend that the session should stop.
  • If the network call fails, it keeps the internal state as recording so you can retry stopSession().
Checklist:
  • Try stopping again once connectivity is restored.
  • Inspect logs for HTTP status codes or network errors.

​
4. No data appears in Desmo

Symptom:
  • startSession / stopSession succeed, but you don’t see sessions/insights in Desmo.
Checklist:
  • Confirm you are using the same environment and tenant as the dashboard you’re looking at.
  • Check for any rate limiting or 4xx/5xx errors in the logs.
  • Share session IDs from your logs with the Desmo team to trace them end-to-end.

​
Integration checklist

Use this as a quick pre-flight check before shipping:
  1. Setup
    • Desmo.setup is called exactly once at app startup.
    • You use a publishable key starting with pk_.
    • The environment (SANDBOX / LIVE) matches the keys you created.
  2. Session lifecycle
    • startSession (or startSessionWithDeviceInfo) is called when a delivery begins.
    • stopSession is called when the delivery completes.
    • Both calls succeed without throwing in your test flows.
  3. Logging
    • Logging is enabled in sandbox builds.
    • You can see Desmo logs in Logcat when starting/stopping sessions.
  4. Backend visibility
    • You can see created sessions in the Desmo dashboard or API using the same environment and tenant.
If any box is unchecked, fix that item before rolling out broadly to drivers.