Modify the build.gradle file in a post process step when possible

[sp-jordi-vilalta]

Please fill in the following fields:

Unity editor version: >= 2018.1 Features in Play Services Resolver in use: Android Resolver Platform you are targeting: Android

Please describe the issue here:

This is a feature request / suggestion for improvement / request for comments.

Summary: I would like the Android resolver to be able to delegate the dependencies resolution to Gradle without requiring the presence of a mainTemplate.gradle file. Here's the rationale:

• First of all, we prefer delegating the dependencies resolution to Gradle: we have a set of dependencies that the Android Resolver struggles to resolve, running multiple attempts, taking a long time (several minutes), and giving a result that differs from the one we get from Gradle (some versions get unlocked in the process)
• When the mainTemplate.gradle is present the Android Resolver does an amazing job (collecting the dependencies, repositories, handling AndroidX+Jetifier, etc...) 👏
• The mainTemplate.gradle file has to be in sync with the one provided by Unity. Large projects can take multiple years (and live ones have to be maintained for a long time), and we often have to update the Unity version in the process. Updating the mainTemplate.gradle file is easy to forget, it becomes a chore and it's error-prone to compare the differences in the Unity provided ones between versions and porting our own customizations
• Because of the previous point we're trying to get rid of the mainTemplate.gradle file so Unity can automatically provide its own one without us having to care about updating it
• We've updated our customizations to be applied to the generated build.gradle as a post-process step using IPostGenerateGradleAndroidProject (it was added in Unity 2018.1.0)
• When I tried removing the mainTemplate.gradle file I noticed the Android Resolver was falling back to its internal resolution again 😢

Ideally I would like the Android Resolver to offer an "approach" option where the users could choose between:

• "Final build.gradle patching": Available when the project is built using Gradle and Unity >= 2018.1, using an IPostGenerateGradleAndroidProject (whether the mainTemplate.gradle file is provided or not)
• "mainTemplate.gradle patching": Available when the project is built using Gradle and it has a mainTemplate.gradle file
• "Internal resolution": The classic approach, always available

Do you think it's possible? Does it fit the direction of the project? Do you see value in it? Do you think it would be doable with relatively small effort?

Thanks!

[google-oss-bot]

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

[stewartmiles]

@sp-jordi-vilalta I didn't realize Unity had added IPostGenerateGradleAndroidProject that is very cool indeed.

Yeah I think what you've outlined sounds like a great approach it's certainly better than having to deal with Unity's mainTemplate.gradle changing between versions etc. Also, moving all resolution outside of the project so effectively build artifacts aren't plopped in each time would be far better.

w.r.t classical resolution taking a long time, it sounds like a bug IMHO if it's coming up with a different result to Gradle. Though last time I checked, Gradle's fallback was to just upgrade to the latest requested version for a dependency when faced with conflicts which is usually a recipe for disaster.

In terms of effort, I think the most tricky thing would be to add conditional support for IPostGenerateGradleAndroidProject so that the DLL still loads with old versions of Unity. Beyond that it doesn't sound like a huge effort since the mainTemplate.gradle patching code is already there it would just need to run after the build.gradle file had been generated.

[sp-jordi-vilalta]

@stewartmiles Great! So what do you think we could do to move it forward? Do you think you could handle it on your own or would you prefer getting a PR with it?

[stewartmiles]

@sp-jordi-vilalta a PR would definitely be appreciated

[Thaina]

In terms of effort, I think the most tricky thing would be to add conditional support for IPostGenerateGradleAndroidProject so that the DLL still loads with old versions of Unity. Beyond that it doesn't sound like a huge effort since the mainTemplate.gradle patching code is already there it would just need to run after the build.gradle file had been generated.

One way to do is revert this package back into raw C# code instead of dll I think? That way we could have handle any bug or unity varied version by just tweaking some code

Or maybe we would have new repo that could be reference as UPM? So we could just use this new interface feature in version that also UPM available