Install SDK on Android

GitHub Android SDK

Add Hypertrack SDK

Add following lines to your applications build.gradle:

// Import the SDK within your repositories block
repositories {
maven {
name 'hypertrack'
url 'https://s3-us-west-2.amazonaws.com/m2.hypertrack.com/'
}
...
}
//Add HyperTrack as a dependency
dependencies {
implementation 'com.hypertrack:hypertrack:5.2.0'
...
}
note

We constantly work on making our SDKs better, so make sure you have the latest version of it. You might take a look of its changelog here.

Set up silent push notifications

Set up silent push notifications to manage on-device tracking using HyperTrack cloud APIs from your server. This requires Firebase push notification. If you do not yet have push notifications enabled, please proceed to setup Firebase Cloud Messaging.

Also you need to add your Firebase API key to your HyperTrack Dashboard Setup Page under Server to Device communication section.

note

Push notifications have delays so if you're looking for more instant channel you can use syncDeviceSettings sdk method to speed up command propagation.

Initialize SDK

Obtain an SDK instance, when you wish to use SDK, by passing your publishable key from the Setup page.

val sdkInstance = HyperTrack.getInstance("your-publishable-key-here")

Also make sure you've requested permissions somewhere in your app. HyperTrack accesses location and activity data, so exact set of permissions depends on an Android version. You may use HyperTrack.requestPermissionsIfNecessary() convenience method to request permissions and make SDK integration simpler.

Identify your devices

HyperTrack uses string device identifiers that could be obtained from the SDK instance

val deviceId = sdkInstance.deviceID

Make sure you've saved this device identifier as it is required when calling HyperTrack Devices and Trips APIs.

Get approved for the background location access

Android 11 requires background location access in order to start tracking when the app is in background. HyperTrack SDK declares all the required permissions in AndroidManifest.xml but you need to make some changes to your app and its description in Play Console in order to pass the Google Play Review.

Play Console description

Open Play Console select your app from list and scroll the left navigation bar all the way to the bottom. Then select App Content item from Policy section and scroll the page down to Sensitive app permissions section, where you need to click Manage to proceed. Manage Permissions Fill in Policy Compliance form, focusing on user facing aspects of your app. E.g. HyperTrack Visits app uses following:

Input TitleSample Content
App purposeAutomate expense payouts and gather delivery sites coordinates
Location accessRequires all the time location permission to collect data of user movement for the purpose of travel expense payouts (main scenario) based on mileage driven. When the shift ends, it is possible to review the total mileage driven and which path segments contributes to the drives total (walks are not accounted in reimbursement). The latter establishes transparency that is required to trust the automation.
Video instructionshttps://youtu.be/zb55wxCYLCc

Show explanation prompt in the app

Google Play Review team requires that your app show an explanation before permission requests. In case of a background location access the propmpt must contain the following words: This app collects location data to ... even when the app is closed or not in use The flow of requesting permissions should consist of two steps: 1. App shows permission explanation prompt, containing the sentense above, and requests ACCESS_FINE_LOCATION permission. 2. Once the previous permission is successfully received, the app should show Adjust Settings prompt and request ACCESS_BACKGROUND_LOCATION permission.



Tracking your device

Once you integrated the SDK into your app, you can start tracking your device.

In order to test and verify your SDK integration, you can use either PlayGround in the Dashboard or call Devices and Trips APIs from your server.

Dashboard

Once your app is running, go to the Dashboard where you can see a list of all your devices and their live location with ongoing activity on the map.

Subscribe to SDK status changes

You can add an SDK state listener to catch events.

You can subscribe to SDK status changes addTrackingListener and handle them in the appropriate methods onError(TrackingError) onTrackingStart() onTrackingStop()

Customize foreground service notification

HyperTrack tracking runs as a separate foreground service, so when it is running, your users will see a persistent notification. By default, it displays your app icon with text {app name} is running but you can customize it anytime after initialization by calling:

sdkInstance.setTrackingNotificationConfig(
ServiceNotificationConfig.Builder()
.setContentTitle("Tap to stop tracking")
.build()
)

Check out other configurable properties in ServiceNotificationConfig reference

Create geotags

Geotag is an optional method to tag an app event in the app user's location timeline. E.g. marking a task as done, visit notes, proof-of-delivery, accepting an assigned job, etc.

Distances between geotags are automatically computed, posted to you over webhooks, displayed in map views, and reported in insights scores.

You may optionally attach expected location to verify that the actual location where action took place matches your expectation. You can use deviation between actual and expected to detect an incorrect address, or incorrect behavior.

val expectedLocation = Location("any").apply {
latitude = 35.0476912
longitude = -90.0260493
}
val result: GeotagResult = sdk.addGeotag(Collections.singletonMap("action", "login"), expectedLocation)
if (result is SuccessWithDeviation) {
Log.d(
TAG, "Action happened at lat=${result.deviceLocation.latitude}," +
" long=${result.deviceLocation.longitude}," +
" in approximately ${result.deviationDistance}"
+ " meters from expected location" + result.deviceLocation
)
} else {
val error = result as Error
Log.w(TAG, "Can't detect deviation distance due to " + error.reason)
}

Every geotag invocation returns current device location, or the reason, why it can't be obtained. If expected location was given, the result will also contain distance in meters, from the expected to actual device location.

Look into documentation for more details.

Resolve tracking blockers

In order for tracking to work reliably, SDK requires the user to grant it certain permissions and enable some features in settings. You can use dedicated SDK API to figure out if all the requirements are met: 

val blockers = HyperTrack.getBlockers()
blockers.forEach { blocker ->
Log.d(TAG, "Blocker $blocker requires user to ${blocker.userActionTitle}")
}

Each blocker has a name, a description, CTA name, and an action that is performed when blocker.resolve() is invoked. E.g. Blocker.LOCATION_SERVICE_DISABLED.resolve() triggers navigation to the dedicated Settings menu. Check out Blockers javadoc for details.

You are all set

You can now run the app and start using HyperTrack. You can see your devices on the dashboard.

SDK integration examples

To learn more about SDK integration examples, you may visit these resources:

Frequently Asked Questions

Please review this guide to get answer to these questions:

What API levels (Android versions) are supported?

Currently we do support all of the Android versions starting from API 21 (Android 5.0 Lollipop).

Why do I have dependencies conflicts?

SDK dependencies graph looks like below:

