Monitoring mobile battery impact with Project Falx
Our mission at Life360 is to build the must have Family Membership that helps protect and connect everyone in the family. Today, we do that by providing features such as car collision detection and place alerts.
To build these magical features we use many different hardware on the phone such as GPS, accelerometer, gyroscope and proximity sensors. The mobile app then uses this data to protect and connect members in your family by communicating with our servers. All of these activities if not managed carefully can impact member’s battery negatively.
Our engineering team ensures we use battery power intelligently so that we do not put too much stress on the device’s battery. We have several processes in place to to ensure our apps use battery power reasonably. However, we wanted to improve in these two areas:
- Ensure battery consumption consistency release over release.
- Investigate issues that negatively impact battery for our users.
Our current processes to address these areas require a lot of manual work and are prone to errors. For example, we run battery tests comparing a release candidate with the previous release. We use Battery Historian to analyze Android bug report logs from both releases. Although this tool gives insightful information, it is time consuming and requires a lot of attention to compare two sets of results.
Another problem is analyzing the cause of battery issues for a specific user. If we need to look at their Android bug report, the devices must have some Developer Settings turned on. Also, these logs need to be collected by acquiring the user’s device.
Origin of the name Falx
Falx is an ancient weapon built to pierce armors and to reach targets around their shield. In our case we needed to get around the OS abstractions to monitor battery impact.
Introducing Project Falx
We felt compelled to invest in tools that help us understand more about battery impact. Moreover, we wanted a tool that can be implemented on both iOS and Android without getting too nitty-gritty with low-level hardware. Since hardware specifications can change frequently, directly measuring hardware effect on battery is not very useful in attributing the measurement with an app. However, from the app we can reliably monitor how we use different APIs that correlate to some function of the device that impacts battery.
How can we collect data about battery usage by our app with very little processing overhead?
We put our heads together and found out we could use a set of proxy metrics that strongly correlate to battery use. A proxy metric is events logged from performing an operation by an app that correlate with power consumed by specific hardware and sensors. We also want to measure these metrics from our app code at runtime.
Our engineering team performed various lab tests and identified the following proxy metrics that we can measure:
Development
The app decides when to start and stop monitoring the proxy metrics. There is a monitor to observe and collect data about each proxy metric, and each of them can be enabled or disabled any time.
Data Collection
Apps using Falx can request data on-demand by calling APIs that return events logged by the enabled monitors. Apps can either request all individual events for the enabled monitor or a result that aggregates argument values for all events for each monitor.
Example data of a single event that logs network activity:
Example of data that shows aggregated results for multiple events of the same type:
(In this example the arguments duration, count and bytesReceived have been aggregated for a time interval)
How we are making use of the data
We have integrated Falx for Android with our Life360 app for a subset of users. Our app has a job scheduled to run every 24 hours that reads aggregated event data from Falx and uploads them in our analytics platform.
Compare latest release with latest beta
Another way we are using the data to analyze results from our battery tests that we perform before each release. The battery tests run for 1–2 days on 2 devices, one running the current production app and the other running beta version of the upcoming release. Once the data is collected by the analytics platform, we can compare results from the logged events and determine if there is any unexpected deviations. In this example network activity looks very close between release and beta builds and gets a thumbs up for this activity.
Deciding whether our battery tests were done right
From the foreground event data we deduced that the beta was in foreground for longer than expected. Our app makes more network calls and triggers more GPS use while in foreground. So, we concluded that the tests were not comparable and decided to re-run the tests.
What’s Next?
Enhance our monitors
Since we got the basics working for several key monitors, our next step is to collect more useful data for the monitors. For example, in the network monitor we are tracking number of calls, and bytes received, but we would like to know which calls use the phone radio vs WiFi. The foreground monitor is now monitoring time in foreground, but can we also log how our layouts and graphics effect battery?
Add more useful monitors
We are thinking about how we can better track battery consumption in the background. We do have logs for network activity, wake locks, GPS use etc, but not how our background services are impacting the battery.
Open Sourcing Falx
We believe his project can be very useful to other app developers, and we could use expertise from a open community. So we decided to release Falx as an open source Project. Falx for Android has been open sourced, and Falx for iOS is coming soon.
Come join us
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.
