Sorry, you need to enable JavaScript to visit this website.


In some cases you will run into some problems with the TomTom software or your own. You will need to be in contact with your customers and possibly users to determine where the issue is. This page explains the tools available to you to help understand the problem.

Reporting defects to The BRIDGE team

For all defect reports at least the following information should be supplied:

  • A detailed description of the issue, including:
    • The build version from "Settings" -> "About your TomTom device" -> "Build number".
    • The exact time/date the issue occurred(if logs are available).
    • Customer and/or end user impact.
    • Clear reproduce steps.
    • Relevant screenshots or videos.
  • The priority and severity.
  • Logs.
  • Reproducibility. How reproducible is the issue? (e.g. 3 times out of a hundred).
  • Recovery. How can the user or app recover from the situation?

Reproducibility can help determine the priority and severity of an issue. Please remember that some issue may only be reproducible with customer applications installed. Reproduce steps on “stock Bridge software” will help the Bridge team reproduce and fix the issue.

  • Very easy: Can be reproduced at when needed with clear reproduce steps on “stock Bridge software”.
  • Relatively easy: Can be reproduce with clear reproduce steps after a less than 10 attempts on “stock Bridge software”.
  • Hard: Difficult to reproduce with unclear reproduce steps or frequency. Such issues should rarely have Critical priority or severity.

Remote access is possible via the TeamViewer Quick Support app.

Providing logs

In most cases defects can only be understood if logs are sent with a defect report. There are are few ways to do this:

  1. Collect the logs shortly after the issue has been reproduced.
  2. Enable developer options and "take a bug report".
  3. Capture the logs as you reproduce the issue.
  4. Use an SD card to capture logs (especially helpful for issues only reproducible in the field).

To collect the logs after the issue has been reproduce you must dump the logs to the disc and then pull them off the device. After the issue has been reproduced you can dump the logs to disk:

adb shell collectLogs

To collect the logs off the device run:

adb pull /data/logs-.tgz

To take a bug report via developer option you must:

  1. Enable developer options by tapping "Build number" in "About your TomTom device" until the menu is available
  2. Enter Developer options and select "Take a bug report"
  3. Then when adb is available use:
    adb pull /data/data/

To capture the logs as you reproduce the issue use.

adb logcat -v time


  • -b radio for phone and telephony logs.
  • -b system for kernel and android system logs.
  • -b main for all application logs.

Use an SD card to capture logs.

This is available in 16.6 Raphael or later. This can be especially helpful for those less technically inclined. To activate this:

  • Extract the contents of to an SD card. This file is also available for download on the developer downloads page.
  • Insert the SD card into the device.
  • Reboot the device.
  • Once the device boots logging will be enabled and logs will be written to SD card.
  • After the issue has been reproduced you can eject the SD card.

Priority of issues.

When contacting TomTom support it generally helps to understand the priority and the product impact of the issue. Some guidelines will help to set this.

Priority in short is the urgency the Bridge development team needs to place on an issue; the priority that TomTom and the customer together place on a defect. An important issue should be treated as such by both TomTom and customer. In the event no follow up is given by the customer the issue may be deemed to have less priority and downgraded.

  • Critical: Defect must be fixed before the next BRIDGE release. Customer / TomTom are expected to respond within 48 hours for each update.
  • Major: Defect does not block customer’s release but should be fixed at next possible opportunity. Customer / TomTom should respond within 1 week for each update.
  • Minor: Fix is nice to have but does not affect customer’s product much. Customer doesn’t need to respond but is expected to do so if they would like the issue fixed.

Product impact – what impact does the defect have on your product?

  • Safety: Problem has impact on safety of the end user or might create a dangerous situation.
  • Critical: Complete loss of functionality or data. Customer product cannot be shipped with this defect present.
  • Major: Major loss of functionality or data. Customer product can be shipped but has an issue that should be fixed at next opportunity.
  • Minor: Partial loss of functionality or data, incorrect functionality. Defect can be tolerated. Fix is preferred but not required.