+--- com.android.volley:volley:1.2.0
+--- com.google.code.gson:gson:2.8.6
+--- org.greenrobot:eventbus:3.1.1
+--- org.jetbrains.kotlinx:kotlinx-coroutines-android:1.4.1
+--- org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1
\--- org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.1
+--- org.jetbrains.kotlin:kotlin-stdlib:1.4.0
\--- org.jetbrains.kotlin:kotlin-stdlib-common:1.4.0
\--- org.jetbrains.kotlin:kotlin-stdlib:1.4.0
+--- androidx.appcompat:appcompat:1.3.0 (*)
+--- androidx.legacy:legacy-support-v4:1.0.0 (*)
+--- com.google.android.gms:play-services-location:18.0.0 // safe to downgrade to 17.1.0
+--- com.google.android.gms:play-services-base:17.5.0
+--- androidx.collection:collection:1.0.0
+--- androidx.core:core:1.2.0
+--- androidx.fragment:fragment:1.0.0
+--- com.google.android.gms:play-services-basement:17.5.0
+--- androidx.collection:collection:1.0.0
+--- androidx.core:core:1.2.0
\--- androidx.fragment:fragment:1.0.0
\--- com.google.android.gms:play-services-tasks:17.2.0
\--- com.google.android.gms:play-services-basement:17.4.0
+--- com.google.android.gms:play-services-basement:17.5.0 (*)
+--- com.google.android.gms:play-services-places-placereport:17.0.0
\--- com.google.android.gms:play-services-basement:17.0.0
\--- com.google.android.gms:play-services-tasks:17.1.0
+--- androidx.annotation:annotation:1.2.0
+--- com.google.firebase:firebase-messaging:22.0.0 // safe to downgrade to 17.0.0
+--- androidx.collection:collection:1.0.0
+--- androidx.core:core:1.0.0
+--- com.google.android.datatransport:transport-api:3.0.0
\--- androidx.annotation:annotation:1.1.0
+--- com.google.android.datatransport:transport-backend-cct:3.0.0
+--- androidx.annotation:annotation:1.1.0
+--- com.google.android.datatransport:transport-api:3.0.0 (*)
+--- com.google.android.datatransport:transport-runtime:3.0.0
+--- androidx.annotation:annotation:1.1.0
+--- com.google.android.datatransport:transport-api:3.0.0 (*)
\--- javax.inject:javax.inject:1
+--- com.google.firebase:firebase-encoders:17.0.0
\--- androidx.annotation:annotation:1.1.0
\--- com.google.firebase:firebase-encoders-json:18.0.0
+--- androidx.annotation:annotation:1.1.0
\--- com.google.firebase:firebase-encoders:17.0.0 (*)
+--- com.google.android.datatransport:transport-runtime:3.0.0 (*)
+--- com.google.android.gms:play-services-basement:17.0.0
+--- com.google.android.gms:play-services-cloud-messaging:16.0.0
+--- com.google.android.gms:play-services-basement:17.0.0
\--- com.google.android.gms:play-services-tasks:17.0.0
+--- com.google.android.gms:play-services-stats:17.0.0
+--- androidx.legacy:legacy-support-core-utils:1.0.0 (*)
\--- com.google.android.gms:play-services-basement:17.0.0
+--- com.google.android.gms:play-services-tasks:17.0.0
+--- com.google.firebase:firebase-common:20.0.0
+--- com.google.android.gms:play-services-basement:17.0.0
+--- com.google.android.gms:play-services-tasks:17.0.0
\--- com.google.firebase:firebase-components:17.0.0
+--- androidx.annotation:annotation:1.1.0
\--- com.google.firebase:firebase-annotations:16.0.0
+--- com.google.firebase:firebase-components:17.0.0 (*)
+--- com.google.firebase:firebase-datatransport:18.0.0
+--- androidx.annotation:annotation:1.1.0
+--- com.google.android.datatransport:transport-api:3.0.0 (*)
+--- com.google.android.datatransport:transport-backend-cct:3.0.0 (*)
+--- com.google.android.datatransport:transport-runtime:3.0.0 (*)
+--- com.google.firebase:firebase-common:20.0.0 (*)
\--- com.google.firebase:firebase-components:17.0.0 (*)
+--- com.google.firebase:firebase-iid-interop:17.1.0
+--- com.google.android.gms:play-services-basement:17.0.0
\--- com.google.android.gms:play-services-tasks:17.0.0
+--- com.google.firebase:firebase-installations:17.0.0
+--- com.google.android.gms:play-services-tasks:17.0.0
+--- com.google.firebase:firebase-common:20.0.0 (*)
+--- com.google.firebase:firebase-components:17.0.0 (*)
\--- com.google.firebase:firebase-installations-interop:17.0.0
+--- com.google.android.gms:play-services-tasks:17.0.0
\--- com.google.firebase:firebase-annotations:16.0.0
+--- com.google.firebase:firebase-installations-interop:17.0.0 (*)
\--- com.google.firebase:firebase-measurement-connector:19.0.0
+--- com.google.android.gms:play-services-basement:17.0.0
\--- com.google.firebase:firebase-annotations:16.0.0
+--- androidx.lifecycle:lifecycle-extensions:2.2.0
+--- androidx.lifecycle:lifecycle-runtime:2.2.0
+--- androidx.arch.core:core-common:2.1.0 (*)
+--- androidx.arch.core:core-runtime:2.1.0 (*)
+--- androidx.fragment:fragment:1.2.0
+--- androidx.lifecycle:lifecycle-common:2.2.0
+--- androidx.lifecycle:lifecycle-livedata:2.2.0 (*)
+--- androidx.lifecycle:lifecycle-process:2.2.0
\--- androidx.lifecycle:lifecycle-runtime:2.2.0
+--- androidx.lifecycle:lifecycle-service:2.2.0
\--- androidx.lifecycle:lifecycle-runtime:2.2.0
\--- androidx.lifecycle:lifecycle-viewmodel:2.2.0
+--- org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.5.0 (*)
\--- com.squareup.okhttp3:okhttp:3.12.12
\--- com.squareup.okio:okio:1.15.0

Common problem here is depending on different versions of com.android.support library components. You need to migrate to Android X to resolve the issue.

Why do I have persistent notification on my app?

HyperTrack SDK by default runs as a foreground service. This is to ensure that the location tracking works reliably even when your app is minimized.

A foreground service is a service that the user is actively aware of and isn't a candidate for the system to kill when it is low on memory.

Android mandates that a foreground service provides a persistent notification in the status bar. This means that the notification cannot be dismissed by the user.

persistent-notification

How do I handle custom ROMs?

Smartphones are getting more and more powerful, but the battery capacity is lagging behind. Device manufacturers are always trying to squeeze some battery saving features into the firmware with each new Android release. Manufactures like Xiaomi, Huawei and OnePlus have their own battery savers that kills the services running in the background.

To avoid OS killing the service, users of your app need to override the automatic battery management and set it manual.

To inform your users and direct them to the right setting page, SDK shows a special promt on requestPermissionsIfNecessary() invocation.

Unfortunately whitelisting can't be performed programmatically. So you need to always rely on user performing particular action.

In that case the only way to achieve service reliability is manual setup. E.g. for Oxygen OS (OnePlus) you need to select Lock menu item from app options button in Recent Apps view:

one-plus-example

Why does HyperTrack notification show even after my app is terminated?

