Unity Firebase Analytics with custom gradle file as dependency management (instead of Google Play Services Resolver)

[Kirill Nadezhdin]

We have a lot of library dependencies in our Android project, some of which depend on google services. As such, we use gradle system (custom gradle template in Unity) to handle all dependencies in one place, partially removing duplicated entries using "exclude" mechanics. It also allows us to track different required versions of different plugins

Now we also need to add Firebase Analytics to our Unity game to enable better Google Ads learning to provide better ads traffic quality.

We have followed the "happy path" of integrating Unity plugin and resolving all dependencies using Google Play Services Resolver, which adds a bunch of .jar and .aar files in our project, some of which are clashing with our dependencies from the Gradle system, which results in a failed build for Android due to duplicated library entries (I can post a log here, but it won't help to solve the problem at a higher level).

Thus we have followed the not-so-happy-path of integrating "pure" Android Firebase plugin, which seems to be using only gradle and no manually downloaded .jar or .aar files.

In the process, we have found out that "pure" Android plugin only requires "firebase-core" lib, while Unity plugin also requires "firebase-analytics", "firebase-iid" and "firebase-unity". And while it's possible to include first two options with gradle directly (three if we count "firebase-core"), the last one ("firebase-unity") is stored in a local Unity project folder-based Maven repository as a .scaar file. And we can't just "tie" it through some hardcoded file path because it will be different on every developer machine (mac / windows).

Unity plugin, unlike "pure" Android one, also requires some "app" dependencies on "firebase-common", "firebase-app-unity" and "auto value annotations".

One possible solution would be to manually delete clashing libraries from the plugins folder (those files that Player Services Resolver has downloaded), but it will get in a way of Resolver's work, possibly breaking something in the process

Another one is to manually exclude clashing libraries from Gradle, but it will not be apparent enough as why there are excluded libs in that folder. And if someday we update one of the plugins with "raw" .jar or .aar files, some of them may disappear out of the Plugins folder (Resolver possibly deleting some of them due to not being used anymore), it will lead to runtime crashes, which are much harder to track than simple compilation fails.

I want to point out that this inter-dependency problem is very common and a lot of Unity plugin maintainers also support gradle-based dependency resolutions rather than using Google Play Services Resolver which also seems to be doing a lot of other stuff behind the scenes (see this topic https://groups.google.com/forum/#!searchin/firebase-talk/unity$20firebase$20gradle|sort:date/firebase-talk/lQu9eSPHoJs/Zmg6z5RBBAAJ)

My questions are:

- what is an effective solution for integrating Firebase Analytics into an existing project with other Google Services and common libraries dependencies which use Gradle as dependency management tool?

- why does Unity plugin requires so many more dependencies compared to "pure" android project? I can understand about "firebase-unity" lib, but what about 4 others?

[Patrick Martin]

Hi Kirill,

Thanks a lot for your questions, and I'll do my best to answer them.

Based on the details of your question, I assume that you've already looked at how the Play Services Resolver works and ruled this out as an option. But I do want to mention that it's possible to specify the other gradle dependencies you have as additional Dependencies.xml files.

The path you're going includes disabling this resolver (as I assume you've done), and making sure that you transfer the existing gradle dependencies in those files into your gradle template. To handle the firebase-*-unity dependencies, in addition to the option you mentioned as not being viable due to your mixed environment, it is possible to rename those from .srcaar to .aar and manually stripping out the ABIs of the native libraries you're not using. These are mostly native C/C++ components used to bind between C# and Java.

Finally, for the additional dependencies, gradle silently handles transitive dependencies in the background whereas the Play Services Resolver has to explicitly drag everything in. As you can see here, firebase-core does bring in firebase-analytics.

Let me know if I haven't addressed these to your liking, or need additional help. If my response is enough to get you unstuck, feel free to submit additional feature requests here!

--Patrick

[Kirill Nadezhdin]

Hi Patrick!

Thanks for getting back to us on this.

We have used GPSR in the past and it was a source of constant issues and a pain-point in our projects, we even had to manually source-patch it a few times to make it work correctly in our environment.

Moving to Gradle, on the other hand, was a huge relief as it not only allows to handle dependencies more easily, but also allows us to specify some advanced Android build options in one file.

While moving all our other packages to Dependencies.xml option may be a viable option in a few cases, we usually tend to move the other way around - we have patched a few libs to use gradle instead of GPSR, and it was possible because all of the libs dependencies were available on remote repositories.

There's also an advantage of debugging clashing dependencies with gradle as it allows to log all the nested dependencies and track which libs may require either updating dependencies to a common version, or excluding duplicating dependencies, which in our experience is not always possible (or works correctly) with GPSR.

Moreover, most of the "pure"-Android development ecosystem seems to be using Gradle these days, sometimes marking "raw" .jar and .aar file downloads as a "deprecated" method, so bringing Gradle to Firebase-Unity will surely make Android devs feel more at home.

Are there any plans on moving firebase unity plugin to Gradle instead of the Google Play Services Resolver (GPSR)? Or at least providing an alternative way of handling package dependencies (like putting firebase-unity lib to some remote maven repository so it's no longer required to host one locally)?

I have submitted a feature request like you've suggested, just in case.

Cheers,
Kirill

[Patrick Martin]

Hi Kirill,

Thanks a ton for filing the feature request. It's difficult for us to completely abandon the GPSR, as we do support versions of Unity where gradle was either unavailable or still marked as beta (thus why many of our Quick Start samples are saved with the 5.5 Unity Editor). Overall, I don't think that we can abandon it as it does do a lot automatically that would otherwise have to be manual actions on behalf of our users and a number of Unity plugins do rely on this resolver.

We are looking at ways to improve this experience as your situations is in no way unique. I don't have any details or timelines to share, and the base behaviour is likely to stay the same for the reasons mentioned above, but Firebase's raison d'être is to be as easy and accessible to use as possible. Until then, feel free to reach out here or to our support page when you're stuck on issues like this.

By the way, were you able to move everything to a custom gradle successfully (and did renaming scaar to aar work out for the local dependences in your mixed-platform development environment)?

--Patrick

On Wednesday, April 24, 2019 at 8:12:54 AM UTC-6, Kirill Nadezhdin wrote:

[Stewart Miles]

We've added support for patching mainTemplate.gradle with dependencies in version 1.2.105 of the Play Services Resolver

https://github.com/googlesamples/unity-jar-resolver/blob/master/CHANGELOG.md#version-12105---apr-30-2019

It's available for download here https://github.com/googlesamples/unity-jar-resolver/blob/master/play-services-resolver-1.2.105.0.unitypackage

This allows plugin developers to export their set of Android dependencies using the Android Resolver in a way that multiple plugins can inter-operate, assuming they don't depend upon Android libraries that are incompatible.  This also works across all versions of Unity after 4.x-ish.

Cheers,

Stewart

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/72cf53ae-7977-4dd6-b7ea-2890cfbfa5c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kirill Nadezhdin]

Very cool, we'll be sure to try that

Thank you, Stewart!

To unsubscribe from this group and stop receiving emails from it, send an email to fireba...@googlegroups.com.