>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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
