Developer

Additional features

Remote access

As of the 16.2 release BRIDGE allows devices to be accessed remotely (and controlled) via the TeamViewer QuickSupport app. To setup your fleet you will need to:

  1. Download and add the TeamViewer QuickSupport app from the TeamViewer website to your package-list.
  2. Add the TomTom TeamViewerQSAddon from the download page to a package-list. As of 16.6 release this step is no longer required.
1{
2  "name": "com.teamviewer.quicksupport.addon.tomtom",
3  "path": "TeamViewerQSAddon_tomtom.signed.apk",
4  "version": "4765"
5}

Once installed your user must open the app, send you their id and then allow your request on the device screen.

Connecting to an external camera

TomTom Bridge devices support an external video camera connection - either via the 16pin cable bundle on Bridge Hub or with a dock with external camera support for Bridge Terminal devices.

Applications that want to use an external camera, should use the standard Android Camera API.

Here are some hints for using the external camera in app development:

  1. The external camera is identified as the front facing camera.
  2. The external camera has a constant resolution of 640x480. It does not depend on the actual camera hardware that is used.
  3. The intent sent when the external video becomes available is: 
     "tomtom.intent.action.VIDEO_AVAILABLE"
    and when it becomes unavailable: 
    "tomtom.intent.action.VIDEO_UNAVAILABLE"
  4. Note that when tomtom.intent.action.VIDEO_AVAILABLE is sent, it means that the video dock was just connected and the initialization of the video camera has started. It might take up to 3 seconds to set up the camera. In this case, Camera.open(camId) will throw a RuntimeException. To deal with this situation consider the following piece of code: 
    1  int count = 0
    2  Camera camera = null;
    3  do {
    4      try {
    5          for (int camId = 0; camId < Camera.getNumberOfCameras(); camId++) {
    6              CameraInfo camInfo = new CameraInfo();
    7              Camera.getCameraInfo(camId, camInfo);
    8              if (camInfo.facing == CameraInfo.CAMERA_FACING_FRONT) {
    9                  camera = Camera.open(camId);
    10                  break;
    11              }
    12          }
    13      } catch (RuntimeException ex) {
    14      }
    15      if (camera == null) {
    16          try {
    17              Thread.sleep(100);
    18          } catch (InterruptedException e) {
    19              Log.w(TAG, "Sleep was interrupted.", ie);
    20              break;
    21          }
    22      }
    23  } while ((camera == null) && (count++ < 30));

Android application installer

App installer was developed to allow a quick installation of android applications without using the Software Update mechanism. It is not intended for final configuration of the device.

Note that all the apps installed by the Android application installer will be removed if a user does Personal Data Reset or a factory reset.

To install an android app on the device follow the next steps:

  1. Put an Android app .apk file to the root folder of a micro SD card.
  2. Insert the micro SD card in the TomTom Bridge device.
  3. A dialog will appear on the screen, prompting to install one or more Android Applications from the SD card.
  4. Click 'Install' and the standard android installation dialog will appear.
  5. Follow the steps in the dialog to install the application(s).

If "Unknown sources" is disabled in Security Settings, the user will not be prompted for installation.

Screen Lock feature

This feature is only available on Android 4.3 (17.4 Baggio) or earlier. It will not be supported in Android 6. The Screen Lock feature locks user interaction with the screen.

With the exception of the back, home and volume buttons, when the user touches the screen, they will be informed the reason for screen lock with a full screen notification.

When activated there will be an icon on the system bar informing the user that the screen is locked. The full screen notification will stay on the screen for 3 seconds, unless the user docks/undocks, rotates the device, or touches the screen.

Note that the screen lock will be deactivated once the device is rebooted.

There are a few things to take care of when using this feature. Firstly, you need to be careful you don’t lock the screen and never unlock it, as this will render the device unusable. If you choose to use a custom message then you should take care to keep it short as the full screen notification will only display for 3 seconds and your user needs sufficient time to read it.

Enabling the Screen Lock Feature

To have the screen lock feature enabled on the device, the “screenlock-allowed” package needs to be installed on the device.

