HERE Android SDK Developer's Guide

Development Tips

This section provides tips on building your application using HERE Android SDK.

Upgrading from Older Versions of HERE SDK

HERE Android SDK is now packaged as an Android archive (AAR) file instead of separate JAR, native library, and proguard components. If you are upgrading from an older HERE SDK release, the old components should be cleaned up before integrating the AAR version of HERE SDK. To do so, follow these steps:

  1. Ensure that HERE-sdk.jar file is removed from your project and the compile entry is removed from your build.gradle file. The JAR may be located at app/libs/HERE-sdk.jar and included in your build.gradle file in one of the following ways:
    compile files('libs/HERE-sdk.jar')
    compile fileTree(dir: 'libs', include: ['*.jar'])
    Note that if you were previously using Google GSON library or JTS Topology Suite library with HERE SDK, it is still required to be included separately.
  2. Remove HERE SDK proguard file and the proguard entry specific to HERE SDK from build.gradle file. The file to remove is named proguard-here-sdk.txt, and the entry with the same name should also be removed from proguardFiles property in your build.gradle file. The proguard instructions for newer versions of HERE SDK are now applied automatically and are included in the AAR.

You can find further info on integrating the AAR version of HERE SDK into your app in section Run the Sample Application of the User Guide and associated HERE-sdk/tutorial/BasicMapSolution/app/build.gradle file.

Lapsed Listeners and Garbage Collection

HERE SDK provides a number of listener interfaces such as Map.OnSchemeChangedListener, Map.OnTransformListener, and MapGesture.OnGestureListener. To use these listeners, you are required to implement and create a listener instance, then register it with another object (using a method such as addSchemeChangedListener()) to receive event notifications. Unfortunately, this coding pattern can also lead to lapsed listener problem when available memory is consumed by listener objects that are not explicitly unregistered and not garbage collected.

To mitigate this problem, HERE SDK, in some cases, accepts listener objects in WeakReference containers. This has the advantage of avoiding lapsed listeners but it also means that you must be aware of registered listeners becoming garbage collected. To avoid any unintended issues with this coding pattern, be sure to retain a strong reference to your listener instances (for example, by assigning it to a class variable) if you would like to manage its garbage collection lifecycle. Listener objects are not garbage collected as long as a strong reference exists.

Working with Getters

Classes in HERE SDK return copies of objects in its getters. For example, MapPolyline.getPolyline() does not return the same GeoPolyline instance that was used to construct the MapPolyline object; instead, a copy of the GeoPolyline is returned. Since this returned object is a copy, you cannot dynamically modify the MapPolyline instance by modifying this object. If you would like to make changes to MapPolyline, you must call setGeoPolyline(GeoPolyline) instead.

Map Object Limitations

HERE SDK does not limit the number of map markers, polygons, and polylines that can be added to a map. However, rendering a large number of map objects can cause performance degradation in your application. It is recommended that you use techniques such as viewport clipping to avoid these issues.

Doze and App Standby

If you are using Android 6.0 (API level 23) or above, be aware that Doze and App Standby features may impact your HERE SDK app by disabling network access when the device is unplugged, stationary, and has the screen off for a period of time. While HERE Android SDK has the ability to work offline, you should design your app with these operating system features in mind.

For more information about Doze and App Standby including how to use notifications and whitelisting to ensure your app functions properly, see the Android article, "Optimizing for Doze and App Standby".

Native Libraries and ABI Splits

Your app may encounter an error if it also includes other dependencies that have unsupported ABIs. To get around this issue, enable ABI splits to build for armeabi-v7a, arm64-v8a, or both architectures explicitly by modifying your app build.gradle file:

android {
  splits {
    abi {
      enable true
      include 'armeabi-v7a', 'arm64-v8a' // or choose one of them
      universalApk false

For more information about the splits Gradle block, see Configure multiple APKs for ABIs in the Android Studio User Guide.