While I read the blog here : http://android-developers.blogspot.com/2009/04/future-proofing-your-a... 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?
Don't forget the fact that it assumes the google devs (or, more likely, the
mysterious and secretive Designers) have the One True Best Way to change
settings.
Want to set profiles in "toggle settings" or other apps (or, say, the
much-vaunted Locale) to do things like turn gps off when you are on a train,
and turn brightness up when you are outside? Yeah, forget that. Lets see
what it takes in 1.1 to turn up the brightness on my phone: Drag down the
notification bar (1 drag), click 'toggle settings' (1 click), click
'brightness' (2 clicks) and select a level (3 clicks). Getting back is as
easy as a single click to 'back'.
Now lets look at the new way. Instead of going to one app that has a list
(or no apps, in the case of locale) you have to open settings (click 1),
scroll down to the bottom (drag), open display (click 2), scroll down to the
bottom (2 drags basically) and click 'brightness' (click three) and then
select the slider position (click 4). then hold home (click five, plus a
long delay) and select the app you were using (click six).
Wow. That sure is convenient when all i want to do is make a phone call in
the sun. The good news is, by the time I do that, make my call, and do it
again to set the brightness back down, its probably nighttime.
(And if I were to set up profiles, I could do all that - plus gps and
ringtones - in 3 clicks. Instead of 10+ to do it in 'settings')
On Fri, Apr 24, 2009 at 10:19 AM, chrispix <chris...@gmail.com> wrote:
> While I read the blog here :
> http://android-developers.blogspot.com/2009/04/future-proofing-your-a... > 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?
chrispix wrote: > Having to prompt the user each time to turn on / off gps is a giant > pain from the standpoint of program flow.
It is rather mystifying that the solution was to disable the APIs rather than add more permissions, or even a system-launched confirmation dialog.
If the goal was to prevent rogue applications from mucking with GPS availability, well, that's fine, but I'd hope there'd be a way to not throw the baby out with the bathwater.
I haven't played with the new 1.5 Settings class yet to be in position to write up an enhancement request on http://b.android.com -- anyone else want to take a crack at that?
On Apr 24, 7:26 am, Disconnect <dc.disconn...@gmail.com> wrote:
> Now lets look at the new way. Instead of going to one app that has a list
> (or no apps, in the case of locale) you have to open settings (click 1),
> scroll down to the bottom (drag), open display (click 2), scroll down to the
> bottom (2 drags basically) and click 'brightness' (click three) and then
> select the slider position (click 4). then hold home (click five, plus a
> long delay) and select the app you were using (click six).
> Wow. That sure is convenient when all i want to do is make a phone call in
> the sun. The good news is, by the time I do that, make my call, and do it
> again to set the brightness back down, its probably nighttime.
It's only half as bad as you guys make it out to be. I agree with
Google's change so that device settings are made in one location only
to emphasize it as a conscious step. You can jump straight into the
relevany settings from an app with the user returning to your app via
the "Back" button. Here's a snippet how I handle this even now in
1.0/1.1 (haven't had the time to try 1.5; I do this on the side),
using an alert dialog to directly jump to the location settings:
class DummyListener implements OnClickListener {
public void onClick(DialogInterface dialog, int whichButton)
{
okToFinishApp = false; // starting Intent sends a stop
to myApp; do not respond if this is just opening the browser or some
else
Intent myIntent = new Intent
(Settings.ACTION_SECURITY_SETTINGS );
startActivity(myIntent);
} ;
};
if (locListener == null)
locListener = new LocListener(this);
bestProvider = locMan.getBestProvider(providerCriteria, true);
if (bestProvider == null) {
AlertDialog noProviderDialog = new
AlertDialog.Builder(this)
.setIcon(R.drawable.menudetour)
.setTitle("Where I am")
.setPositiveButton("Turn on", new DummyListener())
.setMessage("No provider for location tracking
available.\n\nYou must turn on a location provider.") // lazy...
string not transferred to resources yet
.setNeutralButton("Cancel", null)
.create();
Diane H. critizised the override of onStop() (on another occasion) but
this may not necessary when jumping to settings. It is needed however
when opening the browser from within an app, which I do, so I need
this anyway and I just run with it throughout.
>Having to prompt the user each time to turn on / off gps is a giant >pain from the standpoint of program flow.
I'm not sure why you have to prompt each time. You only need to check the GPS state once at startup and then fire the user off to settings if it is not on. They press "back" after that and you're on your way.
> Can't there be some way to code GPS state to an application state?
I'm having a hard time understanding most of your writing, but do you mean doing something like this:
...or are you proposing a manifest entry staying your app only wants to run with GPS on? or?
Sure it is nice to be able to provide an "in application control" but it is not strictly a requirement for operation. This just does not seem to me to be that big a deal. Am I missing something?
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.
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... > 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.
The issue I have with this is, rather than adding permissions that
need to be accepted as part of the manifest, it was disabled.
Our users wanted to have GPS turned on and OFF automatically to
conserve battery life, now when they open the application they will be
prompted to turn GPS on, and when they exit we intend to provide them
with a dialog to do the same, to turn it off. But if every application
is doing this, users are either really going to get fed up turning GPS on and Off or they are going to just leave GPS on, and the battery
will run down.
I can understand the reasoning behind it, but it certainly does not
seem like an elegant solution to make the user manually change the
setting each time, when it was available before for them to just
select an in application setting to automatically enable & disable on
exit.
Thanks,
On Apr 24, 10:34 am, Jean-Baptiste Queru <j...@android.com> wrote:
> 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...
> > 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?
> 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.
If you're worried about an app turning those things on without the
user's permission, why not just detect the application changing the
setting and pop up a quick dialog asking the user if its ok. That way
they wouldn't have to go clicking through menus, it would only add an
extra click to say ok to turning the devices on.
On Apr 24, 9:34 am, Jean-Baptiste Queru <j...@android.com> wrote:
> 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...
> > 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?
> 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.
It seems that a better way would be to have a list of applications allowed to make GPS status changes. So user would be prompted one time to say if he allow or not this application to change GPS status. And to be able to consult and change the list of applications allowed to do so if he wants.
But actual solution seems to be very poor and not very user friendly.
It's already possible for a user to see an app's permissions - though
it'd be nice indeed if the list could be organized the other way
(contributions welcome).
At least anecdotally, though, we've noticed that users (even
sophisticated ones) don't associate poor battery life or control over
some of the core aspects of their phone with permissions (so the point
of how fine-grained the permissions are defined or how verbosely
they're worded is pretty moot): for a certain category of settings,
our anecdotal evidence suggests that users don't expect any
application to be able to change such settings without asking for
permission each time.
JBQ
On Fri, Apr 24, 2009 at 8:52 AM, André Charles Legendre
> It seems that a better way would be to have a list of applications
> allowed to make GPS status changes.
> So user would be prompted one time to say if he allow or not this
> application to change GPS status.
> And to be able to consult and change the list of applications allowed
> to do so if he wants.
> But actual solution seems to be very poor and not very user friendly.
> Regards
> Andre Legendre
-- 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.
> It's already possible for a user to see an app's permissions - though
> it'd be nice indeed if the list could be organized the other way
> (contributions welcome).
> At least anecdotally, though, we've noticed that users (even
> sophisticated ones) don't associate poor battery life or control over
> some of the core aspects of their phone with permissions (so the point
> of how fine-grained the permissions are defined or how verbosely
> they're worded is pretty moot): for a certain category of settings,
> our anecdotal evidence suggests that users don't expect any
> application to be able to change such settings without asking for
> permission each time.
> JBQ
> On Fri, Apr 24, 2009 at 8:52 AM, André Charles Legendre
> > It seems that a better way would be to have a list of applications
> > allowed to make GPS status changes.
> > So user would be prompted one time to say if he allow or not this
> > application to change GPS status.
> > And to be able to consult and change the list of applications allowed
> > to do so if he wants.
> > But actual solution seems to be very poor and not very user friendly.
> 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.
Where was this discussion held? It sounds like quite a few developers and
platform hackers are interested in providing feedback/alternatives.
(And as a later poster said, a popup that says "turn on gps?" is not nearly
as bad as this new method, AND doesn't involve a major regression for apps
written to 1.0/1.1.)
On Fri, Apr 24, 2009 at 11:34 AM, Jean-Baptiste Queru <j...@android.com>wrote:
> 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... > > 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?
> 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.
- Isn't this new scenario going to have a negative impact on battery life
because apps won't be able to turn GPS off when they don't need to use it.
- Isn't the biggest privacy problem at the moment with permission
granularity on Internet access?, There are many apps that want internet
access just to access a donations page, but as a user of, say, an accounts
program, how can I tell that is all the app wants to do and that it isn't
also sending my bank and credit card details somewhere?
======
Funky Android Limited is registered in England & Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK.
The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.
[mailto:android-developers@googlegroups.com] On Behalf Of Jean-Baptiste
Queru
Sent: 24 April 2009 16:35
To: android-developers@googlegroups.com
Subject: [android-developers] Re: Android v. 1.5 = FAIL #2: Directly
Manipulating Settings
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-ap > ps.html 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.
On Fri, Apr 24, 2009 at 9:55 AM, Al Sutton <a...@funkyandroid.com> wrote: > - Isn't the biggest privacy problem at the moment with permission > granularity on Internet access?, There are many apps that want internet > access just to access a donations page, but as a user of, say, an accounts > program, how can I tell that is all the app wants to do and that it isn't > also sending my bank and credit card details somewhere?
I think some people are really missing what the "turn on GPS" setting is. It just is saying that GPS is -allowed- to run. The GPS hardware will only actually be powered up if someone is asking to get data from it. So the vast majority of apps should NEVER be touching this setting -- they should just request location updates when they want them, which will bring up the GPS hardware if it isn't already running (and the user has confirmed that this okay at all with that setting).
Another way to look at this -- the GPS setting is primarily there for privacy, to allow users to determine whether is okay -at all- for anyone to be getting the fine-grained information about where they are.
The built in maps app (with friend finder and everything) never ever touches the GPS setting. The vast majority of other apps should never have been doing this either. Yes, there are a couple ones out there that have some justification for it, but given the significant abuse and bad user experience and press that was happening with these, we (and I was the main person who made sure this happened so blame me) decided to shut that door now and decide how we wanted to support the much smaller subset of reasonable needs in the future.
For example, we should build into the platform a "toggles" widget that allows users directly control these settings on the home screen. We didn't have time to do this in cupcake; if someone wants to work on it, I think we would be happy to accept a good change to the settings app to add this widget in the next release.
Finally, as far as putting up a dialog to confirm with the user -- we don't do this, anywhere in the UI, because experience with other platforms has shown that these kinds of dialogs are more annoying to users than anything else (and they just don't work at all for stuff being done in the background). You also basically get the same thing with the ability to directly launch the location settings panel to have the user turn it on themselves.
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
Dianne, thank you for the response.
The issue is, that if an application uses GPS and it is NOT turned
off, it can drain the battery quite quickly if the app continues to
ping the location. Which is why you disabled this. By saying the user
can just leave the GPS on, and it won't get powered up until data is
requested is still fine. But does not solve the underlying issue of
applications still draining the battery from being poorly written,
will still drain the battery. The issue is that users did not KNOW
that gps was automatically being turned on. So why not fix that issue
rather than break something else, and leave the underlying problem
still there?
Users, no matter how much you tell them, have it in their mind already
that GPS ON means less battery life. No matter what you say. The
question is, how do we handle all the complaints that are unjustified
on the application reviews? There is no way for us to even respond to
the end users based on a poor rating.
On another topic, do you know if anything has been done to improve the
user experience on downloading applications? Some feel that it is the
developer that is trying to scam them, when their downloads freeze on
download, and it just sits there downloading?
What about the settings for WiFi? That does drain your battery, so now
I will be forced to ask users to turn that on/off on startup / exit?
I have a feeling developers are going to be getting a bunch of
complaints, if not - great. But where/who do we forward those to?
Thanks,
On Apr 24, 12:18 pm, Dianne Hackborn <hack...@android.com> wrote:
> On Fri, Apr 24, 2009 at 9:55 AM, Al Sutton <a...@funkyandroid.com> wrote:
> > - Isn't the biggest privacy problem at the moment with permission
> > granularity on Internet access?, There are many apps that want internet
> > access just to access a donations page, but as a user of, say, an accounts
> > program, how can I tell that is all the app wants to do and that it isn't
> > also sending my bank and credit card details somewhere?
> I think some people are really missing what the "turn on GPS" setting is.
> It just is saying that GPS is -allowed- to run. The GPS hardware will only
> actually be powered up if someone is asking to get data from it. So the
> vast majority of apps should NEVER be touching this setting -- they should
> just request location updates when they want them, which will bring up the
> GPS hardware if it isn't already running (and the user has confirmed that
> this okay at all with that setting).
> Another way to look at this -- the GPS setting is primarily there for
> privacy, to allow users to determine whether is okay -at all- for anyone to
> be getting the fine-grained information about where they are.
> The built in maps app (with friend finder and everything) never ever touches
> the GPS setting. The vast majority of other apps should never have been
> doing this either. Yes, there are a couple ones out there that have some
> justification for it, but given the significant abuse and bad user
> experience and press that was happening with these, we (and I was the main
> person who made sure this happened so blame me) decided to shut that door
> now and decide how we wanted to support the much smaller subset of
> reasonable needs in the future.
> For example, we should build into the platform a "toggles" widget that
> allows users directly control these settings on the home screen. We didn't
> have time to do this in cupcake; if someone wants to work on it, I think we
> would be happy to accept a good change to the settings app to add this
> widget in the next release.
> Finally, as far as putting up a dialog to confirm with the user -- we don't
> do this, anywhere in the UI, because experience with other platforms has
> shown that these kinds of dialogs are more annoying to users than anything
> else (and they just don't work at all for stuff being done in the
> background). You also basically get the same thing with the ability to
> directly launch the location settings panel to have the user turn it on
> themselves.
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All such
> questions should be posted on public forums, where I and others can see and
> answer them.
I too think this change is a bad idea and will decrease the user's
experience with my application.
I am surprised that Android's security model asking for permissions
when every application is installed is tollerated while WIndows Vista
basically doing the same thing in a simpler way receives howls of
protest.
Additionally, I don't think the average teenager or grand-mother knows
what any of the fine grain permissions in Android mean and will just
go ahead and allow any app to have the permissions it wants. Being
somewhat knowledgable, I wonder if the app is using the permission for
the stated purpose or does it do more than it says.
On Apr 24, 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...
> 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?
patg wrote: > I am surprised that Android's security model asking for permissions > when every application is installed is tollerated while WIndows Vista > basically doing the same thing in a simpler way receives howls of > protest.
Android's permission model involves an install-time prompt to grant permission. Vista's involves a run-time prompt to grant permission. That is a huge difference for an application that is run more than a couple of times.
> Additionally, I don't think the average teenager or grand-mother knows > what any of the fine grain permissions in Android mean and will just > go ahead and allow any app to have the permissions it wants.
Solve that problem, and you have yourself a very lucrative consulting business.
> ... The GPS hardware will only actually be powered up> if someone is
asking to get data from it.... Another way
> to look at this -- the GPS setting is primarily there for > privacy, to allow users to determine whether is okay -at > all- for anyone to be getting the fine-grained information > about where they are.
So it's really unfortunate that the explanation for the GPS setting reads: "deselect to conserve battery", it gives every user I've discussed it with the impression that enabling the setting will drain their battery faster independently of what applications choose to do. This is enforced the absence of similar indications for other settings.
So, if I understand this all correctly... Those of us who have paid
for an app to toggle settings for us, specifically - Power Manager
(which, by the way, is currently the 2nd most popular Paid
Application), have thrown away our money since we will be prompted to
allow changes for some of the settings every time the application
wants to change them? Man, I am glad this app was only $0.99,
otherwise I'd be really ticked off. Not to mention that I will not be
able to conserve battery life as well as I do now, meaning that this
effort to help users conserve battery life actually hurts me (and
10,000 - 50,000 other users who have purchased Power Manager).
On Apr 24, 10:48 am, Tom Gibara <m...@tomgibara.com> wrote:
> > ... The GPS hardware will only actually be powered up> if someone is
> asking to get data from it.... Another way> to look at this -- the GPS setting is primarily there for
> > privacy, to allow users to determine whether is okay -at
> > all- for anyone to be getting the fine-grained information
> > about where they are.
> So it's really unfortunate that the explanation for the GPS setting reads:
> "deselect to conserve battery", it gives every user I've discussed it with
> the impression that enabling the setting will drain their battery faster
> independently of what applications choose to do. This is enforced the
> absence of similar indications for other settings.
I wouldn't worry, you can always do a chargeback on your credit card for
power manager and Google will approve it through and fine the developer $3
all without asking them...
[mailto:android-developers@googlegroups.com] On Behalf Of nEx.Software
Sent: 24 April 2009 20:01
To: Android Developers
Subject: [android-developers] Re: Android v. 1.5 = FAIL #2: Directly
Manipulating Settings
So, if I understand this all correctly... Those of us who have paid for an
app to toggle settings for us, specifically - Power Manager (which, by the
way, is currently the 2nd most popular Paid Application), have thrown away
our money since we will be prompted to allow changes for some of the
settings every time the application wants to change them? Man, I am glad
this app was only $0.99, otherwise I'd be really ticked off. Not to mention
that I will not be able to conserve battery life as well as I do now,
meaning that this effort to help users conserve battery life actually hurts
me (and 10,000 - 50,000 other users who have purchased Power Manager).
On Apr 24, 10:48 am, Tom Gibara <m...@tomgibara.com> wrote:
> > ... The GPS hardware will only actually be powered up> if someone is
> asking to get data from it.... Another way> to look at this -- the GPS > setting is primarily there for
> > privacy, to allow users to determine whether is okay -at
> > all- for anyone to be getting the fine-grained information about > > where they are.
> So it's really unfortunate that the explanation for the GPS setting reads:
> "deselect to conserve battery", it gives every user I've discussed it > with the impression that enabling the setting will drain their battery > faster independently of what applications choose to do. This is > enforced the absence of similar indications for other settings.
I don't want to single out any particular app, but conversely should a
developer sell an application that can't be supported in the future because
it uses an undocumented API?
Tom.
> I wouldn't worry, you can always do a chargeback on your credit card for
> power manager and Google will approve it through and fine the developer $3
> all without asking them...
> Nice... Not.
> Al.
> -----Original Message-----
> From: android-developers@googlegroups.com
> [mailto:android-developers@googlegroups.com] On Behalf Of nEx.Software
> Sent: 24 April 2009 20:01
> To: Android Developers
> Subject: [android-developers] Re: Android v. 1.5 = FAIL #2: Directly
> Manipulating Settings
> So, if I understand this all correctly... Those of us who have paid for an
> app to toggle settings for us, specifically - Power Manager (which, by the
> way, is currently the 2nd most popular Paid Application), have thrown away
> our money since we will be prompted to allow changes for some of the
> settings every time the application wants to change them? Man, I am glad
> this app was only $0.99, otherwise I'd be really ticked off. Not to mention
> that I will not be able to conserve battery life as well as I do now,
> meaning that this effort to help users conserve battery life actually hurts
> me (and 10,000 - 50,000 other users who have purchased Power Manager).
> On Apr 24, 10:48 am, Tom Gibara <m...@tomgibara.com> wrote:
> > > ... The GPS hardware will only actually be powered up> if someone is
> > asking to get data from it.... Another way> to look at this -- the GPS
> > setting is primarily there for
> > > privacy, to allow users to determine whether is okay -at
> > > all- for anyone to be getting the fine-grained information about
> > > where they are.
> > So it's really unfortunate that the explanation for the GPS setting
> reads:
> > "deselect to conserve battery", it gives every user I've discussed it
> > with the impression that enabling the setting will drain their battery
> > faster independently of what applications choose to do. This is
> > enforced the absence of similar indications for other settings.
On Fri, Apr 24, 2009 at 12:44 PM, Tom Gibara <m...@tomgibara.com> wrote:
> I don't want to single out any particular app, but conversely should a
> developer sell an application that can't be supported in the future because
> it uses an undocumented API?
> Tom.
>> I wouldn't worry, you can always do a chargeback on your credit card for
>> power manager and Google will approve it through and fine the developer $3
>> all without asking them...
>> Nice... Not.
>> Al.
>> -----Original Message-----
>> From: android-developers@googlegroups.com
>> [mailto:android-developers@googlegroups.com] On Behalf Of nEx.Software
>> Sent: 24 April 2009 20:01
>> To: Android Developers
>> Subject: [android-developers] Re: Android v. 1.5 = FAIL #2: Directly
>> Manipulating Settings
>> So, if I understand this all correctly... Those of us who have paid for an
>> app to toggle settings for us, specifically - Power Manager (which, by the
>> way, is currently the 2nd most popular Paid Application), have thrown away
>> our money since we will be prompted to allow changes for some of the
>> settings every time the application wants to change them? Man, I am glad
>> this app was only $0.99, otherwise I'd be really ticked off. Not to
>> mention
>> that I will not be able to conserve battery life as well as I do now,
>> meaning that this effort to help users conserve battery life actually
>> hurts
>> me (and 10,000 - 50,000 other users who have purchased Power Manager).
>> On Apr 24, 10:48 am, Tom Gibara <m...@tomgibara.com> wrote:
>> > > ... The GPS hardware will only actually be powered up> if someone is
>> > asking to get data from it.... Another way> to look at this -- the GPS >> > setting is primarily there for
>> > > privacy, to allow users to determine whether is okay -at
>> > > all- for anyone to be getting the fine-grained information about
>> > > where they are.
>> > So it's really unfortunate that the explanation for the GPS setting
>> > reads:
>> > "deselect to conserve battery", it gives every user I've discussed it
>> > with the impression that enabling the setting will drain their battery
>> > faster independently of what applications choose to do. This is
>> > enforced the absence of similar indications for other settings.
>> > Tom.
-- 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
It's a good thing I copied and duplicated all of the private APIs I
used into my own project. :)
I understand though, guess I didn't realize that Power Manager was
using private APIs.
I still think there were better ways to handle this, such as those
mentioned above.
I'd gladly make the decision at install time to allow an app access to
settings.
I won't appreciate having to manually change settings all of the time.
On Apr 24, 6:32 pm, Romain Guy <romain...@google.com> wrote:
> It's not like we didn't warn developers about private APIs :)
> On Fri, Apr 24, 2009 at 12:44 PM, Tom Gibara <m...@tomgibara.com> wrote:
> > I don't want to single out any particular app, but conversely should a
> > developer sell an application that can't be supported in the future because
> > it uses an undocumented API?
> > Tom.
> >> I wouldn't worry, you can always do a chargeback on your credit card for
> >> power manager and Google will approve it through and fine the developer $3
> >> all without asking them...
> >> Nice... Not.
> >> Al.
> >> -----Original Message-----
> >> From: android-developers@googlegroups.com
> >> [mailto:android-developers@googlegroups.com] On Behalf Of nEx.Software
> >> Sent: 24 April 2009 20:01
> >> To: Android Developers
> >> Subject: [android-developers] Re: Android v. 1.5 = FAIL #2: Directly
> >> Manipulating Settings
> >> So, if I understand this all correctly... Those of us who have paid for an
> >> app to toggle settings for us, specifically - Power Manager (which, by the
> >> way, is currently the 2nd most popular Paid Application), have thrown away
> >> our money since we will be prompted to allow changes for some of the
> >> settings every time the application wants to change them? Man, I am glad
> >> this app was only $0.99, otherwise I'd be really ticked off. Not to
> >> mention
> >> that I will not be able to conserve battery life as well as I do now,
> >> meaning that this effort to help users conserve battery life actually
> >> hurts
> >> me (and 10,000 - 50,000 other users who have purchased Power Manager).
> >> On Apr 24, 10:48 am, Tom Gibara <m...@tomgibara.com> wrote:
> >> > > ... The GPS hardware will only actually be powered up> if someone is
> >> > asking to get data from it.... Another way> to look at this -- the GPS > >> > setting is primarily there for
> >> > > privacy, to allow users to determine whether is okay -at
> >> > > all- for anyone to be getting the fine-grained information about
> >> > > where they are.
> >> > So it's really unfortunate that the explanation for the GPS setting
> >> > reads:
> >> > "deselect to conserve battery", it gives every user I've discussed it
> >> > with the impression that enabling the setting will drain their battery
> >> > faster independently of what applications choose to do. This is
> >> > enforced the absence of similar indications for other settings.
> 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
For the most part, My Vista computer only prompts during install to
get permission to write to the programs directory. Personally I find
the Andoid model much more annoying because it is so fine grained and
meaningless to the average user.
On Apr 24, 10:44 am, Mark Murphy <mmur...@commonsware.com> wrote:
> patg wrote:
> > I am surprised that Android's security model asking for permissions
> > when every application is installed is tollerated while WIndows Vista
> > basically doing the same thing in a simpler way receives howls of
> > protest.
> Android's permission model involves an install-time prompt to grant
> permission. Vista's involves a run-time prompt to grant permission. That
> is a huge difference for an application that is run more than a couple
> of times.
> > Additionally, I don't think the average teenager or grand-mother knows
> > what any of the fine grain permissions in Android mean and will just
> > go ahead and allow any app to have the permissions it wants.
> Solve that problem, and you have yourself a very lucrative consulting
> business.
|
