IssueTracker

Thanks Xav, I just read the details. Do you have a project that shows this error? If not, I can try to set this up. Let's talk about this next week.

It's probably easier to create a small one. I can assist you with that.

Hi Xav, I looked into this and got to this state in a project. I agree with the changes you recommended. This should be a warning and it should be on the consumer (app2) instead of the producer (library).

Just ran into a similar issue and I'm wondering if it's the same. b/232122497

I have working prototype that to change the variant selection conflicts from error to warning and move the fix conflict to the consumer(ag/21747907). But I have a followup questions.

In above case, fixing conflicts for :app2 changes the variant of :library to variant2 to match :app2s variant but this produces a warning on :app1 which depends of variant1 of the :library. Fix action now fixed a conflict(on :app2) but produced another(on :app1). It would be nice if we also changed the :app1s variant to varaint2 to match the downstream dependency if the matching variant exist. Would it be acceptable to do this change in two phases: one where we just fix the conflict of a consumer and second phase where we try to fix variants upstream as well to prevent generating new conflict if possible.

The goal here is not to fix the build setup. There are probably good reasons why the dependencies of both apps are setup that way. We don't want to change that just because Studio has a limitation in how it can handle this setup.

It's just not possible today to make Studio happy about both apps, and that's ok. The goal of making this change is to make it more obvious that this is a limitation of Studio (not being able to have the same submodules loaded as 2 different variants at the same time) and put the warning on the relevant module, ie. the app module that you may be deploying (or not).

BTW we should look at the wording of the warning to make sure it convey the appropriate message.

The messages we display right now do not make much sense.

Xav, while we do not need to fix build we should make it possible to configure conflict resolution, i.e. if you have two parts of a project that in conflict by design, you want to be able to explicitly set where propagation of one variant ends and where the other one begins.

:app
  -> :lib

:test_app
  -> :lib (*the same)

right now the variant from app will win and only because a goes before t. However, changing the variant of t will override the variant of :lib. This is in most cases the right thing to do, but in rare cases it is not and users have no control over it. One basically needs to sync several times hoping to get the right variant selection.

We should consider allowing users to set multiple variant selection anchors manually and then requesting sync that will (1) start propagation from manually set anchors and (2) respect anchors even if they are in conflict with the current selection.

This way (1) it will be clear which variant where requested and which propagated and in cases where conflicts are expected, conflicts can be explicitly resolved at boundaries and (2) variant selection can be applied in one sync even though that in cases it may still be necessary to adjust several drop-downs.

Here is the proposal for wording of the warning(Also see implementation ag/21747907 which is ready to be submitted):

"Only a single variant of a Android Gradle project can be loaded at a time in Android Studio. Dependencies of ${this@variantConflictMessage.displayName} are different to what it expects due to variant conflicts.

Gradle project ${it.dependencyName}(Expected variant: ${it.expectedVariant}, Loaded variant: ${it.actualVariant})"

I will play with it (likely next week) and report back. I do like Yuriy's idea about the anchors.

Im working on a project, and let's say that a producer module has two custom build types, but the module which consumes it doesn't have those buildtypes, so a list of matching fallbacks is added to the consumer module on a particular buildtype of it, theres no warning when the producer module has as active the variant which is the first of the sorted list of matchingfallbacks, but as soon as i change the active producer module variant, consumer module yields a warning that it expected the first variant of the matching fallbacks list, please help