This package can be found in the extra-packages.zip on the Releases page.

Activating the Screen Lock feature

The screen lock can be activated or deactivated by sending the following broadcast:

  • am broadcast -a "tomtom.intent.action.SCREEN_LOCK" --ez enabled true This will enable the screen lock and a default string ("Screen locked for safety.") will be displayed in the notification when user touches the locked areas.
  • am broadcast -a "tomtom.intent.action.SCREEN_LOCK" --ez enabled true --es lock_description "Your custom message" This will enable the screen lock and "Your custom message" will be displayed in the notification when user touches the locked areas.
  • am broadcast -a "tomtom.intent.action.SCREEN_LOCK" --ez enabled false This will disable the screen lock, and make the whole screen interactive.

Immersive mode

This section is only relavant for Android 4.3 (17.4 Baggio) and earlier. For Marshmallow please see the Android documentation.

There are two ways to implement immersive mode, the first, and preferred, method is to add an immersive mode flag to the system UI visibility flags in an activity's view, and the second method is to use the policy control feature of android.

System user interface visibility

Immersive mode can also be enabled in any android activity by setting the SYSTEM_UI_FLAG_IMMERSIVE or SYSTEM_UI_FLAG_IMMERSIVE_STICKY flag on the activity view as follows:

1int vis = View.SYSTEM_UI_FLAG_FULLSCREEN
2        | View.SYSTEM_UI_FLAG_HIDE_NAVIGATION
3        | View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY;
4View decorView = getWindow().getDecorView();
5decorView.setSystemUiVisibility(vis);

The immsersive mode flags should be set in both onCreate() and onResume(), this will cause the activity to use the standard android immersive mode features described in the android developer documentation.

The following flags were also added to the TomTom addon:

1tomtom.platform.View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY
2tomtom.platform.View.SYSTEM_UI_FLAG_IMMERSIVE
3tomtom.platform.View.SYSTEM_UI_FLAG_IMMERSIVE_TOTAL

Applications can use either the tomtom.platform flags, or the standard android flags when calling setSystemUiVisibility()

The tomtom.platform.View.SYSTEM_UI_FLAG_IMMERSIVE_TOTAL flag is only available with the TomTom addon, if an application uses this flag then the system bar will never be shown while the application is active.

Policy control

The window policy control can be used to apply runtime adjustments to the global window policy. This includes forcing immersive mode behavior for the system bar (based on a package list) and permanently disabling immersive mode confirmations for specific packages.

Control by setting Settings.Global.POLICY_CONTROL (policy_control) to one or more name-value pairs. e.g.

To force immersive mode everywhere:

settings put global policy_control "immersive.full=*"

To force immersive mode for all apps except a specific package:

settings put global policy_control "immersive.full=apps,-com.package"

To force total immersive mode for all all apps:

settings put global policy_control "immersive.total=*"

To disable the immersive mode confirmations for specific packages:

settings put global policy_control "immersive.preconfirms=com.package.one,com.package.two"

Separate multiple name-value pairs with a colon:

settings put global policy_control "immersive.full=apps:immersive.preconfirms=*"

Disabling access to the notification tray

As of 15.3 Rossi access to the notification tray and its notifications can be disabled so that users cannot open the notification tray or open a notification. To do so a package must be installed and the device must be rebooted. Simply install ro-tomtom-sysbar-expand-disable_1.0_arm.ttpkg from the extra-packages.zip on the Releases page.

Privacy disclaimers

If your application records or collects privacy sensitive information, you should inform the user of this. To keep this clear to the user, we've provided a mechanism to show all these disclaimers in one location: Settings → About your TomTom device → Legal information → Your information. You'll see all apps listed there and tapping them will show you their privacy information.

To list the privacy disclaimer of your application there, you need to add a meta-data element called privacy_disclaimer to the application element of the application's AndroidManifest.xml, defining a reference to a string resource via the android:resource field. For example:

AndroidManifest.xml

1    <application android:name="CustomApp"
2               android:label="@string/application_name"
3               android:icon="@mipmap/ic_launcher_custom_app" >
4

