Multiple service account?

[harshmandan]

I have a config like this which works fine:

android {
   ...
   flavorDimensions "version"
   productFlavours {
       flavourEXMPL {
             applicationIdSuffix ".example"
             play {
                 track = "beta"
                 userFraction = 1
             }
         }

         flavourTEST {
             applicationIdSuffix ".test"
             play {
                 track = "beta"
                 userFraction = 1
             }
         }
   }
}

play {
defaultToAppBundles = true
serviceAccountCredentials = file("key1.json")
}

Now I want to use multiple service accounts for different flavours. Accorrding to the documentation, I should use playConfigs. So I updated the config like this:

android {
   ...
   flavorDimensions "version"
   productFlavours {
       flavourEXMPL {
             applicationIdSuffix ".example"
             play {
                 track = "beta"
                 userFraction = 1
             }
         }

         flavourTEST {
             applicationIdSuffix ".test"
             test {
                 track = "beta"
                 userFraction = 1
             }
         }
   }

   playConfigs {
       play {
              defaultToAppBundles = true
              serviceAccountCredentials = file("key1.json")
       }
       test {
              defaultToAppBundles = true
              serviceAccountCredentials = file("key2.json")
       }
   }
}

But this throws this error:

A problem occurred evaluating project ':app'.
> No signature of method: build_evdnx6dyz0jw9xu38p4b4djbo.android() is applicable for argument types: (build_evdnx6dyz0jw9xu38p4b4djbo$_run_closure1) values: [build_evdnx6dyz0jw9xu38p4b4djbo$_run_closure1@72b0ed27]

[SUPERCILEX]

Please read the docs (you can open the Groovy code samples).

[harshmandan]

@SUPERCILEX I've mentioned the same config as stated in the docs. Not working for me. Can you please point out what am I doing wrong?

[SUPERCILEX]

Everything. :) Please let me know if you have suggestions to improve the docs. BTW, make sure you're using v2.7.5 of the plugin.

• The play blocks under productFlavours don't do anything. play is a singleton and there's only one instance of that object. So everytime you set a property on play, you're just overwriting whatever value you had set previously.
• The play block under playConfigs also doesn't do anything. In this case, you're trying to add an object to playConfigs named "play" which doesn't make sense because you don't have product flavors or dimensions named "play."
• The test block is also probably wrong since I don't think you have a flavor named "test."

Here's configuration that probably does what you want:

android {
   // ...

   flavorDimensions "version"
   productFlavours {
       flavourEXMPL {
             applicationIdSuffix ".example"
         }

         flavourTEST {
             applicationIdSuffix ".test"
         }
   }

   playConfigs {
       flavourEXMPL {
              serviceAccountCredentials = file("key1.json")
       }
       flavourTEST {
              serviceAccountCredentials = file("key2.json")
       }
   }
}

play {
  track = "beta"
  userFraction = 1
  defaultToAppBundles = true
}

[harshmandan]

Hi. Thanks for the clarification. It seems everything is wrong, yes. But I think the wrong config posted by me do makes sense in a way. I have an app that has 20+ flavours distributed among three developers account. I though using one block as config and specifying that block under different flavours would apply that config to that flavour.

But now I see that I'm wrong. Your clarification helps immensely.

I'm still confused though. Would you be able to answer these questions:

• Do I need to specify the accountCredentials for every flavour?
• How do I specify the track on per-flavour-basis? For eg., If I want one flavour to be in beta and another flavour to be in production.

Thanks again for the clarification. And I would surely like to add some things in the documentation to make it more clear. Will send a PR for that.

Edit: Alright, I think I got the answer to my second question. The playConfigs can overwrite config for the play block per-flavours-basis. So answering my own question, that would be:

android {
   // ...

   flavorDimensions "version"
   productFlavours {
       flavourEXMPL {
             applicationIdSuffix ".example"
         }

         flavourTEST {
             applicationIdSuffix ".test"
         }
   }

   playConfigs {
       flavourEXMPL {
              serviceAccountCredentials = file("key1.json")
              track = "production"
       }
       flavourTEST {
              serviceAccountCredentials = file("key2.json")
              track = "beta" //redundant entry as the default play config is "beta"
       }
   }
}

play {
  track = "beta"
  userFraction = 1
  defaultToAppBundles = true
}

Still, do I have to create a separate playConfigs block or can I contain the config in the flavour block somehow?

Edit 2:

I think I got it. This is the final config. The first question that I asked is also clear now.

android {
   // ...

   flavorDimensions "version"
   productFlavours {
       flavourEXMPL {
             applicationIdSuffix ".example"
         }

         flavourTEST {
             applicationIdSuffix ".test"
         }

         flavourEXMPL2 {
             applicationIdSuffix ".exmpl2"
         }

   }

   playConfigs {
       flavourEXMPL {
              track = "production" //override track to production
       }
       flavourTEST {
              serviceAccountCredentials = file("key2.json") //override key as developer account is different
       }
      //no need to override any settings for flavourTEST2 now as the deafult play block holds the correct config for it.
   }
}

play {
  serviceAccountCredentials = file("key1.json") //this is the default key
  track = "beta"
  userFraction = 1
  defaultToAppBundles = true
}

[SUPERCILEX]

Yes! All of your examples seem correct! 🙌 As for putting the play block inside flavors, I think we actually used to do that in an old version of GPP, but got rid of it because we thought it was confusing.