[FR] Android dependencies should target main gradle or launcher template.

[toxikman]

Feature proposal

• EDM4U Component: Android Resolver

Since Unity 2019.3, they changed their build system to build the main project as library. There are now 3 gradle scripts, base, launcher and main library. EDM4U still does library resolving on mainTemplate only and doesn't allow you to add dependencies to the launcher script. Please add a way in the Dependencies.xml files to specify which gradle script to target. For example, add an attribute: .

We're requesting this because recently an SDK that we rely on had to move their plugin and dependencies to the launcher-level and not the main Unity library. This makes it difficult to maintain multiple Android build configurations because we can no longer use EDM4U's great Dependencies.xml system.

[google-oss-bot]

This issue does not seem to follow the issue template. Make sure you provide all the required information.

[toxikman]

I will add the clarifying detail that they switched their SDK from a gradle dependency to a gradle plugin which is inserted into the launcherTemplate file. So it would also be desirable if Dependencies.xml could specify if the library is a dependency or a plugin.

[AtomicTroop]

We are struggling with this too, in our case the issue is with Fyber SDK requiring its native dependencies (SDK + mediation) to be placed in launcherTemplate.gradle rather than mainTemplate.gradle. Their integration guide's advice for use with EDM4U is quite unhelpful:

Resolving the dependencies will automatically add them inside your dependencies {...} block in your mainTemplate.gradle.
These dependencies should be instead be placed inside your launcherTemplate.gradle.

How these dependencies are meant to be moved into launcherTemplate.gradle isn't clarified. Right now it's manual work.
To make things worse, some of these mediation dependencies are very likely to collide with other existing dependencies, so not resolving Fyber with EDM4U isn't a great option either.

Somewhat ironically, it seems this was already fixed once in a practically complete PR #346 . Could this work perhaps be reused to fix this issue?

[AtomicTroop]

This is still an ongoing active problem for us. Any news or is this issue as good as dead?