5        <meta-data android:name="privacy_disclaimer"
6                  android:resource="@string/privacy_disclaimer"/>
7        ...
8    </application>

strings.xml

1    ...
2    <string name="privacy_disclaimer"><b>General</b>\nThis is a stylized <i>privacy disclaimer</i>.</string>
3    ...

Wake on SMS

TomTom Bridge can be woken up from sleep by sending an SMS to it. The screen is not turned on by default, but an intent tomtom.intent.action.MODEM_WAKEUP is broadcasted by the system. Upon receiving the intent, applications can decide whether to turn on the display or to do some work and sleep again. The intent tomtom.intent.action.MODEM_WAKEUP is only sent to the current user to prevent multiple instances of the same application from retrieving the intent.

Writing to external SD card

This feature is only available on Android 4.3 (17.4 Baggio) or earlier. For Android 6 please see the Android documentation (getExternalFilesDirs).

By default, applications are allowed only to read from the external SD card. To enable writing to the SD card, the “write_external_media” package needs to be installed on the device.

This package can be found in the extra-packages.zip on the Releases page. The application requires the android.permission.WRITE_EXTERNAL_STORAGE declared in its AndroidManifest.xml to use this feature.

Risks of allowing write access to the external SD card

Use this feature only for testing purposes. Unknown third party applications can write unlimited amount of data and access other applications data on the SD card. They can also leave the data undeleted in the SD card when uninstalled.

If an application relies on the inserted sd card and the user ejects it, there would be unexpected failures. If the user ejects the cards while an application is writing to it, the data could get corrupted.

Ethernet Dongles

This feature is only available in Android 4.3 (17.4 Baggio) or earlier.

When TomTom Bridge is connected to internet via a supported ethernet dongle, the ethernet connection takes priority over all other available connections.

Changing passwords

This feature is only available in Android 4.3 (17.4 Baggio) or earlier.

The DevicePolicyManager.resetPassword() in the standard android API allows programmers to change the current users password. The TomTom addon has a new API that extends this functionality to allow setting and clearing the password for a specified user.

public boolean resetPassword(String password, int flags, int userHandle);
1    try {
2        tomtom.platform.DevicePolicyManager ttdpm = new tomtom.platform.DevicePolicyManager();
3        boolean ret = ttdpm.resetPassword(password, 0, userId);
4    } catch (SecurityException ex) {
5        Log.e(TAG, "Security exception: ", ex);
6    }

See the documentation in the TomTom addon for more details.

Miracast

Screencasting with a Miracast dongle is supported on Bridge Terminal but not Hub at the moment.

Runtime permissions whitelist

From 18.4 Android runtime permissions requests can be configured to be auto-accepted by defining a whitelist. The whitelist comprises a text file which can be configured to always grant specific permissions to specific apps when requested. Please check the distribute section for information on how to include the whitelist in an update configuration. The file is parsed line by line at the time an application requests for runtime permissions. The line is represented by zero or more characters followed by \n, \r, \r\n or the end of the file. The following line formats are supported:

Line formatCommentsLine example
Case sensitive match.com.tomtom.navapp

<package-name>*

Prefix need to match, case senstive.com.tomtom.*
*Any application matches.*

When one of the lines results in a match, the application is considered to be whitelisted. This assumes that the specified permission is present in the manifest of the apk too. The requested runtime permissions are auto-accepted at the moment they would normally be granted when the user allows the related permissions groups.

Please note: Permissions requests are normally grouped and the whole permissions group is granted to the application. The same applies for when the application is whitelisted: All the runtime permissions (which are also requested in the manifest) of the requested permissions are granted to the requesting application. When a line contains an invalid package name, the line is still handled as one of the supported line formats and therefore ignored as it will not match against the package name of any application requesting runtime permissions. The permission is a runtime permission ( protection level = dangerous).

Audio Mute Pin

Audio Mute Pin is supported on Bridge Hub but not on Terminal. The Mute output is intended to mute the connected head unit audio and gets activated when Hub produces audio or when an application requests focus for an unmuted stream. It has typical output voltages of 4V high and 0.4V low. The Mute output is driven low when activated and high when deactivated.