Permissions automatically added to android app manifest

Last week when I displayed a QR code to download my app, the one person who talked to me about it was a security person, and of course she asked: why does it need these permissions?

Storage: modify/delete SD card contents. Phone calls: read phone state and identity

Say what? I didn't ask for those!

Truth be told, I had no idea (except for the start-at-boot, which is in the manifest and needed so it can install alarms at boot). I noticed them when I did a test install but didn’t think much about it because I was in a hurry. No, LogMyLife doesn’t need to write to the SD card or read the phone identity. OK, it will need to write to SD once I implement export/import of data; but it will never need to read the phone identity.

Tonight I finally got a chance to look into this. It turns out, if you build your app to run on the 1.5 platform (which LogMyLife does so that my wife’s Cliq can use it), these permissions are silently added when the APK is created. Believe it or not this is “working as designed” according to this Google Code issue. Romain Guy could have been a little more helpful there and provided a link to some kind of useful explanation, but I get the drift: because these permissions were introduced in 1.6, they’re grandfathered in to apps built for previous versions (which didn’t have to declare them), and so have to be included for them to work on platforms 1.6 and up, just in case they’re needed.

There’s some kind of voodoo in the Android Market that keeps these added permissions from showing up at download/install time. But they’re still technically there, and they’ll show up if the user looks at the application permissions later. Also they’ll show up at install via non-Market path, like during beta testing. Sigh! Fortunately, or un-fortunately, most users are pretty oblivious to permissions. But not security people.

So, what to do? I could exclude my wife and the other unfortunates stuck on 1.5 and just target 1.6+. Perhaps I could provide different APKs, one just for 1.5, and another for 1.6+? Well, regardless of that, what I think every app author should be doing is explaining exactly what they’re doing with those permissions. I’ll include a section in the app README, and also in the Market description (once it’s on there), explaining what permissions are used and why, and I can explain where these two come from if needed.

Advertisements

Android packaging and publishing

I’m giving a lightning talk on LogMyLife and other Android-y stuff this Friday at SplatSpace. I thought it’d be nice to allow people to download the app and try it out if they so desire, even though it’s still pre-release at this point. So I looked around on github and found where I could create downloads (in addition to the source download that’s automatic).

On a different machine from what I usually develop on, I created a new LogMyLife package. Actually, it wasn’t quite that simple, because I discovered my SDK debug keystore cert had expired. Which wasn’t quite that simple either, as I had to track down the error message (which I forget at this point). But, congrats me, I’ve been at this for a year now! Or not congrats so much, as I still don’t have a complete app on the market to show for it. But I have my excuses.

Anyway, I deleted the existing keystore and the Eclipse ADT plugin kindly made another one behind the scenes, and I carried on. I uploaded the package and got an error, but it seemed to have succeeded. The cool thing was when I found github automatically pulls a QRcode from a Google service for the uploaded APK:

So I can just include that in my slide and people can use their Android device’s barcode reader to scan it and download if they so desire. So can you while you’re looking at this.

Of course I tried this, and I tried it on my phone, where I already had LogMyLife installed. It downloaded and nicely showed me the permissions it needed and notified me it would replace the current app. Then it proceeded to fail to install. There wasn’t really an informative message, but I think I know what happened.

That key I was talking about earlier? Well, it was of course different on my two dev machines. I’m pretty sure the phone refused to install the app because the key had changed from what was previously installed. I would have to un-install the app in order to install the version signed with a different key. Which leads me to wonder whether I’ll have the same problem once I sign it with my official market signing key for release? I don’t want to lose what data I already have been collecting on my phone, so if that’s the way it will be, I’m gonna be prioritizing the “Export/import data” feature way up.

I went ahead and signed up for an Android Market account finally. I’ll probably post something for beginners about the process on my neglected “Android from scratch” blog at some point. It’s pretty simple, but you don’t know what your $25 gets you to start with. Strangely enough, there doesn’t seem to be anything about signing your app on the market site. There is on the dev site, of course. It seems somewhat complicated to do by hand, but pretty simple from the Eclipse plugin. Nothing seems to mention what happens when you change keys – what the practical consequences of doing that would be. I’ll find out soon enough. Just for fun I tried uploading my dev LogMyLife.apk, and received only the error message “Upload a valid APK.” I guess if you don’t know about this stuff they’re not gonna help you find it!

notes on android market terms

Google Android Market distribution terms:
3.4 users can get a refund on their apps if requested within 48 hours.
3.6 once app is purchased they can reinstall for free.
4.1 dev retains IP rights.
4.3 you agree to protect user privacy / secure info
4.4 can’t use customer base from market as leads for outside-market app
4.5 can’t use market app to set up a competing market
4.6 there are restrictions on app content – for instance respecting carrier terms of service would prohibit network tethering apps
7.2 Google doesn’t filter/monitor your apps, but can take them down if they become aware of violations.