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

BuildType/Flavour Support #54

Closed
chrisjenx opened this Issue Aug 31, 2015 · 91 comments

Comments

Projects
None yet
@chrisjenx

chrisjenx commented Aug 31, 2015

I have had a look, I can't see another issue.

How do we enabled different configs per flavour/buildType? Most Common use case is where we have different analytics tracking and GCM senders per debug/release builds.

Favours would be an added bonus.

Thanks.

@ianbarber

This comment has been minimized.

Show comment
Hide comment
@ianbarber

ianbarber Aug 31, 2015

Contributor

If you vary on package name you should be OK - the gradle plugin should pull config from the JSON based on the app's package name.

Contributor

ianbarber commented Aug 31, 2015

If you vary on package name you should be OK - the gradle plugin should pull config from the JSON based on the app's package name.

@silvolu

This comment has been minimized.

Show comment
Hide comment
@silvolu

silvolu Aug 31, 2015

Contributor

It won't solve the GCM senders part though: you got one per app, so the different packages will share the same GCM sender ID.

Contributor

silvolu commented Aug 31, 2015

It won't solve the GCM senders part though: you got one per app, so the different packages will share the same GCM sender ID.

@ajfclark

This comment has been minimized.

Show comment
Hide comment
@ajfclark

ajfclark Nov 24, 2015

@ianbarber Can you give an example of how to combine multiple google.services files together when the package name varies per flavour?

ajfclark commented Nov 24, 2015

@ianbarber Can you give an example of how to combine multiple google.services files together when the package name varies per flavour?

@chrisjenx

This comment has been minimized.

Show comment
Hide comment
@chrisjenx

chrisjenx Nov 24, 2015

You just keep adding them to the config on the website and it combines them
all together in the JSON file.

On Tue, 24 Nov 2015, 14:28 Andrew Clark notifications@github.com wrote:

@ianbarber https://github.com/ianbarber Can you give an example of how
to combine multiple google.services files together when the package name
varies per flavour?


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

chrisjenx commented Nov 24, 2015

You just keep adding them to the config on the website and it combines them
all together in the JSON file.

On Tue, 24 Nov 2015, 14:28 Andrew Clark notifications@github.com wrote:

@ianbarber https://github.com/ianbarber Can you give an example of how
to combine multiple google.services files together when the package name
varies per flavour?


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

@bigD666

This comment has been minimized.

Show comment
Hide comment
@bigD666

bigD666 Nov 24, 2015

Stop emailing me
On 25 Nov 2015 08:58, "Andrew Clark" notifications@github.com wrote:

@ianbarber https://github.com/ianbarber Can you give an example of how
to combine multiple google.services files together when the package name
varies per flavour?


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

bigD666 commented Nov 24, 2015

Stop emailing me
On 25 Nov 2015 08:58, "Andrew Clark" notifications@github.com wrote:

@ianbarber https://github.com/ianbarber Can you give an example of how
to combine multiple google.services files together when the package name
varies per flavour?


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

@ajfclark

This comment has been minimized.

Show comment
Hide comment
@ajfclark

ajfclark Nov 24, 2015

@chrisjenx Where? I go to https://developers.google.com/mobile/add, pick android, Pick the app and package name, add analytics as a service and then the only option is to generate the config file.

[edit: oh, I see now. You have to go in, add a service, generate a config, go back to the original url, add another service, etc. That's horribly non-intuitive.

Is there anywhere you can see what's already been added to a project, modify existing services, etc?]

ajfclark commented Nov 24, 2015

@chrisjenx Where? I go to https://developers.google.com/mobile/add, pick android, Pick the app and package name, add analytics as a service and then the only option is to generate the config file.

[edit: oh, I see now. You have to go in, add a service, generate a config, go back to the original url, add another service, etc. That's horribly non-intuitive.

Is there anywhere you can see what's already been added to a project, modify existing services, etc?]

@ajfclark

This comment has been minimized.

Show comment
Hide comment
@ajfclark

ajfclark Nov 24, 2015

@bigD666 I'm not. Github is. You must be watching this project or issue or something?

ajfclark commented Nov 24, 2015

@bigD666 I'm not. Github is. You must be watching this project or issue or something?

@chrisjenx

This comment has been minimized.

Show comment
Hide comment
@chrisjenx

chrisjenx Nov 25, 2015

@ajfclark correct, pick the same "App Name" then add new package names:

If you pick the same package name and continue, you can add/see whats added to that config.

See example:
screen shot 2015-11-24 at 16 07 32

chrisjenx commented Nov 25, 2015

@ajfclark correct, pick the same "App Name" then add new package names:

If you pick the same package name and continue, you can add/see whats added to that config.

See example:
screen shot 2015-11-24 at 16 07 32

@ajfclark

This comment has been minimized.

Show comment
Hide comment
@ajfclark

ajfclark Nov 26, 2015

It'd be nice if there was an "add another service" or something button to make it obvious that you could do that.

ajfclark commented Nov 26, 2015

It'd be nice if there was an "add another service" or something button to make it obvious that you could do that.

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Nov 30, 2015

Member

@ajfclark agreed, we are currently considering the best way to support build flavors in the UI.

Member

samtstern commented Nov 30, 2015

@ajfclark agreed, we are currently considering the best way to support build flavors in the UI.

@yairkukielka

This comment has been minimized.

Show comment
Hide comment
@yairkukielka

yairkukielka Dec 4, 2015

@samtstern yes, please. This would be great. I have another tricky case with our app:

We have 4 build variants: FreeDev, FreeProd, PaidDev and PaidProd. Each of these variants has a Google Services project, so we have 4 Google Services project ids: Free dev, Free prod, Paid dev and Paid prod.

Is there a way to get only one google-services.json for all these Google Services projects? If I had only one Google Services account with multiple flavors (package names) I see that I could apply what @chrisjenx is saying, but how do I achieve that for different Google Services projects?

If it's not possible, how should I use different google-services.json files in my local project?

This is what I see when I try to enable Google Services for my app:
screen shot 2015-12-04 at 11 56 11 am

yairkukielka commented Dec 4, 2015

@samtstern yes, please. This would be great. I have another tricky case with our app:

We have 4 build variants: FreeDev, FreeProd, PaidDev and PaidProd. Each of these variants has a Google Services project, so we have 4 Google Services project ids: Free dev, Free prod, Paid dev and Paid prod.

Is there a way to get only one google-services.json for all these Google Services projects? If I had only one Google Services account with multiple flavors (package names) I see that I could apply what @chrisjenx is saying, but how do I achieve that for different Google Services projects?

If it's not possible, how should I use different google-services.json files in my local project?

This is what I see when I try to enable Google Services for my app:
screen shot 2015-12-04 at 11 56 11 am

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Dec 4, 2015

Member

@yairkukielka there is no way (and there probably never will be) to get one google-services.json file for multiple distinct projects. However with build flavor support you would just have four google-services iles and it would look something like this:

app/
  src/
    FreeDev/google-services.json
    FreeProd/google-services.json
    PaidDev/google-services.json
    PaidDev/google-services.json
Member

samtstern commented Dec 4, 2015

@yairkukielka there is no way (and there probably never will be) to get one google-services.json file for multiple distinct projects. However with build flavor support you would just have four google-services iles and it would look something like this:

app/
  src/
    FreeDev/google-services.json
    FreeProd/google-services.json
    PaidDev/google-services.json
    PaidDev/google-services.json
@yairkukielka

This comment has been minimized.

Show comment
Hide comment
@yairkukielka

yairkukielka Dec 5, 2015

ok, Thank you Sam!

I thought the plugin only worked when the google-services.json file was placed on the /app root folder. It it works placing the google-services.json file in every flavour's folder, that's not a big deal :)

yairkukielka commented Dec 5, 2015

ok, Thank you Sam!

I thought the plugin only worked when the google-services.json file was placed on the /app root folder. It it works placing the google-services.json file in every flavour's folder, that's not a big deal :)

@ajfclark

This comment has been minimized.

Show comment
Hide comment
@ajfclark

ajfclark Dec 5, 2015

@yairkukielka That's what we're asking for, not what's currently supported.

ajfclark commented Dec 5, 2015

@yairkukielka That's what we're asking for, not what's currently supported.

@yairkukielka

This comment has been minimized.

Show comment
Hide comment
@yairkukielka

yairkukielka Dec 5, 2015

I see... In that case, +1 to this issue. Flavor support would be very interesting.

yairkukielka commented Dec 5, 2015

I see... In that case, +1 to this issue. Flavor support would be very interesting.

@stsandro

This comment has been minimized.

Show comment
Hide comment
@stsandro

stsandro Dec 9, 2015

Wow, implementing/including Google Play Services has really become complicated since the last time I've done some Android development!
+1 for this issue! I need this to build multiple apps with different app-ids from the same code base!

stsandro commented Dec 9, 2015

Wow, implementing/including Google Play Services has really become complicated since the last time I've done some Android development!
+1 for this issue! I need this to build multiple apps with different app-ids from the same code base!

@chrisjenx

This comment has been minimized.

Show comment
Hide comment
@chrisjenx

chrisjenx Dec 9, 2015

I think another work around for now would be to create a "core" module which is effectively a library project.
Then create child projects which have their own google-services.json

core
|- freedev
|- freeprod
|- paiddev
|- paidprod

By no means a "good" solution but that would let you do what you need for now.

chrisjenx commented Dec 9, 2015

I think another work around for now would be to create a "core" module which is effectively a library project.
Then create child projects which have their own google-services.json

core
|- freedev
|- freeprod
|- paiddev
|- paidprod

By no means a "good" solution but that would let you do what you need for now.

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Dec 9, 2015

Member

There is a workaround for all of this, which involves not using the
google-services plugin at all and just recreating what it would do. The
plugin is meant to be a convenience and it doesn't do anything you can't do
yourself.

The main thing it does is create R.string.google_app_id using the value of
the "mobilesdk_app_id" field from the JSON file.

The other things it does are optional and depend on the APIs you're using.
If you're using GCM it creates R.string.gcm_default_senderId and if you're
using Ads it creates R.xml.global_tracker. If you need these resources,
you can simply create them yourselves.

Most of the other data in the JSON file is not currently used by the plugin
so you can get away with just creating the resources you need in each build
flavor you need them. The plugin does not affect any of your project's
Java code and your app will run fine without it.

On Wed, Dec 9, 2015, 7:08 AM Christopher Jenkins notifications@github.com
wrote:

I think another work around for now would be to create a "core" module
which is effectively a library project.
Then create child projects which have their own google-services.json

/ core
|- / freedev
|- / freeprod
|- / paiddev
|- / paidprod

By no means a "good" solution but that would let you do what you need for
now.


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

Member

samtstern commented Dec 9, 2015

There is a workaround for all of this, which involves not using the
google-services plugin at all and just recreating what it would do. The
plugin is meant to be a convenience and it doesn't do anything you can't do
yourself.

The main thing it does is create R.string.google_app_id using the value of
the "mobilesdk_app_id" field from the JSON file.

The other things it does are optional and depend on the APIs you're using.
If you're using GCM it creates R.string.gcm_default_senderId and if you're
using Ads it creates R.xml.global_tracker. If you need these resources,
you can simply create them yourselves.

Most of the other data in the JSON file is not currently used by the plugin
so you can get away with just creating the resources you need in each build
flavor you need them. The plugin does not affect any of your project's
Java code and your app will run fine without it.

On Wed, Dec 9, 2015, 7:08 AM Christopher Jenkins notifications@github.com
wrote:

I think another work around for now would be to create a "core" module
which is effectively a library project.
Then create child projects which have their own google-services.json

/ core
|- / freedev
|- / freeprod
|- / paiddev
|- / paidprod

By no means a "good" solution but that would let you do what you need for
now.


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

@chrisjenx

This comment has been minimized.

Show comment
Hide comment
@chrisjenx

chrisjenx Dec 9, 2015

@samtstern OK great, thats good to know, thanks for that!

chrisjenx commented Dec 9, 2015

@samtstern OK great, thats good to know, thanks for that!

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Dec 18, 2015

Member

Good News Everyone

As of the build com.google.gms:google-services:2.0.0-alpha3 you should be able to put your google-services.json file inside your build flavors directories like this:

app/src/
    flavor1/google-services.json
    flavor2/google-services.json

I will leave this issue open so that we can collect feedback on whether or not this solves your problems. Thanks for your patience thus far.

Member

samtstern commented Dec 18, 2015

Good News Everyone

