On 8/2/2012 1:16 PM, omoling wrote:
I really don't see ANY point in requiring permissions that you might
> use in the future, but don't use now. if your app requires permission
> X (eg reading contacts), I must assume you are using it, the opposite
> does not make sense, at all.
The reason to use a permission that you're not using NOW is that if you
add the permission later, you're likely to get a pile of negative
reviews and uninstalls as people are forced to re-agree to permissions
and freak out when they realize what it is that you're NOW asking for.
This has been discussed here before, and the advice given was to always
ask for everything that you might ever need, or suffer major negative
consequences when you do need it. People on the list have reported this,
and I've seen it happen to a half dozen apps myself. You can't claim it
won't happen, because it DOES. I've seen it many times!
Often, a developer has several ways to solve an issue, if the
> shortest and easiest one implies requiring privacy-concerning
> permissions like reading the log files (just saying)
There is NO other way to get that information if you're an NDK user.
Implying that we're being lazy or stupid is just untrue. We had that
debate on this list a while back as well, and no one was able to suggest
an alternative then, either.
a developer cannot, in my opinion, be frustrated if that request is not liked
by
> some users.
We can and we will, because the log files contain almost NO private
information ANYWAY. The warning is FAR too scary for the actual "privacy
violation" involved, and you're just making it worse! At worst I might
be able to find out that some user -- who I don't even know their email
-- uses some app that might be embarrassing. If someone wrote a
completely incompetent app and wrote a password to the log, then I COULD
see that -- but MY app filters out everything that doesn't come from my
app, so I couldn't actually see that. I'm very transparent about that
and explain why and how I use the permission in the app description, and
that I show you the log before I send it. Does Appprivacy look at the
description and determine that I explain why I need it, and how I use it?
READ_PHONE_STATE is even worse. It's one of the many ways the Android
SDK is profoundly broken. Almost NO ONE needs to know "who you're
calling;" 99.99% of users of that permission have ads in their apps, and
the permission is to get a unique ID from the phone. Big. Deal. But no,
it's this "scary" permission. How does your app treat it?
There are lots of ways to do some good debugging without
> reading log files, just saying.
This is just insulting, as well as wrong. How big are the apps you've
produced? How many have you produced? How many users do they have? I've
written an SDK used by over a hundred published games, and have been
lead engineer on games with millions of cumulative installs. What are
the credentials that you have that justify you implying that anyone who
uses the LOG permission is incompetent?
My Android apps are based on the NDK, and the standard Java-based
debugging/crash handling is useless there. For example, how could I have
discovered that the OpenGL drivers on some phones have a bug that
crashes when I call glEnable() at a bad time without reading the log
files on the appropriate phones? Or that Samsung phones have a pervasive
bug when you use SoundPool objects?
Do I need to buy every phone that has a problem? Google certainly
doesn't give me crash dumps that are in the slightest bit useful, and
every single Java crash dump I ever see shows the Java stack at the
Render() call which calls into my code. I write games; they're real
time. If I wrote enough to the log to track down every conceivable crash
point, then my games would run at about 5 frames per second. Even faster
methods of tracing would slow things down (caching a round-robin log and
only writing it on a crash, for instance).
Please don't make absolute statements unless you know the actual
challenges involved. And please don't make insulting statements at all.
> If a developer publishes a good app, and at a later point she updates
> it by adding some functionality and some permissions required, users
> will just update and continue to use the app.
And MANY users will post 1-star reviews. I've seen it happen a LOT.
I simply don't trust apps that require permissions for which I can
> not see the purpose.
Fine. Don't. But reading log files is necessary sometimes. And reading
contacts is sometimes necessary. And other permissions are sometimes
necessary. I do feel like Apprivacy is more likely to scare users away
from useful and harmless apps than actually protect them from harmful
apps (probably 98% false positives, maybe more), and misleading users
about how harmful an app is will piss off developers, no matter how you
slice it.
With 100-500 installs, your app is not actually a threat, but don't
expect any sympathy here, especially if you're willing to cast insults
at those you want support from.
Tim
--
You received this message because you are subscribed to the Google Groups "Android
Discuss" 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-discuss?hl=en.
