Mission impossible: geolocation on Android without SIRENIA batteries

User: this is not possible, GPS will eat the battery
Junior: it's possible, use Geofences
Senor: there are options better

the picture first in one and then in another direction at the same time with one person "walking" 6 the same phones. But what a different result!

Geolocation is used in a variety of tasks. Take the frequent scenario when themselves are coordinates of the user are uninteresting, but it is extremely important to know when it enters into a certain geographic radius. Range of applications where it is necessary, is very wide — from shopping lists and geo-games, to logistics and security.

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

the
1. Small radius. It is required to determine the occurrence of the user in a fairly small radius of area is 500 metres away.
the
2. a High probability. Necessary strongly nonzero probability that the user does not slip radius. Given that now could be "besprovodnoy" time of the day and he rides in the car, it all becomes quite sad.
the
3. Minimum power consumption. An important point for any application, but worst of all — we develop the app and SDK, which should be integrated into other applications. Other developers trust us, and in case of problems, will be the first they, that their applications will be zaminusovali users or deleted. Therefore, power requirements are highest.

Generally by itself, the scenario, of course, terrible from a technical point of view. Indeed, in most applications, geolocation, or short-term use (a check, to see where we are now, saved to exif the place of photography) and requires little energy use, or expected for the user eats the battery (navigators) and thus causes mentally prepare to go or to stick in charging. Here, as in many cases you will have to hang in the background (if I want the developer of the parent application), and therefore normal recommendations on the use Google location in fact useless.

so, the problem is. But is there a solution?

It should be noted that this material is not about the severed head or just a set of experiences that would not survive actual use, and about the technology that was implemented on the basis of the data obtained and used in the business.

As in the formula "time-cost-resources development" can reduce only two parameters, so we need something pozirovat. Given that 500 meters, in principle, constant, a little "release" down from 1.0 the probability of determining the entry into the radius.


Without a GPS to know when the user will pass the red radius. Really?

Initially, the basic options are essentially a three — box solution from Google using Geofences, use the built-in Android Google Services with its own algorithm or the use of open geo-API again with its own algorithm.
Obviously, all this must be run in conditions similar to combat. And time will still take considerable time costs, at the same time will test some marginal options.

race for survival

1. Google Services Passive mode — only cached calls to the GEO-data from other apps. It can be treatment Network location — Wi-Fi in passive and active mode, monitoring cellular towers, and GPS use.
2. Google Services GPS — the good old GPS devouring
3. Mylnikov Provider implementation using the public APIs for Wi-Fi networks from mylnikov (just want to say a huge thanks for the many advice and useful articles). Uses API running on a database aggregated from multiple geobase on Wi-Fi. Especially interesting in cases when you want to avoid the use of permissi ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION (just enough ACCESS_WIFI_STATE), as it directly uses lists Wi-Fi networks. True for Android 6.0 is already not very important, so to scan networks now also requires ACCESS_COARSE_LOCATION.
5. Google Services Combined mode — a balanced mode of operation of Google Services * Passive mode + forced prompt for Wi-Fi and cell towers, when we see the relevance of the cached data are not satisfactory.
6. i402 — implementation of the Rus 402 Targeting: Google Services Combined mode + adaptive mode frequency test (from 1 minute to 24 hours) depending on the distance of the user from the nearest radius

Calibrate

For testing looking for sets of 7 identical models of phones. All phones are new, without additionally installed software. For a more realistic testing Google Services, Passive mode would be correct, on the contrary, extra software, but it would be unpredictable crosstalk and seriously complicate the testing.
Each cycle of calibration and testing starts with a full charge the phones. All measurements are made at temperatures below +15.
Calibration takes a week, which again allows you to be confident that the batteries of all phones "swung" and came in a stable condition.

the calibration Process is performed in two steps

Stage # 1
1. Settings and software of all instances that are in the same state, phones charged and placed in the same conditions.
2. Waiting 24 hours.
3. Withdrawal data for the residual charge.

Phase # 2
1. Settings and software of all instances that are in the same state, phones charged and placed in the same conditions.
2. In phones with a SIM card of one mobile operator.
3. Waiting 24 hours.
4. Withdrawal data for the residual charge.

Stages No. 1 and No. 2 in total performed in five cycles on all instances.
The results revealed phone with abnormal power consumption, it is taken out of the test limits.

Assistance in working with the devices is the fact that one of the team managers at the time was the experience of participating in and simultaneously odious and immersed in technical details project, where do the crash tests as keypad mobile and smart phones-iPhones. There were made measurements of the efficiency of the program — even at extreme temperatures.

6 apps for 2 days

It's always nice to write something small that immediately begins to live. Prepared 6 builds one of the simplest Android application that uses different collection algorithms geodatabase. Each Assembly includes an implementation of the variant of the algorithm, the start/stop button, full step-by-step logs and health indicator instance and Assembly.
Indicator a short beep once a minute, in fact squeak. Due to test bag, filled with test specimens, continuously making strange noises. Fortunately for our difficult and dangerous time, the sounds of the street and transport is completely jammed for the surrounding continuous squeak of our wards. The squeak helps at the initial stage of debugging, for understanding does not depend on whether the Assembly, and after — to determine whether the village is still a battery in a specific instance and not whether the system put to sleep a particular application. After inclusion of the voracious screen to clarify the situation of testing — a luxury and a huge tip.

All assemblies except #4 and #5, requesting the coordinates every 10 minutes. On the one hand, this is a big assumption, because the radius of 500 meters of the user on the transport can safely cross and for much less time. On the other hand, and how to confirm the future, even checking every 10 minutes will lead to catastrophic power "outcasts" and all hope will be solely on clever algorithms.

Testing dance!

On each instance set has its own build of the test application. One instance in the set included a control group and therefore a placebo. That is, it does not install.
The input data for all instances remain common: a common cellular operator, total route and the General rag-bag of a tester. Rag specially selected to avoid interference on the received signals.

Routes are constructed in various terrains like city areas and outside the city. There are routes for cars, transportation, metro, walking. There is even a route on the terrain that are missing by definition, Wi-Fi and cellular connection at the limit — far from the shores of the surface of lake Ladoga.


In this cycle is the most difficult thing was not to drown during the outbreak of the storm bag tester.

Results?

Carry out field research takes more than two weeks. The output of each algorithm is estimated from the point of view of two parameters:

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

what is accuracy

After each round of testing logs for each instance are uploaded, geo-data is converted and displayed on Google Maps. Based on the standard, ie the real historical route, the examiner manually assesses the deviation from it, marks the rating and also gives the text justification. Expert assessment is checked and confirmed by the second expert.
To calculate the deviation in automatic mode is impossible because of determinirovannogo timer waking up to Android and the subsequent out-of-sync devices, and the complexity of many routes — for example, turn twice to the left for a relatively small for the algorithm period of time or "teleportation with the help of the metro".

Energy EFFICIENCY — the percentage of battery charge of the device after the completion of the cycle test is reduced to a common 10-point scale (the higher the better) from 0 (worst level of charge copy of the set in a loop) to 10 (best level of instances of the set in a loop).

Why to determine the efficiency of not using the Profiler?

distrust him. The power consumption of a specific application displayed in the phone settings or readings of specialized software or otherwise include a set of errors and assumptions. Since we were interested in the raw data, we tried to focus on the basic parameters. Given the complete identity of the instances in the set, no third-party software and pre-calibration, the permissible error is not exceeded, the required measurement accuracy.

Below are the average values of the parameters. Median values are not presented, as due to the repeatability of the tests close to the average.

1. Google Services Passive mode

ACCURACY: 3.4 (4th place)
ENERGIAF.: 4.3 (5th place)

The average precision. Allows you to define the General path of the route. Energy efficiency last, but far from the last participant — GPS (4.3 vs 2.1). The accuracy depends greatly on is smartphone third-party software, or to cache the system almost nothing. If the second — then the system can cache only its own periodic system queries. We remember that the Corporation retains a good every step?
Unfortunately, in most cases, TK's own program can not prescribe "do the calculation on the fact that the phone will stand a lot of different programs and they will often refer to geo-data".

2. Google Services GPS

ACCURACY: 4.6 (2nd place)
ENERGIAF.: 2.1 (6th place)

