Skip to content
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

Closed
robertoestivill opened this issue Jun 2, 2015 · 11 comments
Closed

Multiple Service Accounts #76

robertoestivill opened this issue Jun 2, 2015 · 11 comments

Comments

@robertoestivill
Copy link

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

@robertoestivill robertoestivill changed the title Multiple Dev Accounts Multiple Service Accounts Jun 2, 2015
@robertoestivill
Copy link
Author

Ended up using jvm variables similar to the workaround in #65
Would still be nice to know what the collaborators opinion is on having this per signing config.

@bhurling
Copy link
Contributor

I thought of something similar to Android's signingConfigs. So one can define one or more playSigninigConfigsand then use it inside of the build flavour block. I think we would have to extend their DSL to do something like that. Is that even possible?

@mattxander12
Copy link

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.

@robertoestivill
Copy link
Author

Hi @mattxander12 . Your solution sounds like a better option. Do you mind sharing a repo with all the needed directories/files ? Thanks

@rubeus90
Copy link

rubeus90 commented Sep 2, 2015

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

bhurling added a commit that referenced this issue Sep 3, 2015
@bhurling
Copy link
Contributor

bhurling commented Sep 3, 2015

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 playAccountConfigssimilar to sigingConfigs. I managed to add this property to the com.android.build.gradle.AppExtension but now I can't reference it from within a flavor.

Can anyone shed some light on this issue?

@d-lindahl
Copy link
Contributor

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:
http://stackoverflow.com/questions/30772201/google-services-json-for-different-productflavors

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).
Wouldn't solve things like track / uploadImages per flavour of course.

@tunjid
Copy link

tunjid commented Aug 10, 2016

@brp-david I have a repo forked off this with that functionality built in: https://github.com/tunjid/gradle_play_publisher/commits/develop

@d-lindahl
Copy link
Contributor

@tunjid excellent, thank you! Already hacked together a working version but useful nonetheless.

d-lindahl pushed a commit to d-lindahl/gradle-play-publisher that referenced this issue Aug 12, 2016
@d-lindahl
Copy link
Contributor

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.

@bhurling
Copy link
Contributor

Available in 1.2.0-beta3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants