Mission: Impossible: geolocation on Android without battery drain

User: this is not possible, GPS will eat battery
Junior: it is possible, use geofences
Senor: there are better options

In the picture, first in one, and then in the other direction, 6 identical phones “walked” simultaneously with one person. But what a different result!

Geolocation is used in a variety of tasks. Take the frequent scenario, when the coordinates of the user are not interesting by themselves, but it is extremely important to know when he enters certain geographic radii. The range of applications where it is needed is very wide - from storelists and geo-games to logistics and security.

In our case, this scenario is complicated by three absolutely mutually exclusive things:

1. Small radius. It is required to determine the fact of the user's occurrence in a rather small area radius - 500 meters.
2. High probability. A strongly nonzero probability is needed that the user will not slip a radius. Considering that now it can be a “no-run” time of day and he drives a car, everything becomes rather sad.
3. Minimum power consumption. An important point for any application, but worst of all - we are developing not an application, but an SDK, which must be embedded in other applications. Other developers trust us, and in case of problems they will suffer first of all, it is their applications that will be mined by users or deleted. Therefore, the requirements for energy consumption are the highest.

In general, the scenario itself is, of course, monstrous from a technical point of view. Indeed, in most applications, geolocation is either used for a short time (check, see where I am now, save the place of photography in exif) and does not require much power, or is expected to be consumed by the user (navigators) and therefore makes you psychologically prepared for this or stick into charging. Here, in many cases, you will have to hang in the background (if the developer of the parent application wants it), and therefore the usual Google recommendations for using the location are essentially useless.

So, there is a problem. But is there a solution?

It is worth noting that this material is not about detached reflections or just a certain set of experiments that would not withstand actual use, but about a technology that was implemented on the basis of the data obtained and used in practice.
')
As in the formula “time-price-development resources”, only two parameters can be reduced, so we should devour something. Considering that 500 meters is basically a constant, let us “let go” a bit down from 1.0, the probability of determining the occurrence in a radius.


Without GPS enabled, find out when the user will pass a red radius. Is it real?

Initially, the basic options are essentially three - a boxed solution from Google using Geofences, using the built-in Google Services Android with its own algorithm, or using an open geo-API again with its own algorithm.
Obviously, you need to run it all in conditions close to combat. And since all the same it will take considerable time, then at the same time we will test some marginal options.

Survival race participants

1. Google Services Passive mode - receiving only cached system calls to GEO-data from other applications. These can be either Network location calls — Wi-Fi in passive and active mode, cell tower monitoring, or GPS use.
2. Google Services GPS - good old all-consuming GPS
3. Mylnikov Provider - implementation using the open API via Wi-Fi networks from mylnikov (I want to immediately thank you so much for the many consultations and helpful articles ). Uses an API that works on a base aggregated from several geobases via Wi-Fi. It is especially interesting in cases when you want to avoid using the ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION permissions (only ACCESS_WIFI_STATE is enough), as it directly uses Wi-Fi network lists. True for Android 6.0, this is no longer very relevant, as for the scan of networks now also requires ACCESS_COARSE_LOCATION.
4. Google Services Geofences - a closed implementation of Google by definition of the user's occurrence in the radius; Allows you to determine the geographical area, when entering into which the application will catch the corresponding event. Of the obvious minuses - allows you to do only 100 radii, which for some tasks may not be enough and will require programming nested (or "breaks") radii. On most devices, it uses only Network location (Wi-Fi + cell towers).
5. Google Services Combined mode - a balanced mode of operation of the Google Services Passive mode + forced querying of coordinates via Wi-Fi and cell phone towers, if we see that we are no longer satisfied with the relevance of the cached data.
6. i402 - implementation of 402 Targeting Rus: Google Services Combined mode + adaptive mode of adjustment of the test frequency (from 1 minute to 24 hours) depending on the distance of the user from the nearest radius

Calibrate

For testing, you need sets of 7 identical phone models. All phones are new, without additionally installed software. For more realistic testing of Google Services Passive mode, it would be right, on the contrary, to install additional software, but this would introduce unpredictable hints and seriously complicate testing.
Each cycle and calibration and testing begins with the full charge of the phones. All measurements are made at a temperature not lower than +15.
Calibration takes a week, which again makes it possible to gain confidence that the batteries of all the phones “swung” and came to a stable state.