As of the build com.google.gms:google-services:2.0.0-alpha3 you should be able to put your google-services.json file inside your build flavors directories like this:

app/src/
    flavor1/google-services.json
    flavor2/google-services.json

I will leave this issue open so that we can collect feedback on whether or not this solves your problems. Thanks for your patience thus far.

@sregg

This comment has been minimized.

Show comment
Hide comment
@sregg

sregg Dec 24, 2015

This is still not working for me.
I have app/src/debug/google-services.json and app/src/release/google-services.json and the plugin is still complaining that google-services.json is missing in the root folder.
(using com.google.gms:google-services:2.0.0-alpha3)

sregg commented Dec 24, 2015

This is still not working for me.
I have app/src/debug/google-services.json and app/src/release/google-services.json and the plugin is still complaining that google-services.json is missing in the root folder.
(using com.google.gms:google-services:2.0.0-alpha3)

@m-i-k-e-e

This comment has been minimized.

Show comment
Hide comment
@m-i-k-e-e

m-i-k-e-e Dec 30, 2015

@sregg probably because you're not using flavors but buildTypes

m-i-k-e-e commented Dec 30, 2015

@sregg probably because you're not using flavors but buildTypes

@renejahn

This comment has been minimized.

Show comment
Hide comment
@renejahn

renejahn Jan 6, 2016

So I understand that this could help me with flavors. But in our gradle configuration the dev buildType adds ".dev" to the package name which does not match the package name of google-services.json. Also I have no place for buildType specific google-services.json files. So how do I handle flavors and buildTypes which both append something to the package name?

renejahn commented Jan 6, 2016

So I understand that this could help me with flavors. But in our gradle configuration the dev buildType adds ".dev" to the package name which does not match the package name of google-services.json. Also I have no place for buildType specific google-services.json files. So how do I handle flavors and buildTypes which both append something to the package name?

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Jan 8, 2016

Member

Here is the more official google-services document, as promised:
https://developers.google.com/android/guides/google-services-plugin

I hope that answers many of the questions on this thread. If it does not, feedback appreciated.

(Comment edited 1/8/2016 at 9:31am)

Member

samtstern commented Jan 8, 2016

Here is the more official google-services document, as promised:
https://developers.google.com/android/guides/google-services-plugin

I hope that answers many of the questions on this thread. If it does not, feedback appreciated.

(Comment edited 1/8/2016 at 9:31am)

@sregg

This comment has been minimized.

Show comment
Hide comment
@sregg

sregg Jan 8, 2016

Thanks Sam but that link looks like a private Google link (it asks for username/password)...

sregg commented Jan 8, 2016

Thanks Sam but that link looks like a private Google link (it asks for username/password)...

@sregg

This comment has been minimized.

Show comment
Hide comment
@sregg

sregg Jan 8, 2016

I'm guessing the correct URL is: https://developers.google.com/android/guides/google-services-plugin

@samtstern so there is no way to use buildTypes (debug/release) instead of flavors?

sregg commented Jan 8, 2016

I'm guessing the correct URL is: https://developers.google.com/android/guides/google-services-plugin

@samtstern so there is no way to use buildTypes (debug/release) instead of flavors?

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Jan 8, 2016

Member

Whoops yes: https://developers.google.com/android/guides/google-services-plugin

I accidentally linked to the internal server, sorry about that! I am going to edit the original comment as well, for clarity.

Member

samtstern commented Jan 8, 2016

Whoops yes: https://developers.google.com/android/guides/google-services-plugin

I accidentally linked to the internal server, sorry about that! I am going to edit the original comment as well, for clarity.

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Jan 8, 2016

Member

I think the terminology in this thread has been incorrect the whole time (which is partially my fault, I had been saying build type/build variant/product flavor interchangeably).

I am getting my terminology from here: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants

If you check out the linked document, you will see that build types are supported (and probably what I meant to be saying all along when I said build flavor).

Member

samtstern commented Jan 8, 2016

I think the terminology in this thread has been incorrect the whole time (which is partially my fault, I had been saying build type/build variant/product flavor interchangeably).

I am getting my terminology from here: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants

If you check out the linked document, you will see that build types are supported (and probably what I meant to be saying all along when I said build flavor).

@sregg

This comment has been minimized.

Show comment
Hide comment
@sregg

sregg Jan 8, 2016

I see, does that mean that you guys changed something recently?
Because 15 days ago it wasn't working: #54 (comment)

sregg commented Jan 8, 2016

I see, does that mean that you guys changed something recently?
Because 15 days ago it wasn't working: #54 (comment)

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Jan 8, 2016

Member

Ah I see. Can you try putting google-services.json in the app/ folder as well? I think if you have it in all three locations (app/src/release, app/src/debug and app/) the plugin will actually always ignore the root one, but it may just be complaining that one does not exist there.

