Specify in README which permissions must be given in API access about gradle-play-publisher

[bhurling]

I am not exactly sure what permissions you are referring to. Do you mean the user accounts you can create in the developer console? There is a predefined user role called version manager (I think, because it is translated to something similar in German for me). But if you followed the steps described in https://developers.google.com/android-publisher/getting_started that should be automatically set.

But if I look closer there are really just three permissions that user needs and those would be

• update the play store listing
• publish production apks
• publish alpha, beta apks (if you are using any of those tracks)

I haven't tried it, though, because I usually just go with that default role.

[ZacSweers]

We'll investigate further. We have a very large app (100m+ installs), so anything permissions-wise with publishing is done cautiously. I'll give it a try with just the default version manager role. If that works, I'll whittle down the permissions to see which ones are the necessary ones.

We have it set with the listing and alpha/beta permissions, but purposefully withheld the production one since we will only be using this for an internal-only alpha channel. Hopefully not having that permission isn't what's causing it 😦

Also might mention that Google appears to impose a hard limit of one upload (even attempt) per 24 hour period, though maybe it's just a rate limiting increase due to our testing. Due to that, might be a couple of days before I can update this with the results of our testing.

[bhurling]

Also, you should try running the task with the --debug flag. The Google API logs a lot of stuff and that way you can see which request causes that error.

[ZacSweers]

So further investigation shows it does require permission to upload APKs for all three channels, even if you'd prefer to limit its access to just alpha/beta.

Here is a screenshot of the minimum permissions required for the plugin to work, even if a developer doesn't personally need them for their intended use (like the example above).

I have no idea why it requires access to manage alpha and beta users, but publishListing... tasks will not work without it.

[bhurling]

I investigated a little further and I think I know what is happening. It is all about the way the Google Play API works. You basically edit your app in a staging area called an Edit. There you have everything in one place: The apk, the apklisting, the images, the listing itself and so on. Even the test users are part of that construct. Once you are done with all your changes you have to commit them and everything is updated in one atomic operation.

Thus, in theory you could change all the parts of the app at once. Unfortunately, the server does not figure out what resources are touched, beforehand. So it has a rather pessimistic approach. The Client might want to update every part of the app in that operation -> Just require all permissions.

I don't think there is much we can do about it, except for filing a feature request anywhere. I am sure Google will understand our concerns when it comes to security and permissions. Any idea for a good place to file such a request?

[bhurling]

Filed it here: https://code.google.com/p/google-api-java-client/issues/detail?id=917

[ZacSweers]

Yeah that's probably the best place to file that request. It does seem heavy handed, but I guess it's easier for them to control on their side if it requires all these permissions up front. Hopefully they'll reconsider, I'll star the issue and chime in as well :)

[bhurling]

The issue on Google Code has been moved to Done. I don't think there is anything left we can do about it so I updated the README with the required permissions.

[ZacSweers]

yeah I guess we'll just have to hope they improve this in the future.
Thanks for looking into it and filing for he issue!
On Wed, Jan 7, 2015 at 6:42 AM Björn Hurling [email protected]
wrote:

Closed #20 #20.

—
Reply to this email directly or view it on GitHub
#20 (comment)
.