Reliability

HyperTrack SDKs work reliably when tracking is disrupted in the life of your users. When building movement-aware applications, it is critical to handle common exceptions that occur when your users are on the move. This doc covers various such scenarios and talks about how our SDK handles them.

What happens when

When What happens
App is in the background SDK seamlessly collects and transmits location and activity data in the background with Always permission from the user.
App is killed or swiped up by user SDK automatically restores connection with server and continues tracking with no movement data lost in case of Android and minimal (up to a minute of) of movement data lost in case of iOS. The movement data loss segment is captured in the Placeline as SDK killed.
App crashes or is force killed by OS SDK automatically restores connection with server and continues tracking. The extent of movement data lost depends on the nature of crash or force stop. Typically, tracking resumes when location or activity manager APIs make a callback to the SDK. The movement data loss segment is captured in the Placeline as SDK killed.
App is force stopped from settings This applies to Android only. Tracking stops. SDK resumes tracking when user relaunches the app. The movement data loss segment is captured in the Placeline as SDK killed.
Location is disabled for all apps SDK sends a health.location.disabled event to the server. Location tracking resumes and SDK sends a health.location.enabled event when location is enabled again. The inactive segment is captured in the Placeline as Location disabled.
App is denied location permission SDK sends a health.location_permission.denied event to the server. Location tracking resumes and SDK sends a health.location_permission.allowed event when location is allowed again. The inactive segment is captured in the Placeline as Location permission denied.
App is denied activity permission This applies to iOS only. SDK sends an health.activity_permission.denied event to the server. Activity tracking resumes and SDK sends a health.activity_permission.allowed event when user allows Motion and Fitness permission for the app again.
Device loses network connection SDK continues tracking offline. Server creates a health.network.disconnected event (currently 30 minutes) after losing connection. SDK sends a health.network.reconnected event to server when connection is established again.
Device is switched to Airplane mode SDK continues tracking offline. Server creates a health.network.disconnected event (currently 30 minutes) after losing connection. SDK sends a health.network.reconnected event when connection is established again.
Device is in low battery mode SDK sends a health.battery.low event to the server. Tracking continues.
Device is switched off or restarted Tracking stops. Server creates a health.network.disconnected event (currently 30 minutes) after losing connection. SDK sends a health.network.reconnected event when tracking resumes. SDK records the duration for which the device was switched off. This data is synced up with the server when connection is established again. The movement data loss segment is captured in the Placeline as Device off.
Device time is changed SDK detects the change in device's time settings and the server uses the delta between the device's local time and the server's current time to synchronize automatically. SDK sends a health.time.changed event to the server. Read more here


[info] Consuming SDK events

The SDK events mentioned here are available on the dashboard and on your server in form of webhooks/slack alerts.


[warning] Impact of device losing network connection

Device losing network has no impact on the SDK apart from the HTTP calls. All HTTP calls will fail in absence of network connection and will NOT be retried by the SDK.


[info] Getting device battery status

The device's latest battery status is displayed on the dashboard along with user details. This data is available as last_battery in the User entity.


[warning] For password protected devices

For password protected devices, the user needs to unlock the device for the SDK to resume tracking.

results matching ""

    No results matching ""