Either way I will file a bug to get something fixed. If it all works for you, then the bug is simple (don't require a root json file when there are type-specific ones). If it does not all work for you, then we will have to look for a root cause.

Member

samtstern commented Jan 8, 2016

Ah I see. Can you try putting google-services.json in the app/ folder as well? I think if you have it in all three locations (app/src/release, app/src/debug and app/) the plugin will actually always ignore the root one, but it may just be complaining that one does not exist there.

Either way I will file a bug to get something fixed. If it all works for you, then the bug is simple (don't require a root json file when there are type-specific ones). If it does not all work for you, then we will have to look for a root cause.

@sregg

This comment has been minimized.

Show comment
Hide comment
@sregg

sregg Jan 8, 2016

Awesome!
I'll try again and let you know how it goes.
I'll also try with proper flavors and se if that works fine.

sregg commented Jan 8, 2016

Awesome!
I'll try again and let you know how it goes.
I'll also try with proper flavors and se if that works fine.

@viralypatel

This comment has been minimized.

Show comment
Hide comment
@viralypatel

viralypatel Jan 25, 2016

I'm using four different build types as follows:

buildTypes {
    releasefree.initWith(buildTypes.release)
    releasefree {
        minifyEnabled true
        shrinkResources true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
    releasepro.initWith(buildTypes.release)
    releasepro {
        minifyEnabled true
        shrinkResources true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        applicationIdSuffix ".pro"
    }
    debugfree.initWith(buildTypes.debug)
    debugfree {
        shrinkResources true
        applicationIdSuffix ".debug"
        debuggable true
    }
    debugpro.initWith(buildTypes.debug)
    debugpro {
        shrinkResources true
        applicationIdSuffix ".pro.debug"
        debuggable true
    }
}

With build variant for ReleaseFree (for one of the product flavors) selected, I Tried adding the google-services.json at

src\release as well as at src\releasefree

Still complains about the json missing from the root module folder. What am i missing?

And can i also put it directly into src\flavor1 or src\flavor2? each build variant has a unique applicationId. tried and wasn't working.

viralypatel commented Jan 25, 2016

I'm using four different build types as follows:

buildTypes {
    releasefree.initWith(buildTypes.release)
    releasefree {
        minifyEnabled true
        shrinkResources true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
    releasepro.initWith(buildTypes.release)
    releasepro {
        minifyEnabled true
        shrinkResources true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        applicationIdSuffix ".pro"
    }
    debugfree.initWith(buildTypes.debug)
    debugfree {
        shrinkResources true
        applicationIdSuffix ".debug"
        debuggable true
    }
    debugpro.initWith(buildTypes.debug)
    debugpro {
        shrinkResources true
        applicationIdSuffix ".pro.debug"
        debuggable true
    }
}

With build variant for ReleaseFree (for one of the product flavors) selected, I Tried adding the google-services.json at

src\release as well as at src\releasefree

Still complains about the json missing from the root module folder. What am i missing?

And can i also put it directly into src\flavor1 or src\flavor2? each build variant has a unique applicationId. tried and wasn't working.

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Jan 25, 2016

Member

@viralypatel this is a known issue, just make a copy of google-services.json and put it in the app/ folder (that's what the plugin means by the module root folder).

We will release a version soon that fixes this issue.

Member

samtstern commented Jan 25, 2016

@viralypatel this is a known issue, just make a copy of google-services.json and put it in the app/ folder (that's what the plugin means by the module root folder).

We will release a version soon that fixes this issue.

@datrixo

This comment has been minimized.

Show comment
Hide comment
@datrixo

datrixo Jan 27, 2016

One step closer. But what in the situation when I have for example GA tracking_id per localization folder.
For example:

  • xml-bg/local_tracker.xml (where is ga_trackingId)
  • xml-pl/local_tracker.xml (where is ga_trackingId)

Unfortunetly google-services.json have "analytics_service" object, where the tracking_id is set per flavor, not per localization.

Any solutions?

datrixo commented Jan 27, 2016

One step closer. But what in the situation when I have for example GA tracking_id per localization folder.
For example:

  • xml-bg/local_tracker.xml (where is ga_trackingId)
  • xml-pl/local_tracker.xml (where is ga_trackingId)

Unfortunetly google-services.json have "analytics_service" object, where the tracking_id is set per flavor, not per localization.

Any solutions?

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Jan 27, 2016

Member

@datrixo I don't think the plugin will be able to support per-region configuration as that information is not (and likely will not be) contained in the JSON file.

In your case I would recommend not using the google-services plugin and just continuing manually as you would have before. If there is any service other than Analytics that you use that will require the google services plugin, you can read this guide to figure out how to recreate the work manually.

Member

samtstern commented Jan 27, 2016

@datrixo I don't think the plugin will be able to support per-region configuration as that information is not (and likely will not be) contained in the JSON file.

In your case I would recommend not using the google-services plugin and just continuing manually as you would have before. If there is any service other than Analytics that you use that will require the google services plugin, you can read this guide to figure out how to recreate the work manually.

@ThaDilz

This comment has been minimized.

Show comment
Hide comment
@ThaDilz

ThaDilz Apr 1, 2016

@samtstern This presents a big problem for me as well. I use different projects between debug and release build types, so I can't use a single json file because their project_info sections differ. Everything I've read, including the official documentation (https://developers.google.com/android/guides/google-services-plugin#adding_the_json_file) says that build types are supported, but the end result is always the missing from module root folder error. I'm using com.google.gms:google-services:2.1.0-alpha5, but I've also tried several other versions, including com.google.gms:google-services:2.0.0-alpha3, which the documentation specifically mentions being the release that added support for different json files by build type.

ThaDilz commented Apr 1, 2016

@samtstern This presents a big problem for me as well. I use different projects between debug and release build types, so I can't use a single json file because their project_info sections differ. Everything I've read, including the official documentation (https://developers.google.com/android/guides/google-services-plugin#adding_the_json_file) says that build types are supported, but the end result is always the missing from module root folder error. I'm using com.google.gms:google-services:2.1.0-alpha5, but I've also tried several other versions, including com.google.gms:google-services:2.0.0-alpha3, which the documentation specifically mentions being the release that added support for different json files by build type.

@MichaelEvans

This comment has been minimized.

Show comment
Hide comment

MichaelEvans commented Apr 1, 2016

I wrote up a blog post about a possible workaround here: http://michaelevans.org/blog/2016/03/31/using-build-types-with-the-google-services-gradle-plugin/

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Apr 1, 2016

Member

Ok I have to apologize here, I have misled some people on this thread. I have been using an internal build of the plugin which I assumed was the same as external but apparently there is a commit I have that you don't. So a few things:

  1. Thank you to everyone who has continued to report this. This will definitely be fixed in the next release of the plugin, I will make sure that commit gets in.
  2. The current release supports flavors but not types. So if you create a productflavor (say call it free and another paid) and put the json file in src/$flavorname it will work in the current release. I understand this is extra effort but it's at least something you can do right now.
  3. @MichaelEvans has posted a pretty nifty workaround, good stuff! I haven't tried it but reading the code it looks like it should work if you don't want to use flavors.

Again I apologize for all of the miscommunication so far, I hope this update clears some of the confusion.

Member

samtstern commented Apr 1, 2016

Ok I have to apologize here, I have misled some people on this thread. I have been using an internal build of the plugin which I assumed was the same as external but apparently there is a commit I have that you don't. So a few things:

  1. Thank you to everyone who has continued to report this. This will definitely be fixed in the next release of the plugin, I will make sure that commit gets in.
  2. The current release supports flavors but not types. So if you create a productflavor (say call it free and another paid) and put the json file in src/$flavorname it will work in the current release. I understand this is extra effort but it's at least something you can do right now.
  3. @MichaelEvans has posted a pretty nifty workaround, good stuff! I haven't tried it but reading the code it looks like it should work if you don't want to use flavors.

Again I apologize for all of the miscommunication so far, I hope this update clears some of the confusion.

@adrien-aubel

This comment has been minimized.

Show comment
Hide comment
@adrien-aubel

adrien-aubel Apr 1, 2016

@samthor Additionally, this doesn't work with multi-flavor variants.

If I have:

    flavorDimensions 'flavors', 'api'

    productFlavors {
        a {
            dimension 'flavors'
            applicationId 'com.android.a'
        }

        b {
            dimension 'flavors'
            applicationId 'com.android.b'
        }

        standard {
            dimension 'api'
            minSdkVersion 16
        }

        modern {
            // Setting minSdkVersion to 5+ allows us to use Pre Dex and Live Run
            dimension 'api'
            minSdkVersion 21
        }
    }

I have to copy my google-services.json file in both src/aModern/ and src/aStandard/.

The Google Play Services Gradle plugin (2.1.0-alpha5) traverses src/aModern/ but not src/a/, before falling back to src/main/.

The sources and resources processes do traverse both src/a/ after src/aModern/.

adrien-aubel commented Apr 1, 2016

@samthor Additionally, this doesn't work with multi-flavor variants.

If I have:

    flavorDimensions 'flavors', 'api'

    productFlavors {
        a {
            dimension 'flavors'
            applicationId 'com.android.a'
        }

        b {
            dimension 'flavors'
            applicationId 'com.android.b'
        }

        standard {
            dimension 'api'
            minSdkVersion 16
        }

        modern {
            // Setting minSdkVersion to 5+ allows us to use Pre Dex and Live Run
            dimension 'api'
            minSdkVersion 21
        }
    }

I have to copy my google-services.json file in both src/aModern/ and src/aStandard/.

The Google Play Services Gradle plugin (2.1.0-alpha5) traverses src/aModern/ but not src/a/, before falling back to src/main/.

The sources and resources processes do traverse both src/a/ after src/aModern/.

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Apr 4, 2016

Member

@adrien-aubel you're right, currently you do need a JSON file for each combined flavor. I will put that in as a feature request.

Member

samtstern commented Apr 4, 2016

@adrien-aubel you're right, currently you do need a JSON file for each combined flavor. I will put that in as a feature request.

@AlbertVilaCalvo

This comment has been minimized.

Show comment
Hide comment
@AlbertVilaCalvo

AlbertVilaCalvo Apr 7, 2016

@samtstern do you have an estimate of when the next release of the plugin will happen? I can wait for the support of build types. I just want to have an idea of when it will be available.

AlbertVilaCalvo commented Apr 7, 2016

@samtstern do you have an estimate of when the next release of the plugin will happen? I can wait for the support of build types. I just want to have an idea of when it will be available.

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Apr 7, 2016

Member

The plugin is actually part of the Android Studio source tree which means it's released with (and versioned with) Android Studio releases.

The best way to track this is to watch this page: https://bintray.com/android/android-tools/com.google.gms.google-services/view

The latest is 2.0.0-rc3 which does not have the fix applied. I expect the next release will. This tends to happen on about a weekly pace but in the end it's up to the Studio team.

Member

samtstern commented Apr 7, 2016

The plugin is actually part of the Android Studio source tree which means it's released with (and versioned with) Android Studio releases.

The best way to track this is to watch this page: https://bintray.com/android/android-tools/com.google.gms.google-services/view

The latest is 2.0.0-rc3 which does not have the fix applied. I expect the next release will. This tends to happen on about a weekly pace but in the end it's up to the Studio team.

@MichaelEvans

This comment has been minimized.

Show comment
Hide comment
@MichaelEvans

MichaelEvans Apr 7, 2016

@samtstern How about 2.0 that just came out? 😛

MichaelEvans commented Apr 7, 2016

@samtstern How about 2.0 that just came out? 😛

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Apr 7, 2016

Member

@MichaelEvans unfortunately the 2.0.0 branches are purposely lagging since they're release candidates and they try to test the changes for a while. Look for the change in a 2.1.* release, I will update this thread as soon as I know for sure which one.

In the long term we'd like to get this plugin decoupled from Android Studio since the release schedules should be unrelated.

Member

samtstern commented Apr 7, 2016

@MichaelEvans unfortunately the 2.0.0 branches are purposely lagging since they're release candidates and they try to test the changes for a while. Look for the change in a 2.1.* release, I will update this thread as soon as I know for sure which one.

In the long term we'd like to get this plugin decoupled from Android Studio since the release schedules should be unrelated.

@shehabic

This comment has been minimized.

Show comment
Hide comment
@shehabic

shehabic Apr 9, 2016

In my project I have multiple flavors and multiple build-type so I placed my files as follows:

  • app/google-services.json <-- just to avoid errors from the plugin (File with dummy project_number)
  • app/src/debug/flavor1/google-services.json <-- the file and project for flavor 1 Debug.
  • app/src/debug/flavor2/google-services.json <-- the file and project for flavor 2 Debug
  • app/src/release/flavor1/google-services.json <-- the file and project for flavor 1 Release.
  • app/src/release/flavor2/google-services.json <-- the file and project for flavor 2 Release.

also tried creating the folders as:

  • app/src/flavor1Debug/google-services.json
  • app/src/flavor2Debug/google-services.json
    .
    .
    etc

now when checking the generated files I see that the "clients" are taken properly from the folders, BUT the project_number *(Which is also the GCM Sender Id) is taken from the file on the root (i.e. the "project_number")

Given: I have created 4 projects in Google Play Services Console/Dashboard (1 per flavor's build).

shehabic commented Apr 9, 2016

In my project I have multiple flavors and multiple build-type so I placed my files as follows:

  • app/google-services.json <-- just to avoid errors from the plugin (File with dummy project_number)
  • app/src/debug/flavor1/google-services.json <-- the file and project for flavor 1 Debug.
  • app/src/debug/flavor2/google-services.json <-- the file and project for flavor 2 Debug
  • app/src/release/flavor1/google-services.json <-- the file and project for flavor 1 Release.
  • app/src/release/flavor2/google-services.json <-- the file and project for flavor 2 Release.

also tried creating the folders as:

  • app/src/flavor1Debug/google-services.json
  • app/src/flavor2Debug/google-services.json
    .
    .
    etc

now when checking the generated files I see that the "clients" are taken properly from the folders, BUT the project_number *(Which is also the GCM Sender Id) is taken from the file on the root (i.e. the "project_number")

Given: I have created 4 projects in Google Play Services Console/Dashboard (1 per flavor's build).

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Apr 13, 2016

Member

Hi all,

I have just confirmed and the changes made it into com.google.gms:google-services:2.1.0-beta1. Please give that a try and let me know if it works for your various use cases. Your reports and patience so far are greatly appreciated.

Member

samtstern commented Apr 13, 2016

Hi all,

I have just confirmed and the changes made it into com.google.gms:google-services:2.1.0-beta1. Please give that a try and let me know if it works for your various use cases. Your reports and patience so far are greatly appreciated.

@bskim45

This comment has been minimized.

Show comment
Hide comment
@bskim45

bskim45 Apr 13, 2016

@samtstern Works perfectly. Thanks.

bskim45 commented Apr 13, 2016

@samtstern Works perfectly. Thanks.

@shehabic

This comment has been minimized.

Show comment
Hide comment
@shehabic

shehabic Apr 13, 2016

@samtstern does this include reading the json from Flavor+Build combination ?
src/flavor1Debug/google-service.json
.
.
src/flavor2Release/google-service.json
etc

shehabic commented Apr 13, 2016

@samtstern does this include reading the json from Flavor+Build combination ?
src/flavor1Debug/google-service.json
.
.
src/flavor2Release/google-service.json
etc

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Apr 13, 2016

Member

@shehabix not quite but there is equivalent behavior:

Let's say you have flavor foo and build type release. The plugin looks in the following locations (in this order) and stops when it finds a google-services.json file:

  • app/src/foo/release/google-services.json
  • app/src/foo/google-services.json
  • app/src/release/google-services.json
  • app/google-services.json
Member

samtstern commented Apr 13, 2016

@shehabix not quite but there is equivalent behavior:

Let's say you have flavor foo and build type release. The plugin looks in the following locations (in this order) and stops when it finds a google-services.json file:

  • app/src/foo/release/google-services.json
  • app/src/foo/google-services.json
  • app/src/release/google-services.json
  • app/google-services.json
@shehabic

This comment has been minimized.

Show comment
Hide comment
@shehabic

shehabic Apr 13, 2016

@samtstern thanks a lot for clarifying it

shehabic commented Apr 13, 2016

@samtstern thanks a lot for clarifying it

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Apr 13, 2016

Member

I believe we can finally close this issue as the feature has been implemented. Thanks all!

Member

samtstern commented Apr 13, 2016

I believe we can finally close this issue as the feature has been implemented. Thanks all!

@samtstern samtstern closed this Apr 13, 2016

@rjam

This comment has been minimized.

Show comment
Hide comment
@rjam

rjam Apr 15, 2016

@samtstern I'm still faced with the same issue as @adrien-aubel regarding multi-flavor variants..Any place where we can track the implementation of that feature?

rjam commented Apr 15, 2016

@samtstern I'm still faced with the same issue as @adrien-aubel regarding multi-flavor variants..Any place where we can track the implementation of that feature?

@jvanderwee

This comment has been minimized.

Show comment
Hide comment
@jvanderwee

jvanderwee Jun 1, 2016

Has a feature request been raised for this issue?

jvanderwee commented Jun 1, 2016

Has a feature request been raised for this issue?

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Jun 1, 2016

Member

@jvanderwee we have seen that request and logged a FR, no hard timeline on when that will be a part of the plugin. Thanks for following up.

Member

samtstern commented Jun 1, 2016

@jvanderwee we have seen that request and logged a FR, no hard timeline on when that will be a part of the plugin. Thanks for following up.

@jeffreydelooff

This comment has been minimized.

Show comment
Hide comment
@jeffreydelooff

jeffreydelooff Jun 2, 2016

My current set-up includes flavors with custom root directories specified in the sourceSets:

{flavor}.setRoot("src/environments/{flavor}")

However, the google services plugin doesn't look in those folders. Will this be supported in the future or is there a way to have the project.file resolving of "google-services.json" also look into these custom root directories?

jeffreydelooff commented Jun 2, 2016

My current set-up includes flavors with custom root directories specified in the sourceSets:

{flavor}.setRoot("src/environments/{flavor}")

However, the google services plugin doesn't look in those folders. Will this be supported in the future or is there a way to have the project.file resolving of "google-services.json" also look into these custom root directories?

@schopy

This comment has been minimized.

Show comment
Hide comment
@schopy

schopy Jul 4, 2016

@samtstern We don't have multiple flavors on our app, but we do have multiple build types. I can see multiple apps in the Firebase console, one per build type. Is there a point in having a google-services.json file per build type considering that the files are identical and they contain multiple client entries, one for each build type? And do you know why ads_service has a status 1 by default?

schopy commented Jul 4, 2016

@samtstern We don't have multiple flavors on our app, but we do have multiple build types. I can see multiple apps in the Firebase console, one per build type. Is there a point in having a google-services.json file per build type considering that the files are identical and they contain multiple client entries, one for each build type? And do you know why ads_service has a status 1 by default?

@samtstern

This comment has been minimized.

Show comment
Hide comment
@samtstern

samtstern Jul 4, 2016

Member

If you don't need the build types to behave differently with respect to
Google/Firebase then there's no reason to have multiple JSON files.

As for ads service I believe that's just because the back end has been set
up for you already if you decide to use AdMob. If you're not using the
AdMob SDK nothing will happen due to that value.

On Mon, Jul 4, 2016, 8:43 AM schopy notifications@github.com wrote:

@samtstern https://github.com/samtstern We don't have multiple flavors
on our app, but we do have multiple build types. I can see multiple apps in
the Firebase console, one per build type. Is there a point in having a
google-services.json file per build type considering that the files are
identical and they contain multiple client entries, one for each build
type? And do you know why ads_service has a status 1 by default?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#54 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AIEw6g627p66Cp6Z7p6uBzXYl7OD1C5Lks5qSSobgaJpZM4F1F4I
.

Member

samtstern commented Jul 4, 2016

If you don't need the build types to behave differently with respect to
Google/Firebase then there's no reason to have multiple JSON files.

As for ads service I believe that's just because the back end has been set
up for you already if you decide to use AdMob. If you're not using the
AdMob SDK nothing will happen due to that value.

On Mon, Jul 4, 2016, 8:43 AM schopy notifications@github.com wrote:

@samtstern https://github.com/samtstern We don't have multiple flavors
on our app, but we do have multiple build types. I can see multiple apps in
the Firebase console, one per build type. Is there a point in having a
google-services.json file per build type considering that the files are
identical and they contain multiple client entries, one for each build
type? And do you know why ads_service has a status 1 by default?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#54 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AIEw6g627p66Cp6Z7p6uBzXYl7OD1C5Lks5qSSobgaJpZM4F1F4I
.

phil-lopreiato added a commit to the-blue-alliance/the-blue-alliance-android that referenced this issue Jul 11, 2016

Tweak google-services and VCS
Move the default google-services.json (so fresh clones and travis can
build because the gradle plugin requires the file to be present) to the
lowest priority location, and ensure that the flavor-specific locations
are ignored. This way, prod builds can have its file in
android/src/prod/ and a debug build pointing to a dev instance can have
one in android/src/debug/

See this comment:
googlesamples/google-services#54 (comment)
for the order of file location searches
@localhostEU

This comment has been minimized.

Show comment
Hide comment
@localhostEU

localhostEU Oct 28, 2016

What if i want to use different google-services.json within 1 flavor? (my app should be able to dynamically switch environments - each environment is a seperate Google Project).

localhostEU commented Oct 28, 2016

What if i want to use different google-services.json within 1 flavor? (my app should be able to dynamically switch environments - each environment is a seperate Google Project).

@originx

This comment has been minimized.

Show comment
Hide comment
@originx

originx Oct 28, 2016

Is there any way to raise prio on #54 (comment)

Like this it would be much easier to have a clean setup per dimension, especially if they are separate firebase projects.

Another alternative would be combining all projects and apps into 1 google-json file but I believe supporting fallback to dimensions before going to main would solve all flavor type issues.

or ability to define google-json file location per product flavor config which would override default file traversal algorithm

originx commented Oct 28, 2016

Is there any way to raise prio on #54 (comment)

Like this it would be much easier to have a clean setup per dimension, especially if they are separate firebase projects.

Another alternative would be combining all projects and apps into 1 google-json file but I believe supporting fallback to dimensions before going to main would solve all flavor type issues.

or ability to define google-json file location per product flavor config which would override default file traversal algorithm

@filipmaelbrancke

This comment has been minimized.

Show comment
Hide comment
@filipmaelbrancke

filipmaelbrancke Jan 4, 2017

@localhostEU : I arrived at this issue looking for a solution to the same problem, and I'd like to point out that there is some information now: https://firebase.googleblog.com/2016/12/working-with-multiple-firebase-projects-in-an-android-app.html

filipmaelbrancke commented Jan 4, 2017

@localhostEU : I arrived at this issue looking for a solution to the same problem, and I'd like to point out that there is some information now: https://firebase.googleblog.com/2016/12/working-with-multiple-firebase-projects-in-an-android-app.html

@ElineDeMeyer

This comment has been minimized.

Show comment
Hide comment
@ElineDeMeyer

ElineDeMeyer Jan 16, 2017

Is there already a solution for this issue?

ElineDeMeyer commented Jan 16, 2017

Is there already a solution for this issue?

@cubbuk

This comment has been minimized.

Show comment
Hide comment
@cubbuk

cubbuk Jan 24, 2017

I just need to create 2 flavors for staging and production. I created folders under src respectively and copied google-services.json under folders src/staging and src/production. Each google-services.json under flavor directories contains correct package name for android_client_info i.e. com.myapp.staging or com.myapp.production. However rest of the json files are same i.e. using same api_key etc, only the package name changes according to the flavor name. Do I need to generate new json files from developer console for each flavor, or just changing the package name of each json file is enough? Thanks

cubbuk commented Jan 24, 2017

I just need to create 2 flavors for staging and production. I created folders under src respectively and copied google-services.json under folders src/staging and src/production. Each google-services.json under flavor directories contains correct package name for android_client_info i.e. com.myapp.staging or com.myapp.production. However rest of the json files are same i.e. using same api_key etc, only the package name changes according to the flavor name. Do I need to generate new json files from developer console for each flavor, or just changing the package name of each json file is enough? Thanks

@Cassio90

This comment has been minimized.

Show comment
Hide comment
@Cassio90

Cassio90 Aug 22, 2017

I'm also looking for a solution to scanning non-combined flavor dimension folders as described here.
Is this feature planned?

Cassio90 commented Aug 22, 2017

I'm also looking for a solution to scanning non-combined flavor dimension folders as described here.
Is this feature planned?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 27, 2017

For the issue from comment #204587543:

Google is solving the world problems. They're sending their engineers around NASA, Tesla, Whit House to tackle world problems. Last time I heard, they were building smart condoms. Next API for you Android devs would be Condom Wearable.

Again, what do your tiny projects mean to Google? => null/NPE/NullPointerException

No one likes NullPointerException. That's my honest advice.

When I say "honest", I have workaround:

First, add *.json to your .gitignore.

Then:

applicationVariants.all { variant ->
    // Verify your dimension if needed
    if (variant.productFlavors[-1].dimension != 'xxx') return

    // Here's your original json file
    def orgJsonFile = new File(project.projectDir, ...)

    // Here's the temp file
    def tmpJsonFile = new File(project.projectDir, "src/${variant.dirName}/google-services.json")

    // Check to make directory if not existed: tmpJsonFile.parentFile
    // For any parent directory that you make, call #deleteOnExit()

    if (you're on Linux)
        java.nio.file.Files.createSymbolicLink(tmpJsonFile.toPath(), orgJsonFile.toPath())
    else
        tmpJsonFile.text = orgJsonFile.text()

    // Finally:
    tmpJsonFile.deleteOnExit()
}

ghost commented Nov 27, 2017

For the issue from comment #204587543:

Google is solving the world problems. They're sending their engineers around NASA, Tesla, Whit House to tackle world problems. Last time I heard, they were building smart condoms. Next API for you Android devs would be Condom Wearable.

Again, what do your tiny projects mean to Google? => null/NPE/NullPointerException

No one likes NullPointerException. That's my honest advice.

When I say "honest", I have workaround:

First, add *.json to your .gitignore.

Then:

applicationVariants.all { variant ->
    // Verify your dimension if needed
    if (variant.productFlavors[-1].dimension != 'xxx') return

    // Here's your original json file
    def orgJsonFile = new File(project.projectDir, ...)

    // Here's the temp file
    def tmpJsonFile = new File(project.projectDir, "src/${variant.dirName}/google-services.json")

    // Check to make directory if not existed: tmpJsonFile.parentFile
    // For any parent directory that you make, call #deleteOnExit()

    if (you're on Linux)
        java.nio.file.Files.createSymbolicLink(tmpJsonFile.toPath(), orgJsonFile.toPath())
    else
        tmpJsonFile.text = orgJsonFile.text()

    // Finally:
    tmpJsonFile.deleteOnExit()
}
@bskim45

This comment has been minimized.

Show comment
Hide comment
@bskim45

bskim45 Nov 27, 2017

@ghost
App developers are also engineers managing to solve world problems in different dimensions.
Its funny that those projects are treated as 'tiny projects' 🙃

bskim45 commented Nov 27, 2017

@ghost
App developers are also engineers managing to solve world problems in different dimensions.
Its funny that those projects are treated as 'tiny projects' 🙃

@toxxmeister

This comment has been minimized.

Show comment
Hide comment
@toxxmeister

toxxmeister Feb 14, 2018

My current workaround is attaching to the plugin's task and copying the required flavor's JSON to the module's root:

val gmsPattern = Regex("""process([A-Z][a-z]*).*GoogleServices""")
tasks.withType<GoogleServicesTask> {
    gmsPattern.matchEntire(name)?.destructured?.let { (flavor) ->
        doFirst {
            copy {
                from("src/${flavor.toLowerCase()}/google-services.json")
                into(".")
            }
        }
    }
}

It's written in Gradle Script Kotlin, but it shouldn't be much different in Groovy.

toxxmeister commented Feb 14, 2018

My current workaround is attaching to the plugin's task and copying the required flavor's JSON to the module's root:

val gmsPattern = Regex("""process([A-Z][a-z]*).*GoogleServices""")
tasks.withType<GoogleServicesTask> {
    gmsPattern.matchEntire(name)?.destructured?.let { (flavor) ->
        doFirst {
            copy {
                from("src/${flavor.toLowerCase()}/google-services.json")
                into(".")
            }
        }
    }
}

It's written in Gradle Script Kotlin, but it shouldn't be much different in Groovy.

@jpardogo

This comment has been minimized.

Show comment
Hide comment
@jpardogo

jpardogo Mar 1, 2018

It is solved now in classpath 'com.google.gms:google-services:3.2.0'

https://bintray.com/android/android-tools/com.google.gms.google-services/3.2.0

jpardogo commented Mar 1, 2018

It is solved now in classpath 'com.google.gms:google-services:3.2.0'

https://bintray.com/android/android-tools/com.google.gms.google-services/3.2.0

@flasher297

This comment has been minimized.

Show comment
Hide comment
@flasher297

flasher297 Mar 3, 2018

Oh my god! With 3.2.0 it finally woks. @jpardogo big thanks for flagging!
I have two flavor dimensions an three build types. Moreover there are six Firebase projects,
And henceforth I can avoid copypasting JSON configurations,

flasher297 commented Mar 3, 2018

Oh my god! With 3.2.0 it finally woks. @jpardogo big thanks for flagging!
I have two flavor dimensions an three build types. Moreover there are six Firebase projects,
And henceforth I can avoid copypasting JSON configurations,

@tokou

This comment has been minimized.

Show comment
Hide comment
@tokou

tokou Apr 18, 2018

Thanks for the update.
There's still an issue for flavor names that contain uppercase characters though 🤔
If I have flavors firstFlavor of dimension dim1 and second of dimension dim2, it only looks in the folders first and firstFlavorSecond but not firstFlavor

tokou commented Apr 18, 2018

Thanks for the update.
There's still an issue for flavor names that contain uppercase characters though 🤔
If I have flavors firstFlavor of dimension dim1 and second of dimension dim2, it only looks in the folders first and firstFlavorSecond but not firstFlavor

@jpardogo

This comment has been minimized.

Show comment
Hide comment
@jpardogo

jpardogo Apr 23, 2018

With 2 Flavours dimensions: client & platform.
Log after deleting google-services.json for a client:

Could not find google-services.json while looking in
[

  • mobile/src/client/platform/debug,
  • mobile/src/clientPlatform/debug,
  • mobile/src/debug/clientPlatform,
  • mobile/src/client/debug,
  • mobile/src/client/platform,
  • mobile/src/client/platformDebug,
  • mobile/src/clientPlatform,
  • mobile/src/debug,
  • mobile/src/clientPlatformDebug,
  • mobile/src/client,
  • mobile/src/clientDebug,
  • mobile/
    ]

Those are the paths where the file is searched inside the module.

jpardogo commented Apr 23, 2018

With 2 Flavours dimensions: client & platform.
Log after deleting google-services.json for a client:

Could not find google-services.json while looking in
[

  • mobile/src/client/platform/debug,
  • mobile/src/clientPlatform/debug,
  • mobile/src/debug/clientPlatform,
  • mobile/src/client/debug,
  • mobile/src/client/platform,
  • mobile/src/client/platformDebug,
  • mobile/src/clientPlatform,
  • mobile/src/debug,
  • mobile/src/clientPlatformDebug,
  • mobile/src/client,
  • mobile/src/clientDebug,
  • mobile/
    ]

Those are the paths where the file is searched inside the module.

@huck1eberry

This comment has been minimized.

Show comment
Hide comment
@huck1eberry

huck1eberry Jun 29, 2018

Have the same issue with flavor names containing uppercase characters. Flavor root folder (module/src/<flavour_with_some_uppercase_letters>) is "ignored" by the plugin. The search is performed only within module's root and module/src/<flavour_with_some_uppercase_letter>/debug (or release) folder.

huck1eberry commented Jun 29, 2018

Have the same issue with flavor names containing uppercase characters. Flavor root folder (module/src/<flavour_with_some_uppercase_letters>) is "ignored" by the plugin. The search is performed only within module's root and module/src/<flavour_with_some_uppercase_letter>/debug (or release) folder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment