Gradle build failure -- might be related to Google Play Services and a manifest file

Unity Engine
,
1

On Unity 2019.2.15f1, MacOS Mojave 10.14.6

I opened a small project to test the integration of a few advertising SDKs.
After importing, cleaning and resolving a certain number of issues regarding Google’s resources, in part incurred because some SDKs still ship with the PlayServicesResolver (PSR) in Assets/ folder while others come with the newer ExternalDepedencyManager (EDM). The latter actually prompted me to be migrated to the package manager, so Unity “did stuff”, it downloaded, loaded and moved assets.
It appears to have been doing stuff related to Gradle too at some point after opening a window, loading a bar, so I let it run the course and finish whatever it was doing. All that being done, all seemed to work well and the EDM seemed to have superceded the PSR in the ‘Assets’ menu. I can’t even remember if I had to manually remove the PSR folder in Assets/ and perhaps some lingering related files in Plugin/ but, anyway, all was clean and apparently good to go.

So I pushed for a build and run on some Android device plugged into the computer.

In Build Settings;
I went for a development build.
With autoconnect profiler.

In Player Settings;
I targted API level 19 (4.4 “KitKat”) (I initially aimed lower but had plenty of androidx duplicate errors).
I aimed at two core types, ARMv7 and 64.
The scripting backend was IL2C++.
C++ compiler configuratio nwas “debug”.

The project is very small and I am not splitting binaries or using some kind of special package. I don’t use any Custom Gradle Template, neither do I use Proguard or minify anything. No custom keystore here either.

But the Gradle phase crashed after 4s and I got a pop up:

And then got a flood of errors in the console, because each “line” of information or suggestion is literally loaded as a separate error, which totaled into 86 red messages, even if the last messages actually contain all the former errors.
Here’s a selection of those I think are relevant here.

Let’s stop here already. First main problem seems to be related to Google Play Services here but a crucial information is lacking, something Gradle might not be able to compute.
I have a bunch of AndroidManifest files, but since the error is on line 83 of the merged file, I’m lost on how to know where to look at and actually what to look for.
Any suggestion?

Thank you Unity Console.
Follows a long list of DebugSource/Manifest/Resources/etc., CompileDebug, UP-TO-DATE or NO-SOURCE messages.
Then we’re back to what seems to be an important piece of science:

Here we go again with the special instructions lingo. I just want to compile stuff.
I know that when I prepared the project and succesively added SDKs, as said earlier, at some point a window popped up and there was plenty of stuff going on about Gradle.

Now for some reason, my test project seems to use some old Gradle features that are not compatible with Gradle 6.0.
There’s so little information and transparency about that Gradle wrapper/tool/thingy.

Here are some more errors:

I looked into Preferences, there was no warning regarding Gradle, aside from the warning one gets if one unticks any box; which is kinda odd to get these warnings as soon as a path is made visible.
I’d really love that the path leading the to DEFAULT tool (SDK, NDK, Gradle, else) would actually be displayed in gray.
The warning would only make sense if when unticking any of these boxes, it would display a path that is not the default one, but I think Unity should do an autoparse here, instead of automatically panicking about not using the proper version.

I also checked the Assets/ folder to see if I could find anything related to Gradle but besides one file proper to an advertiser’s SDK, there was nothing looking like a general config file or template whatever.
There’s an AndroidPlayer/Tools/GradleTemplate folder somewhere in Unity’s major folder elsewhere on the Mac but I’d rather not fiddle with that one (yet?).

Let it be known that there are no NDK elements installed in Android Studio’s SDK area. There are two elements, NDK (Side by side), and NDK (obsolete) and both are not installed.

So again, the main problem looks like it is about a version of Gradle. For some reason, an identification of the Gradle tools present on the computer is not done properly or something? Seems odd really, never had any issue before. Must be something else…

**
I noticed that I didn’t have a DISABLED mainTemplate.gradle file in my Assets/ folder.
It appeared after asking for a custom gradle template in Publishing settings and then setting it back to off (it adds the DISABLED extension).
Here is something strange though. Enabling or disabling this file doesn’t change the modification date (mine says late Dec 2019), as if it took the date of the template located elsewhere. That’s a small detail but it shouldn’t really behave that way nevertheless as the instance’s creation date should reflect when it was instantiated.
**

Well, since this file was instantiated into my Plugins/Android/ folder, I opened it to see if I could collect some information about the version of Gradle.
Ha. See this:

The information of value seems to be found in the line:

classpath ‘com.android.tools.build:gradle:3.4.0’

An old post but it’s suggested to change the line I highlighted.
Yet I don’t think I have the same issue. I’m not asked to upgrade Gradle, I’m only told that my project uses old functions.

Another poster said:

This is making me think that the problem might be in some manifest file, as per the first error I pasted here earlier on. All AndroidManifest.xml files are provided by ad SDKs in this simple test project.
Maybe Gradle is acting nuts because it’s lacking a piece of information?

To conclude, a last post I found on this topic:

This page suggests that it’s not recommended to manually upgrade Gradle and I’d agree, I’d rather not do anything like that.

Any 101-Dummies way I could use to obtain more information about this build failure?
The Console mentions using some special instructions. How am I to proceed exactly?

2

Been looking into the troubleshooting page and didn’t find any relevant information about the issue I encounter here.
I think I need to tell Gradle to provide more information to Unity about why the building failed, to fill the Console with data, but I’m clueless as to how to do this within Unity.
Do I need to add a script or use some custom file?

EDIT: other people had issues with this too. Some remained unsolved.

3

:frowning:

The number of threads dealing with very similar errors that remained unanswered or barely got any useful clue is impressive and it goes without saying that the longer the thread, the more annoyed members one can find.
Small sample

One hopes to get rid of a problem, only to be faced with another one. It is almost hopeless.
Perhaps the only thread that seems to be providing the beginning of an answer is this one:

Which links to another thread.

I may have to thank Tom-Atom for reposting JDL’s answer. Or maybe not, I cannot say for now. I am not doing anything exceptional with Unity here, just using a bunch of popular plugins and a few SDKs, all in limited fashion and in focused scale, yet even there it fails.
I’m highly tired of this crap tbh. It literally ruins the Unity experience for me.

4

I still have hope though. So I went on, I removed some SDKs and a plugin that managed them all.
Then I launched another build and got a load of new Gradle errors about issues in merging some dex stuff. This is insane. When publishing for mobile, you are expected to use a given number of third party SDKs and a few plugins, that’s a typical template I would say. In light of this, it should be perfectly understood inside the company that there are high risks of conflicts. The console is vaguely capable of telling you why a build failed, but will not provide an answer. Just imagine not having internet (most of Unity wouldn’t even work then considering the amount of data it keeps sending and requires downloading every minute).

The only thing that’s been extremely easy thus far was getting stuck in a neverending stream of building errors on any kind of project.
Hey, look, a cautionnary warning!

Then why Unity is waiting for the build to fail to barely allude to something like this being perhaps the cause of some of the troubles?
In other places, one can read that Jetifier might be very abrasive in the way it manages libraries and changes (read: destructive).

Why can’t Unity scan the entire project and notice the user that as certain dependencies are called for, some changes should be applied to prevent crashes and building errors? No amount of “resolving” has prevented any of these errors.
This is unprofessional, frustrating and tiring.
The Gradle experience has been nothing more than a pure nightmare thus far.

Reading this, Unity - Manual: Gradle for Android, I see that Gradle’s version is 5.1.1.
If the + attribute, as visible for example in the custom mainTemplate.gradle, will surely cause issues then why is it left it as is by default? Where is the logic in this? Why no warnings?
Some people suggested modifying (again) lines here and there to force Unity to use a certain version of Gradle (as if there were millions of versions installed on a machine).
In the messages provided by the console, I could find a reference to a version of Gradle that read blah blah 3.4.0 blah blah, and another message that told me I attempted to use deprecated Gradle features not compatible with Gradle 6.0. What nonsense is that?
I’m not even sure Unity provides a simple method to ping Gradle about its own version (actually, the same applies to JDK, NDK and SDK, it’s one big mystery).
By Unity’s own documentation (that is not even up to date regarding the Android Publishing Settings because it doesn’t list all the new Gradle custom options), this version of Unity uses Gradle 5.1.1! So why this stupid message about 6.0 that should be totally irrelevant?