The HyperTrack service runs as a separate component and it is still running when the app that started it is terminated. That is why you can observe that notification. When you tracking is stopped, the notification goes away.

How does tracking work in Doze mode?

Doze mode requires device to be stationary, so before OS starts imposing power management restrictions, exact device location is obtained. When device starts moving, Android leaves Doze mode and works regularly, so no special handling of Doze mode required with respect to location tracking.

What is AAPT: error: attribute android:foregroundServiceType not found?

If build fails with error like AAPT: error: attribute android:foregroundServiceType not found that means that you're targeting your app for Android P or earlier. To fix this update your build tools and set the target platform as Android 10 (target SDK level 30). Although there are other workarounds to fix the build still targeting earlier versions, starting from Android 10 Google imposes additional restrictions on services, that access location data while phone screen is turned off, so the drawback will be tracking gaps on devices that run Android 10 or later.

Why doesn't setting device metadata and name work in SDK?

Devices API or in PlayGround take precedence over SDK methods in setting device name and metadata. If you used either Devices API or PlayGround, these SDK methods setDeviceMetadata and setDeviceName will not modify device metadata and name.

What is device Id that I get from SDK?

Device ID uniquely identifies SDK installation. Make sure that you stored it on your backend as a part of user profile to be able to identify location data. On Android 8 and later it is always the same for the app + publishable Key pair and persists across the installation. On devices, powered by earlier versions, it could change after reinstall, although there are some cases in which we are able to keep it the same. Anyway, users change devices and can use one login for multiple phones, so you need to handle that logic of updating device ids in backend.

What permissions are required for the SDK to work

SDK requires following permissions:

Most of listed above don't considered dangeourous permissinos, so granted automatically on install. They also included in SDK's AndroidManifest.xml that is mergerd into your app manifest during the build so you no action required from your side. Contrary to that, your app should request permissions from two last paragraphs interactively if it targets API 29 or later and only location permissions, if it targets API 28 or earlier. This could be achieved via sdkInstance.requestPermissionsIfNecessary() method invocation that presents required permissions request dialog, if neccessary, or does nothing, if they were already granted. Background location access permission is special since it cannot be requested interactively, so on Android 11 user is navigated to device's Settings menu where he needs to select Always Allow menu item. HyperTrack SDK shows an info snackbar with message like Please, select "Always Allow" option. with can be customized by overriding ht_background_permission_toast_template string resource. Menu item name is taken from OS APIs (so it will be in user's locale), so you need to leave a template placeholder instead of it like Please, select "%" option..

Since background location permission complicates Google Play Store review process it is recommended to remove it from the manifest if you don't use platfrom based tracking start in your application, using following tag in your AndroidManifest.xml:

<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" tools:node="remove" />

Why in the dashboard I can see sdk killed by user outage reason?

SDK killed also can be a result of some kind of battery saving settings. Unfortunately it's a way too fragmented across the manufacturers, so we can't provide you with exact steps that the user should take to whitelist the app. But in any case users are able to find the exact technique for their brand either on dedicated resources, like https://dontkillmyapp.com/ or phone manufacturer forums.

You may benefit from checking this also.

Can I test functionality without actual movement?

Although HyperTrack SDK ignores mocked locations by default, there are two ways to test its functionality.

The first one is to use standard emulator, that comes with Android Studio. Check the official manual on how to use it. All the emulators have (Emulator) suffix appended to the device-hardware field, so they can be easily identified, if you need it to distinguish between them and real devices.

Another options is to use one of so called Mock Location apps on a real device. It requires phone settings adjustment that usually explained by those apps. To make HyperTrack accept locations from those apps, you also need to pass a special flag, like shown in the snippet below:

val sdkInstance = HyperTrack.getInstance(publishableKey).allowMockLocations()
caution

Make sure the mock data, you feeding to the SDK, looks real. Instant teleport from Delhi to New York doesn't make sense, so those values will be ignored by processing logic, that is present on HyperTrack platform. Make sure you set desired start location before turning the traking on.

My build fails after adding HyperTrack sdk

Due to the bug in google services gradle plugin your build can start failing after adding HyperTrack sdk with error like a resolved Google Play services library dependency depends on another at an exact version but isn't being resolved to that version. To fix the error we recommend that you either disable version check in the plugin or specified exact dependency version with block like below:

dependencies {
components.all {
allVariants {
withDependencies { deps ->
deps.each { dep ->
if (dep.group == 'com.google.android.gms' && dep.name =='play-services-location') {
dep.version {
prefer "18.0.0"
}
dep.because "resolving dependencies issue"
}
}
}
}
}
..... other dependencies
}