> > 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! >
I disagree... I have an app that uses far fewer permissions than most of my competitors. I have received numerous emails telling me how much they love my app and that they chose to insall mine over my competitors because I had less permissions. Thanks, Justin Anderson MagouyaWare Developer http://sites.google.com/site/magouyaware On Thu, Aug 2, 2012 at 11:24 PM, Tim Mensch <[email protected]> wrote: > 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. > -- 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.