The calibration process is performed in two stages.

Stage # 1
1. Settings and software of all copies are given in the same state, the phones are charged and placed in the same conditions.
2. Waiting 24 hours.
3. Removal of data on the residual charge.

Stage 2
1. Settings and software of all copies are given in the same state, the phones are charged and placed in the same conditions.
2. SIM cards of one cellular operator are inserted into all phones.
3. Waiting 24 hours.
4. Removal of data on the residual charge.

Stages №1 and №2 in total were performed in five cycles on all copies.
The results revealed a phone with abnormal power consumption, it is taken out of testing.

Assistance in working with devices is provided by the fact that one of the team leaders at one time had the experience of participating in a project both simultaneously odious and immersed in technical details, where crash tests of both push-button mobiles and smartphones-iPhones were done. Measurements of the energy efficiency of smartphones were done there, albeit at extreme temperatures.

6 applications in 2 days

It is always nice to write something small that immediately begins to live. 6 assemblies of one simple Android application using different geodata collecting algorithms were prepared. Each assembly includes the implementation of a variant of the algorithm, the start / stop buttons, full step-by-step logging, and an indicator of the health of the instance and assembly.
The indicator is a short beep once a minute, essentially a squeak. Because of this, the test bag, filled with test specimens, continuously makes strange sounds. Fortunately for our difficult and dangerous time, the sounds of the street and transport are completely deafening to those around us, the unceasing squeak of our wards. At the same time, the squeak helps well both at the initial stage of debugging to understand whether the assembly is stuck and on subsequent ones - to determine if the battery is still seated in a particular instance and whether the system decided to put a specific application to sleep. After all, the inclusion of a voracious screen to clarify the situation when testing is performed is an inadmissible luxury and a huge tip.

All assemblies, except # 4 and # 5, request coordinates every 10 minutes. On the one hand, this is a big assumption, because a user of transport can easily cross a radius of 500 meters in much less time. On the other hand, and as the future confirms, even checking once every 10 minutes will lead to catastrophic power consumption of the “marginals” and all hope will be solely on smart algorithms.

Testing dance!

On each copy of a set the assembly of the test application is established. One copy in the kit is included in the control group and therefore takes a placebo. That is, nothing is installed on it.

The input data for all instances remain common: the general cellular operator, the general route, the common rag bag of the tester. Rag selected specifically for the absence of possible interference to the received signals.

Routes are built according to different reliefs both in urban areas and outside the city. There are routes on the car, on transport, in the subway, hiking routes. There is even a route on the terrain with, by definition, Wi-Fi and cellular communication at the limit - remote from the shores of the Ladoga Lake.


In this cycle, the most difficult thing was not to drown the tester's bag during the beginning of the storm.

Results?

Field surveys take more than two weeks to complete. The output of each algorithm is evaluated in terms of two parameters:

ACCURACY - expert assessment on a 5-point scale in comparison with the standard (the more the better).

ENERGY EFFICIENCY - the percentage of the device’s battery charge after the testing cycle is completed is reduced to a total 10-point scale (the more the better) from 0 (the worst charge level from the set copies in the cycle) to 10 (the best level from the set copies in the cycle).

Below are the average values ​​of the parameters. Median values ​​are not given, because due to the repeatability of the tests are close to the average.

1. Google Services Passive mode

ACCURACY: 3.4 (4th place)
ENERGOEFF: 4.3 (5th place)

Medium in accuracy. Allows you to determine the overall trajectory of the route. The penultimate one in terms of energy efficiency, but it is far away from the last participant - GPS (4.3 vs. 2.1). Accuracy strongly depends on whether third-party software is on a smartphone, or there is almost nothing to cache the system. If the latter is, then the system can cache only its own periodic system requests. We remember that the corporation of good saves our every step ?
Unfortunately, in most cases it is impossible to register in the TZ of your own program “we are counting on the fact that there will be many different programs on the phone and they will often refer to geodata”.

2. Google Services GPS

ACCURACY: 4.6 (2nd place)
ENERGOEFF: 2.1 (6th place)

It shows predictably excellent accuracy (except for the metro), but is also predictably expensive: in all tests it showed the worst energy efficiency.

3. Mylnikov Provider (Wi-Fi only)

ACCURACY: 2.2 (6th place)
ENERGOEFF: 6.2 (3rd place)

Low accuracy results are explained by the presence of routes outside the city where there is no Wi-Fi network. At the same time using the API on the cell tower can show good accuracy and low power consumption.

4. Google Services Geofences

ACCURACY: 5.0 (1st place)
ENERGOEFF: 6.8 (2nd place)

Stable statistics of qualitative determination of phens with a radius of 500 meters. It should be warned that testing with smaller radius was not carried out. Judging by some experiments of foreign colleagues, and even by the documentation itself, on fens less than 150, problems may arise with accuracy and / or power consumption will increase significantly.
But even at 500 meters, power consumption could have been lower, considering that this is a system function.

5. Google Services Combined mode

ACCURACY: 3.6 (3rd place)
ENERGOEFF: 5.5 (4th place)

There were errors regarding the reference GPS, but in general it is stable. Power consumption would be better.

6. i402

ACCURACY: 3.1 (5th place)
ENERGOEFFF: 8.5 (1st place)

He showed predictably poor approximation in areas far from the radius location, as he reduced the frequency of checks in places far from the radii - for which he received a low rating. At the same time, it surpassed the competitors in energy efficiency, in 2 protracted tests (more than a day) showed savings of more than 5-7% of the battery charge from the nearest competitor. When solving a basic task - checking for entering into a radius - almost always catches those who are coming and with sufficient probability - riding.

Total

In the first place in the combination of ACCURACY / ENERGY EFFICIENCY were still Google Services Geofences. But let them become prize-winners in energy efficiency, but the fact that they took second place based on the required scenario is unacceptable. Solutions out of the box will only help for standard scenarios, because in the case of advanced options, only you yourself can take into account the nuances of the requirements and the specifics of your application.
Next, the base of the participants is located, the energy efficiency far left behind the GPS and ensure sufficient accuracy. Please note that one of the participants, in principle, refused to dope GPS (Mylnikov Provider), and the other four, not counting the GPS itself, will use its data only if some other application on the smartphone requires high-precision coordinates.

GPS, goodbye?

During the tests and testing of various options, a simple idea was confirmed - to determine the acceptable accuracy of the location in the city, GPS is not needed. In any case, if we are talking about a million-plus city and if your users do not use the applications mainly on wastelands, remote from residential areas.

Try disabling the GPS settings in your phone and open Yandex.Maps - they will determine your location fairly accurately. And even with Wi-Fi turned off - only if Wi-Fi networks are not disabled in the settings (appeared since Android 4.3). But for most users it is enabled.
Open Google Maps - and your location will be determined even more accurately. Set yourself some kind of Wi-Fi network tracker and walk or drive around the city - your smartphone will hook thousands of Wi-Fi networks.


They asked the commercial director to set up a Wi-Fi network tracker for a day.

Depending on the quality of the source (Google or open bases) and the relief of the city, the accuracy of Wi-Fi is about 30-50 meters. Agree that this is an order of magnitude better than cellular networks, which have an accuracy of no more than 300-400 meters in a city.
For most applications, an accuracy of 30-50 meters is sufficient, and therefore it is not necessary to tug at all the devouring GPS. When according to the results of some long-term tests on the GPS-copy, 15% of the charge remained, the best opponent had 57% of the charge - feel the difference!

So what's up with the solution?

Specifically for the industrial implementation selected i402 - now it is used in one of the mobile advertising networks of the 3rd generation ( Habr: Ad networks 3.0 ).
i402 is, I recall, a combination of the following:

• receiving cached system calls to GEO-data from other applications (including GPS data, if some other application included it)
• an explicit request for coordinates via Wi-Fi and / or cell phone towers, if the cached data is outdated
• floating frequency of an explicit request, depending on the distance of the user from the nearest radius

With standard use, an application with a built-in SDK containing an i402 implementation and operating continuously in service mode eats up within 5% of the battery charge per day.
To implement adaptability and intelligence, many other interesting tasks had to be solved, such as fighting the “teleportation” metro or “teleportation” airports (after all, predicting where the subway will be in 30 minutes is more difficult than doing the same for a motorist ) and, say, come up with a multiplier of the value of the period of the actualization of coordinates at rest. And also learn how to determine, without the help of voracious sensors, a person is walking, traveling by transport or on his own car. But about this - in a separate article.