disabling Explore AAR still modifies AARs after downloading

[mo22]

disabling Explode AAR still modifies AARs after downloading in 1.2.129 (current).

to reproduce:

1. uncheck Explode AAR in options, enable verbose
2. start resolve
3. output log contains stuff about replacing applicationId (and it is actually replaced in the files)

[stewartmiles]

@mo22 from https://github.com/googlesamples/unity-jar-resolver/blob/13a3b4ec65b0c3f6280671538c2d02983847bbe3/source/PlayServicesResolver/src/GradleResolver.cs#L973

Unfortunately, as of Unity 5.5.0f3, Unity does not set the applicationId variable
in the build.gradle it generates.  This results in non-functional libraries that
require the ${applicationId} variable to be expanded in their AndroidManifest.xml.
To work around this when Gradle builds are enabled, explosion is enabled for all
AARs that require variable expansion unless this behavior is explicitly disabled
in the settings dialog.

right now disabling explosion does not disable replacing applicationId as it results in broken builds for a range of Unity versions. I could imagine a setting to break the glass to support this behavior but I would really prefer to not do this as I would imagine this resulting in more support requests when builds fail.

[mo22]

I believe the line

            if (PlayServicesResolver.GradleProjectExportEnabled && !SettingsDialog.ExplodeAars) {

is not quite correct as I have disabled ExpodeAars in the settings and it still unpacks and modifies the aars. Possibly because I also disabled PlayServicesResolver.GradleProjectExportEnabled?

[stewartmiles]

@mo22 correct when the gradle project export is enabled it's possible to patch the exported Gradle project manually to generate a working build. If I remember correctly, various Unity versions between 5.5 and 2018.x generate different broken Gradle projects when including AARs that have Android Manifest's that reference the project ID. Since it has been broken on an off, just enabling patching in all cases except for export was easier than testing every point release to see whether we need to patch AARs to have Unity generate a working Android build.

[snlehton]

I'm a total Android noob, but I've been wondering why all of the resolved AARs change always when making a build, even if the AAR version is not updated. I've compared an old file of the AAR with new one, and they seem to be identical (extracted both and did directory compare). Currently when making local Android builds, the resolving makes tons of changes in the git repository, which either have to be discarded or committed. This adds a lot of friction when needing to do multiple Android builds locally and switching between branches. It does not matter on the CI server as any changes in the local repo are ignored anyway.

Is the difference in the AAR happening because of repacking? ie. there is some difference in the zip metadata (timestamp maybe?) and that causes the difference in the actual file even if the content is the same.

If so, could this somehow be made more intelligent by checking that if the old AAR was already good to go? Maybe option to assume that is OK if the version does not change. This would help quite a bit.

It seems I could alternatively disable the resolver when doing builds, and make sure I run it whenever I update plugins. Is there a good reason to have the build time resolving on?

[wei-jiaxing]

In our case,

• We will change the bundle id before build by Jenkins.
• We don't use Enable Auto-Resolution and Enable Resolution On Build. Instead of that, we resolve by ourselves and commit these .aar files to Github directly.

So it is expected that AARs should not be modified (change ${applicationId} to my bundle id).

Our solution is that

1. Use Patch mainTemplate.gradle and resolve. This option will not modify aar files.
2. Copy this file out of the Unity.
3. Patch mainTemplate.gradle => false and resolve.
4. Replace aar files from Step2

---

For this comment https://github.com/googlesamples/unity-jar-resolver/issues/287#issuecomment-547665108 , you could just use the #if UNITY_X_Y_OR_NEWER to avoid the problem if it has known which unity version has the problem. (It works on our unity version Unity2018.4.2f1 at least)

Or maybe you could add the option for who will not use auto resolution with modifying this line https://github.com/googlesamples/unity-jar-resolver/issues/287#issuecomment-545570650 to

if ((PlayServicesResolver.GradleProjectExportEnabled || !SettingsDialog.AutoResolveOnBuild) && !SettingsDialog.ExplodeAars )

---

Currently it is confused to understand Explode AARs will works only when the Gradle's ProjectExport in BuildSetting is on. It is helpful to describe this in the Setting Dialog.