saintbyte / openbmap

Automatically exported from code.google.com/p/openbmap
Other
1 stars 1 forks source link

Feature request: automatic tracking in background #57

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
It would be nice if Radiobeacon could be configured to start logging whenever 
another applications is using the GPS and stop when the other app unregisters 
from GPS.

Approach:

- Listen for android.location.GPS_ENABLED_CHANGE and 
android.location.GPS_FIX_CHANGE broadcasts. (These control the GPS icon in the 
notification bar.)
- When a GPS fix is received, start logging, using the *passive* location 
receiver (which will get a copy of all locations delivered to the other app but 
not request any location updates of its own).
- When the other app unregisters (android.location.GPS_ENABLED_CHANGE with 
enabled=false received), stop logging.

This would save me a few steps whenever I use navigation or similar on my phone 
as I wouldn't have to bother staring/stopping Radiobeacon manually.

The only loose end to tie up is if/how the user can switch from tracking in 
background to "dedicated" logging (i.e. logging as it is being done now).

Original issue reported on code.google.com by mich...@vonglasow.com on 19 Jan 2014 at 8:42

GoogleCodeExporter commented 9 years ago
Hey Michael, 

I'll have to think about this idea. While it sounds good at first look, there 
might be some technichal implications.

shtripok suggested another interesting approach 
(http://code.google.com/p/openbmap/issues/detail?id=48). As he suggested, I 
switched to NFC Task Launcher, which now automatically starts scanning when I 
leave my home's wifi. Comes really handy.. Might that be a solution for you too?

Original comment by wish7code on 20 Jan 2014 at 9:06

GoogleCodeExporter commented 9 years ago
That would introduce some other side effects which might be undesirable: Let's 
say I leave my place and take the metro, or have the cell buried in my pocket, 
or go to the office (no WiFi) and leave the phone on my desk for eight hours. 
All of these are scenarios in which I'd be logging, thus draining the battery, 
when I have no GPS reception and logging doesn't make sense.

On the other hand, with the passive location provider we'd be logging only when 
the GPS is active anyway, thus extra battery consumption is minimal (we'd just 
scan for networks in addition to using GPS).

Also, when I'm using navigation it's a sign I'm going somewhere new, which 
might be unmapped territory, whereas most of the time I leave my home WiFi I'm 
going to some place I have mapped long ago, such as work or to the supermarket.

Original comment by mich...@vonglasow.com on 23 Jan 2014 at 12:46

GoogleCodeExporter commented 9 years ago
Just a short conclusion on battery drain: our friends at Mozilla experimented 
with activity detection in addition to scan frequency sampling to reduce power 
consumption: activity detection is a feature on newer android devices, which 
detects whether the cell is not moving at all (switching off the scanning then) 
or reducing the number of scan rate if no (new) wifis are found. 

Nevertheless following their discussion the results seems mixed, so your 
solution might indeed be a better approach..

Original comment by wish7code on 23 Jan 2014 at 9:28

GoogleCodeExporter commented 9 years ago
What would the technical implications of using the passive location provider 
that you mentioned be? Maybe that can be sorted out somehow...

Original comment by mich...@vonglasow.com on 26 Jan 2014 at 12:14

GoogleCodeExporter commented 9 years ago
Radiobeacon's architecture has two main services: the positioning service, 
which receives gps location updates and the logging service, collecting cell 
and wifi infos.

While the positioning service itself is ready for other location providers, 
e.g. the passive provider, I've to sort out, where we neeed to adjust the 
logging service.

We would probably need some code to handle GPS_ENABLED_CHANGE and 
GPS_FIX_CHANGE broadcasts in the logging service also, otherwise the logging 
service would keep running (although this shouldn't be a big issue).

Secondly, is there a way to sort out, whether the provided passive positions 
are actually gps signals? What happens if the other app uses coarse location 
provider (e.g.  network location provider) only?

Original comment by wish7code on 26 Jan 2014 at 11:20

GoogleCodeExporter commented 9 years ago
The first change would be that LocationManager.requestLocationUpdates() would 
specify LocationManager.PASSIVE_PROVIDER instead of 
LocationManager.GPS_PROVIDER as the location provider when logging in the 
background.

The Location class has a getProvider() method which will report the provider 
that generated the location. If the case of the passive provider, this method 
will never return the passive provider, as the passive provider never generates 
a fix but obtains it from another provider. Thus one can easily identify 
GPS-provided locations by calling Location.getProvider() and verifying whether 
the result matches LocationManager.GPS_PROVIDER.

The code to handle GPS_ENABLED_CHANGE would mostly have to start and stop 
logging, in much the same manner as the GUI does. (Whether or not to start 
logging should be configurable by the user). The start command would need to 
make sure the service uses the passive location provider, not the GPS provider.

When background logging is enabled, we need to handle explicit start/stop 
requests in a different manner. Suggestions:
- If the user starts manual logging while logging in the background, this 
should just switch the location provider from passive to GPS. Basically, this 
will ensure we keep getting GPS updates after the other app closes.
- When manual logging is active, ignore any GPS_ENABLED_CHANGE and 
GPS_FIX_CHANGE broadcasts. This because if the user starts manual logging 
without a background log being active (because no other app is using GPS), this 
would trigger a GPS_ENABLED_CHANGE.
- When manual logging is active and the user stops it, re-enable processing of 
the above broadcasts and switch to the passive location provider. Optionally, 
display a message "Will continue logging in background as long as other apps 
are using GPS. Disable background logging (y/n)?" and, if the user choses Yes, 
unregister from all location providers and stop logging.
- When automated logging is active and the user attempts to stop it, display a 
message "Currently logging in background because another app is using GPS. 
Disable background logging (y/n)?". If the user chooses Yes, see above.

With background logging disabled, behavior should be the same as now. Disabling 
background logging in Settings should stop any running background logs. 
Autostarting background logging as soon as it is enabled would be cool but may 
be tricky.

Original comment by mich...@vonglasow.com on 26 Jan 2014 at 3:49