Predictable shows excellent accuracy (except the metro), but predictably expensive: in all tests showed the worst efficiency.

3. Mylnikov Provider (Wi-Fi only)

ACCURACY: 2.2 (6th place)
ENERGIAF.: 6.2 (3rd place)

Poor accuracy is explained by the presence of routes outside the city, where Wi-Fi networks there. At the same time with the use of API using cell towers can show good accuracy and low power consumption.

4. Google Services Geofences

ACCURACY: 5.0 (1 place)
ENERGIAF.: 6.8 (2nd place)

Stable statistics qualitative detection of fensom a radius of 500 meters. It is necessary to warn that Fench smaller radius testing was conducted. Judging by some of the experiments of foreign colleagues, and most of the documentation on finsh less than 150 can be problems with accuracy and/or greatly increase the power consumption.
But at 500 meters the energy consumption could be lower, given that this is a system function.

5. Google Services Combined mode

ACCURACY: 3.6 (3rd place)
ENERGIAF.: 5.5 (4th place)

Had errors relative to GPS reference but generally stable. Power consumption I would like better.

6. i402

ACCURACY: 3.1 (5th place)
ENERGIAF.: 8.5 (1)

Showed predictable poor approximation in regions away from the location of the radii, as radii from distant areas reduces the frequency of audits — for which he received a low rating. While superior to the competition in efficiency, in 2 prolonged tests (over days) showed savings of more than 5-7% of battery charge from the nearest competitor. At the decision of basic tasks — check the entry in the radius — almost always catches reaching and with sufficient probability of riding.

total

In the first place by the combination of PRECISION/EFFICIENCY, it was Google Services Geofences. But even if they were winners for energy efficiency, but that took second place on the basis of the desired scenario is unacceptable. Out of the box solution will help only for standard scenarios, because in the case of advanced options only you yourself can be aware of the requirements and specifics of your application.
Located on the basis of the peloton participants on energy efficiency far left behind the GPS and provide sufficient accuracy. Please note — one of the participants, in principle, refused doping GPS (Mylnikov Provider), and the other four, not counting the GPS, will use its data only when the smartphone somewhere else, the application will require high-precision coordinate.

GPS?

During tests and testing of different variants of confirmed a simple idea — to define the acceptable accuracy of the location in the city, GPS not needed. Anyway, if we're talking about megacities and if your users are not using the app mostly on vacant lots, remote from residential development.

Try to disable in the phone settings, open GPS and Yandex.Card — they will determine your location accurately enough. Even when you turn off Wi-Fi — only if the settings are not set to scan Wi-Fi networks (since Android 4.3). But most users have it enabled.
Open Google Maps and your location will be determined more precisely. Set yourself some tracker Wi-Fi networks and walk or drive around the city — your smartphone will hook up thousands of Wi-Fi networks.


Asked the commercial Director to put a tracker Wi-Fi networks for the day.

Depending on the quality of the source (Google or the open base) and topography of the city is the accuracy of Wi-Fi is around 30-50 meters. Agree that it is much better than a cell network, which in precision is not more than 300-400 meters.
For most applications, an accuracy of 30-50 meters is sufficient, and therefore to pull all eating GPS is absolutely not necessary. When the results of some long-running tests on the GPS instance has 15% charge, the best the opponents had a 57% charge — feel the difference!

So what's the solution?

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

the
• obtaining the cached calls to the GEO-data from other apps (including GPS data if some other app included)
the
• floating frequency of an explicit request, depending on the distance of the user from the nearest radius

For standard use of the application with built-in SDK contains an implementation i402 and working continuously in the service of biting per day within 5% of the battery.
To implement adaptivity and intelligence had to solve many other interesting problems, such as the fight against "teleportational" metro or the "teleportational" airports (because to predict where you'll be 30 minutes included in the metro more difficult than to do the same for the motorist, plain sandwiched with jam) and, for example, to come up with the multiplier values period of updating of coordinates at rest. And also learn without the help of power hungry sensors determine that there is a man on foot, riding on vehicles or their own cars. But about it — in a separate article.

Article based on information from habrahabr.ru