Open GoogleCodeExporter opened 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
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
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
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
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
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
Original issue reported on code.google.com by
mich...@vonglasow.com
on 19 Jan 2014 at 8:42