Orrin Cross
Mar 23, 2018 · 4 min read

Here at Life360 we heavily rely on a device’s location, as well as the context of what they are doing at that location. Knowing what the device is doing at a given location is useful for labeling a user’s activity. This also helps us decide with which parameters to request location updates. In order to do this without overly draining a user’s battery we have used a range of technologies technologies including the FusedLocationProviderApi, GeofencingApi, and ActivityRecognitionApi.

A little while back, Google’s Android Platform team reached out to us asking if we would like to test a new API that they were in the process of beta testing. That API was Activity Recognition’s new Transition API. At the time we were in the process of working on a large overhaul of our client applications so developer time was already tight, however we were eager to see how this API would work within our system. We were simultaneously working on a new framework to manage collecting sensor data which also included the existing ActivityRecognitionApi. This was a perfect fit for us to create a new component to handle Activity Recognition’s new Transition API, and allowed us to easily swap it out with our existing component managing the existing ActivityRecognitionApi.

Early results testing Activity Recognition’s new Transition API

After we had created a new component in our sensor framework to manage Activity Recognition’s new Transition API, it was time to test the results. For the test we checked the new API on 2 devices: Samsung S8 on Android 7.0 and Google Pixel on Android 8.1.0.

The scenario was:
- Factory install on both devices; no other apps running
- Both devices fully charged; battery stats reset
- The Activity Transitions API ran in the background 90% of the time, with both screens turned off. Otherwise, the app was open to observe the latency during actual activity transitions (e.g. Walk to Drive)
- The app was installed and started on both devices, when stationary in the office
- Short walk to the parking garage, then went for a 10 minute test drive
- Arrived back at the office, and left both devices on the desk until leaving for home
- the trip home took around 50 minutes. Both displays were turned off
- Arrived home and left both devices on desk for the rest of the duration
- Tracked enter and exit conditions for the following detected activities: STILL, IN_VEHICLE, & WALKING
- Test took place over 24 hours

After performing the test with the above scenario we observed the following results:

Battery results:
Samsung S8 0% battery attribution (we guessed that the attribution was being tacked onto other preinstalled apps using google play services) , 33% battery discharged (67% remaining)
Google Pixel 7% battery attribution, 20% battery discharged (80% remaining)

Latency results:
-~1 min reporting activity transition from actual transition
- Appears biased towards IN_VEHICLE, as this transition more frequently arrived sooner than WALKING
- IN_VEHICLE was detected quickly when mounted, but had higher latency when in cup holder

Accuracy results:
- Fairly accurate when actual activity transitions occurred
- WALKING was not always detected, particularly when in hand and walking
- No false positives

Final thoughts

Overall, the API worked fairly well. The power usage appears to be better than using the Google Activity Recognition API directly without sacrificing much latency/accuracy. We assume that, under the covers, the Transitions API has an algorithm that uses the minimal amount of wakeup and sensor samples to determine activity transitions. Additionally our venture into using the Activity Recognition’s Transition API was mentioned in Google’s own blog post. We are excited for the future releases of the Activity Recognition’s Transition API which will include things such as differentiating between rail transit and road vehicles, and look forward to finding novel new ways to use it.


Come with with us to learn more about how we use the Activity Recognition Transitions API!

Life360 is creating the largest membership service for families by developing technology that helps managing family life easier and safer. There is so much more to do as we get there and we’re looking for talented people to join the team: check out our jobs page.

Life360 Engineering

Musings of Life360's talented engineers

Thanks to Remon Karim, Josh Wickham, Michael Sullivan, and Nelly Lam

Orrin Cross

Written by

Life360 Engineering

Musings of Life360's talented engineers

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade