Recommended "Resolution" for Complex Projects (Android X)

[thomasjohnwolfe]

Unity editor version:

2018.4.2f1

###External Dependency Manager version:
Current: 1.2.105.0
Attempted Upgrade: 1.2.137.0

###Features in External Dependency Manager in use (Android Resolver, iOS Resolver, VersionHandler, etc.):
We use the *Dependencies.xml files to define iOS and (newer) Android SDK dependencies.
Most Unity plugins seem to be using this now and we've converted our internal solutions to also use these files.

###Plugins SDK in use:
Adjust - 4.13
Admob - 4.2.1
Admob Mediation, AppLovin, Facebook Audience Network, IronSource, UnityAds, Vungle
Apple ID "Lupidan Sign In With Apple“
BuildPipeline(DotsInternal)
Braze - 1.21.2 => Relies on Custom JAR (and our own Deep-link solution) that extends AppboyUnityPlayerActivity extends UnityPlayerActivity
Facebook => Divergent(2 unity SDKS) unity-7.11.1 (Android)unity-7.18.1 (iOS)
Firebase - Unity - 5.3.0
Google Play Games - 9.50
Localytics - 2.5 (this is old!)
SafeDK
Sentry - (custom plugin that wraps native)
Unity IAP - 1.22.0

Platforms you are using the Unity editor:

Mac/Windows (mostly Macs)

Platforms you are targeting:

Android / iOS

###Scripting Runtime:
IL2CPP

Please describe the issue here:

We haven't been able to use this plug-in as intended to "resolve" for over a year now due to the complexity/history of our project. This plug-in was intended as a one-time solution to "resolve" dependencies. We are large game studio with complex SDK management and custom CI. Our game has been live for roughly 6 years.

Is there any sort of configuration you would recommend where we can run "resolve" without running any sort of custom processing, reverting of files, or guess work?
I’d like to work with this plug-in and not against it. It is a great tool for a newer setup or a project with less SDKS and less custom solutions. It works well for other (newer) projects in our studio.

Currently when after we use the plugin to "resolve" Android dependencies we have to do one or more of the following:

• Commit the libraries we need and then revert the rest (quite often this happens with extremely time consuming amounts of trial and error and swapping in and out versions of Play Services Resolver)
• Avoid the plugin in directly and download the files we need from Maven directly.
• Run the resolver 2x for production and dev bundle IDs and then make custom preprocessor scripts (for Firebase that copy the AARs in and out of Unity project)
• There are usually a large amount of "dex" errors (lately) which seem harder to resolve by using this plug-in, than it was 4 years ago without it.

Now with newer SDKs moving towards Android X, problems with this plugin are even worse (scarier) and it seems we are about to reach a tipping point where half our plug-ins want to use Android X libraries and old ones we will have to remove. We are trying to avoid updating 3+ SDKs at a time to fix these issues (as its very risky and our game is live)

Here is a link to a watered down log (trimmed for security reasons) of tests I have performed trying to make builds over the past week when exploring this issue.
https://dots.quip.com/uGq0Ajvzs7LM/Android-X-Exploration-Play-Services-Resolver

I anticipate this might be a duplicate issue. But we have been doing research on our plan for supporting Android X and I have yet to make a build that works. So please feel free to point me in the right direction!

Thanks!
Thomas Wolfe

What's the issue repro rate?

95% of the time we do an SDK update for Android, we run into large scale issues that can’t seem to be fully resolved with this plugin the way it was intended.

[chkuang-g]

Hi @thomasjohnwolfe

Without diving too deep into your configuration, here is my understanding:

• Among all plugin your project uses, Admob, Facebook, Firebase and Google Play Game are using AndroidResolver to resolve Android dependencies.
• The latest EDM would prompt to utilize Jetifier to migrate libraries for AndroidX 7f438ba
  https://developer.android.com/jetpack/androidx#using_androidx
  You can also find the setting to enable it in Assets > External Dependency Manager > Android Resolver > Setting
• If you have additional .aar or .jar which you like to resolve along with those required by other plugins, I think you can define your own *Dependencies.xml and AndroidResolver will take that into consideration during resolution.
• If you still have trouble to build Android, you can use custom gradle template. More information:
  Cannot use it with AndroidX #145 (comment)
  https://docs.unity3d.com/Manual/android-gradle-overview.html

Hope this helps.

[chkuang-g]

There is a similar issue #349

As mentioned in that thread, any AARs and JARs will need to be in either local or remote maven repos so they're processed by the Android Resolver. If you are using custom gradle template mode, a.k.a. mainTemplate.gradle, the Jetifier integration in the Android Gradle build will process them.

[thomasjohnwolfe]

@chkuang-g
Thank you for your responses!

• Among all plugin your project uses, Admob, Facebook, Firebase and Google Play Game are using AndroidResolver to resolve Android dependencies.

=> Yes, as well as all the admob networks.

• The latest EDM would prompt to utilize Jetifier to migrate libraries for AndroidX 7f438ba
  https://developer.android.com/jetpack/androidx#using_androidx
  You can also find the setting to enable it in Assets > External Dependency Manager > Android Resolver > Setting

=> I tried 1.2.137.0 (as stated above) and used Jetifier, but it produced errors that I posted on the build result doc I provided in my original post. . Do you think the newer version would produce different results?

• If you have additional .aar or .jar which you like to resolve along with those required by other plugins, I think you can define your own *Dependencies.xml and AndroidResolver will take that into consideration during resolution.

=>It is possible I can use this solution to dig deeper into making older SDKs compatible? IE in our case Localytics. With an older Google Play Games SDK, I found that If i download the libraries manually from maven and point the Dependencies.xml file to local repos, it seems to work without "resolving" the project.

• If you still have trouble to build Android, you can use custom gradle template. More information:
  #145 (comment)
  https://docs.unity3d.com/Manual/android-gradle-overview.html

=> We use a custom gradle. I did also try this strategy of letting the plug-in patch the file with repos, which also produced errors I had on the build result doc I provided in my original post.

Addition Info
I can provide our main template.gradle if thats helpful.

Also I tried "pinning" our version numbers at one point and re-naming this template.grade. Which was something potentially advised in another thread. But that also didn't seem to work.

Reiterating part of my initial post. We use a custom jar to intercept android native events for app-linking and also Braze/Apply (it extends UnityPlayerActivity) example here . Not sure if this effects of your recommendations.

My Current Take Away
I should upgrade my Admob, Braze/Firebase, Google Play Games SDKs because they likely work with this Jetify out of the box? I tried everything you said for the most part, but maybe I just need to upgrade the SDKs.

Unfortunately, since it doesn't appear to build (using jetifier) by just replacing ONE of them, I likely need to spend days/weeks stripping down our project to work with no SDKs. Then build it back up one at a time. Otherwise there will be no way to test each component fully or review the code properly. I can't upgrade that many SDKs and trouble-shoot the problems or pass any sort of code-review process since its too many changes at once. It is also unfortunate because this also effects iOS, and will need to be fully tested with iOS, which doesn't have any issues at this time.

I am just trying to understand what is recommended, so I can schedule the timing and direction. Thanks.

[chkuang-g]

Hi @thomasjohnwolfe

Since you are using gradle template mode, a.k.a mainTemplate.gradle, let's use this as the baseline.

1. For plugins which is using EDM to resolve dependency, such as Admob, Firebase, Google Play Games, and Facebook, it is not necessary to upgrade them. What will happen is:
   • AndroidResolver from EDM will inject dependencies and local repo to mainTemplate.gradle for you using information from Dependencies.xml. See // Android Resolver sections. If you did not see those sections, you probably did not enable it in the settings. Take a look at Assets > External Dependency Manager > Android Resolver > Setting menu item.
   • If you enable Jetifier in Android Resolver, mainTemplate.gradle should enable android.enableJetifier. That means, when you build for Android, Gradle will use Jetifier to patch all .aar and .jar from the local or remote repo for you.
2. For plugins which come with .aar and .jar, this is basically a nightmare for you developers. The worst case is that they include legacy Android support library as well. In this case, you need to prune the weed for them.
   • First of all, find all .aar and jar that are just for dependency. Ex. files with name starting with androidx. or android. are definitely dependencies. Remove them, since Gradle will download and patch them during build time.
   • Second, find all the rest of .aar and .jar, create one or more POM file for them to make local repos. Perhaps one for each plugin for easier management. Add the repo paths to mainTemplate.gradle manually. And perhaps add the dependency as well.
   • You really need to consult with the plugin provider about the details. The question for them is "How can I use your plugin with gradle template mode on and with AndroidX support?". They should know the instructions for previous two steps.
   • Once these are done, as mentioned, Gradle should download and patch those libraries for AndroidX.
   • Finally, write a nice letter to the plugin developers and ask them to utilize EDM to make your life easier.
3. For the .aar and .jar your team made, create one ore more POM file to make local repos, and add the path to mainTemplate.gradle as well as dependencies. If you includes .aar and .jar for dependency in your project, you should remove them.

Note that for 2 and 3, you can create your own Dependencies.xml so that Android Resolver can automatically inject repo and dependencies into mainTemplate.gradle for you, just like how Firebase does.

I think this should cover most of the use case. Unfortunately Unity does not provide an official methods to resolve Android dependencies. We can only hope more plugin provider can follow EDM standards so that the developers can spend less effort managing them.

Let us know if it helps!

[thomasjohnwolfe]

Thank you very much for your response. Will keep you updated with results.