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 <[email protected]> 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 <[email protected]> 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
