-
-
Notifications
You must be signed in to change notification settings - Fork 339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple Service Accounts #76
Comments
Ended up using jvm variables similar to the workaround in #65 |
I thought of something similar to Android's signingConfigs. So one can define one or more |
I've sort of worked around this issue myself in a different way. I too have one project with many flavors that go to different Google Play accounts. What I've done, is in my build.gradle file, specify signingConfigs for each dev account (even if the keystore info is the same) for each flavor config. I created some property files based on the signingConfig name with the dev service account info in it, and dropped them into the module root directory. Then in 'PlayPublishApkTask.groovy', I added the following to the publishApk() function: @TaskAction
publishApk() {
def signingConfigName = variant.signingConfig.name;
def propertiesFileName = "${signingConfigName}.play.properties"
File propFile = new File(propertiesFileName.toString());
if (propFile.exists()) {
Properties properties = new Properties()
properties.load(new FileInputStream(propFile))
extension.serviceAccountEmail = properties['serviceAccountEmail']
extension.pk12File = new File(properties['pk12File'])
}
super.publish()
...
} This gives the result of the correct dev service account info feeding in, if available, else it'll use the standard 'play' closure configuration in build.gradle. Not worrying about having to switch service account information when submitting app updates was my main goal. It's a bit messy and requires some extra setup, but working with limited Android DSL property availability, this was an alternative solution I came to. |
Hi @mattxander12 . Your solution sounds like a better option. Do you mind sharing a repo with all the needed directories/files ? Thanks |
Hello, At this point I still can't use multiple service accounts with this plugin out-of-the-box, even when I compile the branch playSigningConfigs. I suppose it's because this branch is still a WIP and everything's not ready yet? Anyway, do you have an ETA for this feature? Thank you |
You're right. This is not really satisfying, I completely understand. But I'm kind of stuck right now and could use some help or a least a hint what I am doing wrong here. I added a failing test to show what I am aiming at. My goal is to extend the DSL with the concept of Can anyone shed some light on this issue? |
As per Googles recommendation we've started putting our customers apps (basically a flavor) on different accounts so this is something that is badly needed (that or Google fixing so you can use a service account for other Play-accounts that you have access-rights to...) I stumbled across this when I was looking for a solution: So basically nothing in the build.gradle but instead the json-file in the flavor directory (configuration by location kind of thing). Doesn't really feel like the prettiest solution but feels like it should be easy to implement (might take a stab at it, had a go at the DSL solution but couldn't get my head around it). |
@brp-david I have a repo forked off this with that functionality built in: https://github.com/tunjid/gradle_play_publisher/commits/develop |
@tunjid excellent, thank you! Already hacked together a working version but useful nonetheless. |
, Triple-T#86 (cherry picked from commit ffb938c)
My fork has working DSL (see example in PlayPublisherPluginTest.groovy). It does require change to the config but I've been using this in production for a month now with 89 flavors spread over 6 different play-accounts. |
Available in |
I'm working on an application that has two flavours. Each flavour corresponds to a brand/client. Each brand has it's own developer account.
Is it possible to configure a per-flavour service account? do you have plans to add this functionality?
Do you guys know how can I accomplish this in the current state?
Maybe with a task that configures the play plugin for each flavour before actually running the upload?
Thanks
The text was updated successfully, but these errors were encountered: