The GPS toggle in the system settings is a **PRIVACY** setting. It's just there to allow applications to turn the GPS on or off. Applications are in control of the GPS and can turn it off/on (when it's on you see a GPS icon in the status bar) whenever they want. If an app is keeping the GPS on all the time, it's a problem with the app.
On Fri, May 8, 2009 at 4:09 AM, yacc <yacc...@gmail.com> wrote: > > Sounds a little bit backward. It forces me to manually switch options > on off, loosing my time. It basically forbids me to delegate this to > my app, which is bad. > > There are many valid reasons why apps need to activate GPS, while I > want to keep it off by default, use cases that come immediatly to > mind: > -) DroidTracker. Why should I have my GPS turned on all the time if > it's needed twice an hour? > -) ToogleGPS. Why should I have to go through the Settings app, if > pressing on button on the home screen is enough. Hint: Pressing one > button on the homescreen is way safer and easier than trying to > navigate the settings while driving. > -) Navigation. Why does my nav app forces me to manually enable GPS? > (It suggests visiting Settings.) > -) refining locations. E.g. for many cases where location based > decisions are needed, it might be enough to monitor the GSM/UMTS cell > location, and switch on GPS only when entering interesting cells. > Example would be an app that turns on Wifi only when I near home, > depending where, the cell location might be enough, but in the country > you can have rather big cells. > > Furthermore, why does Android do not provide a fast UI to change all > these settings? > (Guess the fact that there are some dozen settings changing apps from > the simple ToogleGPS to apps that reconfigure the phone based on rules > got lost on the Google guys. Guess satisfying a demand is irrelevant > to them.) > > Guess you could build an even safer and even more consistent user > experience by disallowing any 3rd party apps to be installed? > > If you want to put me into the driver seat with my G1, well, I could > think of a number ideas: > -) allow/disallow net access dynamically. E.g. relevant when data is > getting expensive: E.g. Email might be allowed to work even with data > roaming, all other apps not. > -) allow the user to control how a connection is built, e.g. via > carrier or via Wifi. > -) allow the user to see which network connections/URLs where done by > an app. > -) allow the user to control which network connections/URL fetches are > allowed. > -) warn the user about apps that share permissions. (two apps that > share uid have also a shared set of permissions that is the union of > both). > -) allow the user to see which app uses GPS, Bluetooth, and so on. > > Basically, you are claiming to help the user to have control of the > device, but what if the user wants these changes to happen based on > some rules? > > And while you are closing some theoretical loop hole (e.g. somebody > could track my location), this seems rather stupid: GPS and Bluetooth > that have this "dangerous" connotations both display an icon in the > notification bar. So any clandestine use of it would get noticed > rather fast, even if not by all users, enough users would notice and > raise a stink. OTOH, you have no problem with leaving the user at the > mercy of the developers when it comes to data connectivity. Which is > way more complicated to detect, and if you avoid doing your sinister > plot while on Wifi, very hard to detect. > > (When the BadApp keeps silent while on Wifi, the only "simple" way to > catch it by inspecting the data traffic with a sniffer is gone, ...) > > Andreas > > On 24 Apr., 17:34, Jean-Baptiste Queru <j...@android.com> wrote: >> All right, here's the deal: >> >> One of the reasons that motivated the change is battery life, which is >> a major point of frustration for many Android users. More precisely, >> we've noticed in our testing that there was a strong correlation >> between user complaints about battery life and specific applications >> being installed, and a deeper investigation showed that those apps >> were indeed causing poor battery life by turning hardware on in a way >> that users weren't expecting. Restricting access to those settings >> through an explicit UI was found to be an appropriate mechanism for >> users to known precisely enough what was going on and to get >> appropriate expectations about battery life. >> >> Another reason that motivated the change is an overall concern about >> privacy and abuse. There've been concerns that changing settings like >> GPS, data roaming, wifi, airplane mode without the user's explicit >> action for each operation was inappropriate. >> >> Both of those areas were broadly reported by users, by carriers, and >> in the press. >> >> 1.5 addresses those concerns based on the feedback that we're >> received, by putting the user in better control of their phone. >> >> JBQ >> >> >> >> On Fri, Apr 24, 2009 at 7:19 AM, chrispix <chris......@gmail.com> wrote: >> >> > While I read the blog here >> > :http://android-developers.blogspot.com/2009/04/future-proofing-your-a...248 >> > I almost had a heart attack. Having a location based application, the >> > number one issue we had was being able to automatically turn on / off >> > GPS based on an application setting. Which quite frankly makes some >> > sense. >> >> > Having to prompt the user each time to turn on / off gps is a giant >> > pain from the standpoint of program flow. >> >> > I have used our applications setting to actually turn GPS off, because >> > it was faster to open our app and close the app, and turn off GPS. >> > Rather than opening the settings, and doing it that way. >> >> > I hope you have updated the market so we can respond to all the >> > negative feedback regarding having to manually enable GPS/disable >> > GPS. >> >> > The coding change is not the matter. The fact that a useful function >> > was taken away. Can't there be some way to code GPS state to an >> > application state? >> >> -- >> Jean-Baptiste M. "JBQ" Queru >> Android Engineer, Google. >> >> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning. > > > > -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