Being exhausted by this rubbish and looking for perhaps a more radical approach (without much hope knowing how this tool suffers of rampant Unitis), I decided to update to 2019.4 in the hope that Stalingradle would finally be properly supported. Well, I just got served with more errors (surprise surprise).
As usual, it seems that new features are pushed onto users who are then turned into guinea pigs.
It is madenning to see how many threads about Gradle have been published within less than two years, with all but the most acrobatic granular modifications being required to make things work properly inside Unity. Reminds me of Mecanim and how it only became more or less complete around 5.2.
I even read one dev who said that he encountered a Gradle error because the building ate too much disk space and he ran short of it: He never was warned by Unity that there would be a problem here because of a lack of ROM. Perhaps the tool could do a quick guess on how much space it’s going to need for the build?
Fortunately this is not a problem I personally encounter as my project clocks at 500 Mb in assets on a disk that has over 14 Gb of free space readily available.

But.
By virtue of being a middleware tool, isn’t Unity supposed to be the orchestra leader that guarantees that all elements work in harmony?
If you want another example of the absurdity of this situation, I remember reading another revealing thread on Stackoverflow (which with UnityAnswers and this forum represent the trifecta of “solutions”). In it, a dev was told he had conflicting files in his project regarding Unity Ads. He had unityads and unity-ads stuff working against each other. One had to go. We’re not even talking about a third party library or else. That’s literally an in-house feature. You would think that Unity would be sufficiently self-aware as to actually warn the user of this problem and already suggest a solution about their own system!
Oh sure, you can click on resolvers a thousand times a day and delete “resolved” libraries and stuff, or even let your gradle files be edited on the fly, but in the end it’s as if you had done nothing.
Right now I’m stuck in the transition from alpha to beta because I just cannot verify the quality of the would-be app since it’s literally impossible for me to build it, as Gradle keeps saying nah, you shall not pass because [arcane byte crap].

Quick note on this btw: Always use verified versions of packages. I had to “update” back to Advertisement 3.4.9 instead of 3.5.0 to have the Ads tab be displayed in the Services window.

Google is pushing all sorts of changes that are generating all forms of roadblocks, turning simple project into truly monstrous chimeras and Unity is not providing any help here. We cannot even chose to use “internal” these days.

Why the hell are you even bothering selling stuff like “codeless” Bolt or other visual scripting whimsical tools for people who don’t eat a full bowl of C# every morning if you’re not even capable of making sure that such newcomers will not encounter any problems ahead of their development’s final steps, aka building, which certainly rests beyond their ability to code anything proper?
These are problems which should be your responsibility to make sure are getting solved in the shortest available time. I’m literally dealing a tool that cannot do what it’s supposed to do and seems to be deeply lacking in self-awareness.

I hope Gradle related phases will be made much more novice friendly than it is now.

3 Likes
5

@Starbox - did you ever find a solution? I have been pulling my hair out over this situation.

1 Like
6

Me too

7

Gold!

Your rant perfectly summarised my last 2 weeks…

8

I’m sorry for not replying earlier. Here are few things one can do to clean up a project before trying to extirpate oneself from a typical Gradle nightmare:

  • make sure you have much more free space on your computer than taken by your own Unity project.
  • check the SDK, NDJ and JDK paths in external tools (don’t hesitate to turn on manual, open the link, then turn them back to auto).
  • backup the project then destroy the Library folder and let Unity rebuild the thing on next launch. You might have to reupdate a few things but it’s a relatively safe process overall.
  • see if you have a conflict between a plugin in Assets and a possible sibling in the Package Manager.

Then;

  • try to build without custom-build parameters (no custom gradle) and see what happens, at least, on a more vanilla setup.
  • check what may require a Gradle custom build, say a plugin or else, and perhaps contact the publisher to know more about it.
  • open the detailed log file from the Unity console (that three vertical dots menu, top right corner), and copy/paste the generic parts of the technical output that surrounds the reported error, and check for them on a search engine. If you don’t get an answer, do not hesitate to truncate sentences.

Good luck.