Multiple Service Accounts about gradle-play-publisher

[d-lindahl]

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.

[d-lindahl]

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

[bhurling]

Available in 1.2.0-beta3

[robertoestivill]

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]

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]

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]

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

[rubeus90]

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]

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]

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]

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