Actually, I can imagine two very common cases: 1) Code or even functionality is changed in an application, possibly in some minor way. The developer does not realize that he has removed the last SDK call using a permission. The permission lingers on in the manifest. It doesn't do much harm, but add minor bloat and maybe scares aways some users.
2) A developer adds a new feature, and does not realize that a permission is needed. Best case, he catches this immediately when testing, but still wastes time and annoyance on an extra compile/ deploy/test cycle. It seems that it would not be too hard to annotate the SDK and and a static permissions check to the build cycle. I can imagine pathological cases, but this should catch 99% of the problems. David On Jul 12, 9:39 pm, TreKing <[email protected]> wrote: > On Sat, Jul 10, 2010 at 2:26 PM, deg <[email protected]> wrote: > > (I know that I can remove all permissions and then repeatedly test > > each code path, reinstating each missing permission that causes the > > > app to malfunction. But, surely, there is a better way!) > > Actually, I really doubt it. You'd need some tool to evaluate your code, see > what SDK functions you are using, and validate that you have the associated > permissions, if any. I'm not aware of any such tool nor any reason to make > one, save for rare instances like this. > > --------------------------------------------------------------------------- > ---------------------- > TreKing - Chicago transit tracking app for Android-powered > deviceshttp://sites.google.com/site/rezmobileapps/treking -- 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
