[android-developers] Re: 1.6: GPS location provider stop unexpectedly (exceeded MIN_FIX_COUNT), bouncing back and forth
I've tested the scenario where a service crosses paths with an app, i.e. both request location provider updates following different levels of location provider availability, as requested by zero and non-zero values of minTime. The mapping of location provider requests appears such that the process with the highest level of GPS receiver availability trumps everything else, for the benefit of the process that operates with minTime values0. In other words, a foreground app receives and keeps at a mimimum the location provider settings it requested. Or a better level yet, if the service keeps the location provider running (through minTime=0). This aspect looks clean after all, good. On Oct 24, 10:10 am, JP joachim.pfeif...@gmail.com wrote: Intentionally, sure. But this is a *side effect*. On Oct 24, 9:41 am, Christine christine.kar...@gmail.com wrote: You can choke the foreground app anyway, if you want to. But you don't - I guess. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: 1.6: GPS location provider stop unexpectedly (exceeded MIN_FIX_COUNT), bouncing back and forth
multiple listeners for a location provider with different minTime intervals - which value should be used Looks like the current implementation uses the shortest value for that situation: http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=services/java/com/android/server/LocationManagerService.java;h=3f268c933f14fabc0950657b43d7e4df1e463cf8;hb=63abad7ed389aea8eef75786d3628cfb288988dd#l806 Seems like an OK decision there from some quick tests. I called requestLocationUpdates for two listeners. One with a power conserving hint argument of 30 seconds. The other with 60 seconds. Both listeners got the same update frequency. In number of seconds between onLocationChanged calls: 1, 1, 2, 1, 2, 1, 2, 1, 2, 1, 39, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 37, ... Corresponding to occasional ~30 second shutdowns. Once I called removeUpdates for the listener that was registered for 30 seconds, then the listener registered for 60 seconds started getting what it would normally get: 2, 1, 69, 1, 1, 3, 1, 2, 1, 2, 1, 2, 1, 70, 1, 1, 2, 1, 2, 1, 2, 1, ... ~60 second shutdowns. End result, the listener that was registered saying it is OK with ~60 second shutdowns never actually has to wait that long if there is another listener registered that wants more frequent updates. Meanwhile the one that wants the most frequent updates gets what it normally would. On Oct 23, 10:30 am, JP joachim.pfeif...@gmail.com wrote: (Refers to the logs) This occurs every 3s, although minTime is much higher, just as you've found. I will venture to say that this is harder on the battery than to just let GPS stand. BTW, resting a location provider this way is also mis-spec'ed. If an app registers multiple listeners for a location provider with different minTime intervals - which value should be used to control the location provider? It certainly isn't in line with 1.5 behavior, or with anything I've seen on any device. I suppose I can't be sold on this being a feature, not a bug. On Oct 22, 11:40 pm, Lance Nanek lna...@gmail.com wrote: Is this behavior hurting an app you use/wrote in some way? It seems within spec. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: 1.6: GPS location provider stop unexpectedly (exceeded MIN_FIX_COUNT), bouncing back and forth
Hmm, ok thanks - which value should be used was intended as a rhetoric question, pointing out that in it's current form, this feature is not usable. It has the potential to cause non-deterministic behavior when the different values of minTime are set as result to (asynchronous) events. By mapping multiple objects (listeners) with different attribute values to a single one (location provider), you never know what you will get. The real kicker (as far as I can see, I haven't tried this out): Now you can build an app that interferes with other apps running at the same time. Say, your app has a service running in the background that calls .requestLocationUpdates() with a minTime value that's different from an app running in the foreground. In the extreme, you can choke off the foreground app's location provider, no? On Oct 24, 2:00 am, Lance Nanek lna...@gmail.com wrote: multiple listeners for a location provider with different minTime intervals - which value should be used Looks like the current implementation uses the shortest value for that situation:http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;... Seems like an OK decision there from some quick tests. I called requestLocationUpdates for two listeners. One with a power conserving hint argument of 30 seconds. The other with 60 seconds. Both listeners got the same update frequency. In number of seconds between onLocationChanged calls: 1, 1, 2, 1, 2, 1, 2, 1, 2, 1, 39, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 37, ... Corresponding to occasional ~30 second shutdowns. Once I called removeUpdates for the listener that was registered for 30 seconds, then the listener registered for 60 seconds started getting what it would normally get: 2, 1, 69, 1, 1, 3, 1, 2, 1, 2, 1, 2, 1, 70, 1, 1, 2, 1, 2, 1, 2, 1, ... ~60 second shutdowns. End result, the listener that was registered saying it is OK with ~60 second shutdowns never actually has to wait that long if there is another listener registered that wants more frequent updates. Meanwhile the one that wants the most frequent updates gets what it normally would. On Oct 23, 10:30 am, JP joachim.pfeif...@gmail.com wrote: (Refers to the logs) This occurs every 3s, although minTime is much higher, just as you've found. I will venture to say that this is harder on the battery than to just let GPS stand. BTW, resting a location provider this way is also mis-spec'ed. If an app registers multiple listeners for a location provider with different minTime intervals - which value should be used to control the location provider? It certainly isn't in line with 1.5 behavior, or with anything I've seen on any device. I suppose I can't be sold on this being a feature, not a bug. On Oct 22, 11:40 pm, Lance Nanek lna...@gmail.com wrote: Is this behavior hurting an app you use/wrote in some way? It seems within spec. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: 1.6: GPS location provider stop unexpectedly (exceeded MIN_FIX_COUNT), bouncing back and forth
On Oct 24, 6:11 pm, JP joachim.pfeif...@gmail.com wrote: By mapping multiple objects (listeners) with different attribute values to a single one (location provider), you never know what you will get. The documentation says that you can't be sure what you'll get. You will probably get location updates at least as often as specified by the time parameter, but there's no guarantee. Maybe you'll get the updates more often than you specified because some other app needs them more often? I don't know. In the extreme, you can choke off the foreground app's location provider, no? You can choke the foreground app anyway, if you want to. But you don't - I guess. On Oct 24, 2:00 am, Lance Nanek lna...@gmail.com wrote: multiple listeners for a location provider with different minTime intervals - which value should be used Looks like the current implementation uses the shortest value for that situation:http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;... Seems like an OK decision there from some quick tests. I called requestLocationUpdates for two listeners. One with a power conserving hint argument of 30 seconds. The other with 60 seconds. Both listeners got the same update frequency. In number of seconds between onLocationChanged calls: 1, 1, 2, 1, 2, 1, 2, 1, 2, 1, 39, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 37, ... Corresponding to occasional ~30 second shutdowns. Once I called removeUpdates for the listener that was registered for 30 seconds, then the listener registered for 60 seconds started getting what it would normally get: 2, 1, 69, 1, 1, 3, 1, 2, 1, 2, 1, 2, 1, 70, 1, 1, 2, 1, 2, 1, 2, 1, ... ~60 second shutdowns. End result, the listener that was registered saying it is OK with ~60 second shutdowns never actually has to wait that long if there is another listener registered that wants more frequent updates. Meanwhile the one that wants the most frequent updates gets what it normally would. On Oct 23, 10:30 am, JP joachim.pfeif...@gmail.com wrote: (Refers to the logs) This occurs every 3s, although minTime is much higher, just as you've found. I will venture to say that this is harder on the battery than to just let GPS stand. BTW, resting a location provider this way is also mis-spec'ed. If an app registers multiple listeners for a location provider with different minTime intervals - which value should be used to control the location provider? It certainly isn't in line with 1.5 behavior, or with anything I've seen on any device. I suppose I can't be sold on this being a feature, not a bug. On Oct 22, 11:40 pm, Lance Nanek lna...@gmail.com wrote: Is this behavior hurting an app you use/wrote in some way? It seems within spec. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: 1.6: GPS location provider stop unexpectedly (exceeded MIN_FIX_COUNT), bouncing back and forth
Intentionally, sure. But this is a *side effect*. On Oct 24, 9:41 am, Christine christine.kar...@gmail.com wrote: You can choke the foreground app anyway, if you want to. But you don't - I guess. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: 1.6: GPS location provider stop unexpectedly (exceeded MIN_FIX_COUNT), bouncing back and forth
non-deterministic behavior when the different values of minTime are set as result to (asynchronous) events The requestLocationUpdates methods use a synchronized block to avoid that potential problem: http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=services/java/com/android/server/LocationManagerService.java;h=3f268c933f14fabc0950657b43d7e4df1e463cf8;hb=63abad7ed389aea8eef75786d3628cfb288988dd#l933 Synchronized blocks aren't guaranteed to be fair, however. I suppose a malicious app could try to register repeatedly in an attempt to starve other threads trying to get into the synchronized block. On Oct 24, 12:11 pm, JP joachim.pfeif...@gmail.com wrote: Hmm, ok thanks - which value should be used was intended as a rhetoric question, pointing out that in it's current form, this feature is not usable. It has the potential to cause non-deterministic behavior when the different values of minTime are set as result to (asynchronous) events. By mapping multiple objects (listeners) with different attribute values to a single one (location provider), you never know what you will get. The real kicker (as far as I can see, I haven't tried this out): Now you can build an app that interferes with other apps running at the same time. Say, your app has a service running in the background that calls .requestLocationUpdates() with a minTime value that's different from an app running in the foreground. In the extreme, you can choke off the foreground app's location provider, no? On Oct 24, 2:00 am, Lance Nanek lna...@gmail.com wrote: multiple listeners for a location provider with different minTime intervals - which value should be used Looks like the current implementation uses the shortest value for that situation:http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;... Seems like an OK decision there from some quick tests. I called requestLocationUpdates for two listeners. One with a power conserving hint argument of 30 seconds. The other with 60 seconds. Both listeners got the same update frequency. In number of seconds between onLocationChanged calls: 1, 1, 2, 1, 2, 1, 2, 1, 2, 1, 39, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 37, ... Corresponding to occasional ~30 second shutdowns. Once I called removeUpdates for the listener that was registered for 30 seconds, then the listener registered for 60 seconds started getting what it would normally get: 2, 1, 69, 1, 1, 3, 1, 2, 1, 2, 1, 2, 1, 70, 1, 1, 2, 1, 2, 1, 2, 1, ... ~60 second shutdowns. End result, the listener that was registered saying it is OK with ~60 second shutdowns never actually has to wait that long if there is another listener registered that wants more frequent updates. Meanwhile the one that wants the most frequent updates gets what it normally would. On Oct 23, 10:30 am, JP joachim.pfeif...@gmail.com wrote: (Refers to the logs) This occurs every 3s, although minTime is much higher, just as you've found. I will venture to say that this is harder on the battery than to just let GPS stand. BTW, resting a location provider this way is also mis-spec'ed. If an app registers multiple listeners for a location provider with different minTime intervals - which value should be used to control the location provider? It certainly isn't in line with 1.5 behavior, or with anything I've seen on any device. I suppose I can't be sold on this being a feature, not a bug. On Oct 22, 11:40 pm, Lance Nanek lna...@gmail.com wrote: Is this behavior hurting an app you use/wrote in some way? It seems within spec. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: 1.6: GPS location provider stop unexpectedly (exceeded MIN_FIX_COUNT), bouncing back and forth
The docs do mention: If minTime is greater than 0, the LocationManager could potentially rest for minTime milliseconds between location updates to conserve power. http://developer.android.com/intl/fr/reference/android/location/LocationManager.html#requestLocationUpdates%28java.lang.String,%20long,%20float,%20android.location.LocationListener%29 So isn't it just stopping occasionally to save power like the docs say it can? Looking at the code where it stops, it sets an alarm to start sending updates again based on the requested time between updates. Doing a few tests on my G1, the time it stays stopped does seem a little off. If I request 30 seconds minimum time between updates then the time between updates when it turns off is usually around 37 seconds. If I request 5 then I get around 7. If I request 2 then I get 3. Maybe the stopped time should be tweaked down a few seconds. Could be I'm in a bad spot for GPS or something, though, and it is taking longer to start back up than it would otherwise. The docs do mention: the minimum time interval for notifications, in milliseconds. This field is only used as a hint to conserve power, and actual time between location updates may be greater or lesser than this value. So I can't really complain about it being a few seconds off, though, or about how the updates come much faster when the implementation decides not to stop to save power in between sending them. Is this behavior hurting an app you use/wrote in some way? It seems within spec. On Oct 22, 11:30 pm, JP joachim.pfeif...@gmail.com wrote: Root cause identified. Pretty obvious bug in Android 1.6, GpsLocationProvider.java. Source here:http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;... I've reported the bug here:http://code.google.com/p/android/issues/detail?id=4336 Symptoms: Described above. To reproduce problem: Register a GPS location provider and set the min time interval to greater than 1. A overrun as shown in the log trace above occurs after a few second. GPS location provider then hibernates (which resets the counter) just to overrun on the next cycle. *** This affects everyone who relies on LocationListener callbacks to onLocationChanged(), based on time intervals. *** Code review: When the GPS location provider reports a location update, the mFixCount counter is incremented, but never reset except when the location provider is hibernated as a result of the counter overrun. Look for mFixCount in the source file and it's pretty apparent. On Oct 21, 10:08 pm, JP joachim.pfeif...@gmail.com wrote: Looks like I've run into some breakage from 1.5 to 1.6 after all... I am registering location listeners with LocationManager.requestLocationUpdates() With GPS as location provider, I run into a problem with navigation stopping by itself after a few seconds, just to return, stop again, in an endless cycle. I haven't seen this prior to 1.6 Donut and I have no clue what might cause this problem. Here's the Logcat output: 10-21 21:53:09.147: DEBUG/libgps(74): PDSM_PD_EVENT_GPS_BEGIN 10-21 21:53:11.177: DEBUG/GpsLocationProvider(74): exceeded MIN_FIX_COUNT 10-21 21:53:11.177: DEBUG/GpsLocationProvider(74): stopNavigating 10-21 21:53:11.177: DEBUG/libgps(74): qct_gps_stop 10-21 21:53:11.187: DEBUG/libgps(74): PDSM_PD_EVENT_END 10-21 21:53:11.187: DEBUG/GpsLocationProvider(74): Releasing wakelock 10-21 21:53:13.097: DEBUG/dalvikvm(74): GC freed 2562 objects / 104912 bytes in 223ms 10-21 21:53:20.227: DEBUG/dalvikvm(74): GC freed 1345 objects / 51352 bytes in 236ms 10-21 21:53:21.180: DEBUG/GpsLocationProvider(74): ALARM_WAKEUP 10-21 21:53:21.187: DEBUG/GpsLocationProvider(74): startNavigating 10-21 21:53:21.187: DEBUG/libgps(74): qct_gps_set_position_mode = 1, fix_frequency = 10 10-21 21:53:21.187: DEBUG/libgps(74): qct_gps_start 10-21 21:53:21.207: DEBUG/GpsLocationProvider(74): Acquiring wakelock 10-21 21:53:22.147: DEBUG/libgps(74): PDSM_PD_EVENT_GPS_BEGIN 10-21 21:53:24.167: DEBUG/GpsLocationProvider(74): TTFF: 2978 10-21 21:53:27.287: DEBUG/dalvikvm(74): GC freed 1417 objects / 52512 bytes in 232ms 10-21 21:53:34.397: DEBUG/GpsLocationProvider(74): exceeded MIN_FIX_COUNT 10-21 21:53:34.397: DEBUG/GpsLocationProvider(74): stopNavigating (and so forth) A web research for these logs didn't turn up anything (which is unusual in my experience), so this leads me to post the question here wondering what the root of the problem might be... Thanks in advance! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: 1.6: GPS location provider stop unexpectedly (exceeded MIN_FIX_COUNT), bouncing back and forth
(Refers to the logs) This occurs every 3s, although minTime is much higher, just as you've found. I will venture to say that this is harder on the battery than to just let GPS stand. BTW, resting a location provider this way is also mis-spec'ed. If an app registers multiple listeners for a location provider with different minTime intervals - which value should be used to control the location provider? It certainly isn't in line with 1.5 behavior, or with anything I've seen on any device. I suppose I can't be sold on this being a feature, not a bug. On Oct 22, 11:40 pm, Lance Nanek lna...@gmail.com wrote: Is this behavior hurting an app you use/wrote in some way? It seems within spec. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: 1.6: GPS location provider stop unexpectedly (exceeded MIN_FIX_COUNT), bouncing back and forth
Root cause identified. Pretty obvious bug in Android 1.6, GpsLocationProvider.java. Source here: http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=location/java/com/android/internal/location/GpsLocationProvider.java I've reported the bug here: http://code.google.com/p/android/issues/detail?id=4336 Symptoms: Described above. To reproduce problem: Register a GPS location provider and set the min time interval to greater than 1. A overrun as shown in the log trace above occurs after a few second. GPS location provider then hibernates (which resets the counter) just to overrun on the next cycle. *** This affects everyone who relies on LocationListener callbacks to onLocationChanged(), based on time intervals. *** Code review: When the GPS location provider reports a location update, the mFixCount counter is incremented, but never reset except when the location provider is hibernated as a result of the counter overrun. Look for mFixCount in the source file and it's pretty apparent. On Oct 21, 10:08 pm, JP joachim.pfeif...@gmail.com wrote: Looks like I've run into some breakage from 1.5 to 1.6 after all... I am registering location listeners with LocationManager.requestLocationUpdates() With GPS as location provider, I run into a problem with navigation stopping by itself after a few seconds, just to return, stop again, in an endless cycle. I haven't seen this prior to 1.6 Donut and I have no clue what might cause this problem. Here's the Logcat output: 10-21 21:53:09.147: DEBUG/libgps(74): PDSM_PD_EVENT_GPS_BEGIN 10-21 21:53:11.177: DEBUG/GpsLocationProvider(74): exceeded MIN_FIX_COUNT 10-21 21:53:11.177: DEBUG/GpsLocationProvider(74): stopNavigating 10-21 21:53:11.177: DEBUG/libgps(74): qct_gps_stop 10-21 21:53:11.187: DEBUG/libgps(74): PDSM_PD_EVENT_END 10-21 21:53:11.187: DEBUG/GpsLocationProvider(74): Releasing wakelock 10-21 21:53:13.097: DEBUG/dalvikvm(74): GC freed 2562 objects / 104912 bytes in 223ms 10-21 21:53:20.227: DEBUG/dalvikvm(74): GC freed 1345 objects / 51352 bytes in 236ms 10-21 21:53:21.180: DEBUG/GpsLocationProvider(74): ALARM_WAKEUP 10-21 21:53:21.187: DEBUG/GpsLocationProvider(74): startNavigating 10-21 21:53:21.187: DEBUG/libgps(74): qct_gps_set_position_mode = 1, fix_frequency = 10 10-21 21:53:21.187: DEBUG/libgps(74): qct_gps_start 10-21 21:53:21.207: DEBUG/GpsLocationProvider(74): Acquiring wakelock 10-21 21:53:22.147: DEBUG/libgps(74): PDSM_PD_EVENT_GPS_BEGIN 10-21 21:53:24.167: DEBUG/GpsLocationProvider(74): TTFF: 2978 10-21 21:53:27.287: DEBUG/dalvikvm(74): GC freed 1417 objects / 52512 bytes in 232ms 10-21 21:53:34.397: DEBUG/GpsLocationProvider(74): exceeded MIN_FIX_COUNT 10-21 21:53:34.397: DEBUG/GpsLocationProvider(74): stopNavigating (and so forth) A web research for these logs didn't turn up anything (which is unusual in my experience), so this leads me to post the question here wondering what the root of the problem might be... Thanks in advance! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
