Bug: 132188969
Change-Id: Ic21075f8c06a1157b7e5491858fceac9e1b4fe1a

Change-Id: I22953be27d216cf8210531ce540b354e929c16af

When resolving Android dependencies using Gradle and a mainTemplate.gradle
file, srcaar artifacts in maven repos embedded in the Unity project are
renamed to aar so they can be included in the Android build process.

However, some plugins (like Google Play Games) ship with Maven POMs that
refrence the srcaar artifacts directly rather than the aar artifacts.
This results in the renamed aar files being ignored in the Android build
process.

This commit patches Maven POMs so they reference the correct artifact
when the packaging is changed by the Gradle Android Resolution step.
If libraries are removed, the POMs are updated to point at the packaging
for the artifact in the directory (e.g srcaar).

Fixes #208
Bug: 132168073

Change-Id: I357c6a1197d4fc15cc924b5a4d9e4d7c79be922d

Change-Id: I2205a22a6f8a9a3d689716d307bcc72eceeb71bc

* Added links to documentation from menu.
* Android Resolver: Added option to auto-resolve Android libraries on build.
* Android Resolver: Added support for packaging specs of Android libraries.
* Android Resolver: Pop up a window when displaying Android dependencies.

Change-Id: If5980724e63d0a5b118cc3902a44c1ef3974f297

Unity 2019 adds support for installation of the Android SDK and JDK in
the AndroidPlayer directory making it easier for developers to configure
the Android build environment.  Unfortunately, Unity does not update
the JdkPath and AndroidSdkRoot editor preferences when the Android SDK
and JDK are installed with the AndroidPlayer.

This change searches for the Android SDK and JDK if JdkPath and
AndroidSdkRoot are not set.

Fixes #188

Bug: 132072681
Change-Id: If01f642ff81570d9c28552fab6957bc88cf4dac1

Bug: 132072231
Change-Id: I4d6de053e515ff94cff4b86b08366d323b45b046

Menu links to per-component and project documentation.

Bug: 132072231
Change-Id: Id47da9e8e8d85955fb95535a2de28ea2830be0cf

With AAR explosion disabled, builds are very likely to fail with Unity's
internal build system.  This patch re-enables AAR explosion on resolution
when the internal build system is used.

Fixes #100

Bug: 132070411
Change-Id: Ib2858910e3497c43eb9b1c9e06f7ec632227d8f0

*If* Callbacks.PostProcessSceneAttribute(0) is called before the Android build
(Unity version specific) Android auto-resolution will run if it's enabled.
This adds a setting to that will enable / disable resolution during the build
process without affecting interactive auto-resolution.

Fixes #196

Bug: 132072419
Change-Id: Idba8ffa249952b2288adc6653f11458b5089725f

Some users are seeing exceptions when the Android Resolver creates and
deletes temporary files.  This *may* be caused by anti-virus, Unity
re-indexing directories or all other manner of processes on machines.

This patch catches any exceptions related to file deletion and simply
bubbles up any failures via a list that the caller can optionally report.

Fixes #198

Bug: 132071174
Change-Id: I7985d4045e190222511ea3ba20ac30b4d6a78654

Fixed #174

Bug: 132070893
Change-Id: I28ca9f48ab08e9343d5e4e259f6354b64fee4c45

The Android Resolver was loading the AAR cache in a static constructor
and using the log functions before they were initialized with the
log level from project settings.  It was possible to configure system
wide logging as "verbose" - which would be used in static constructors -
before the project settings are loaded.

Fixes #192

Bug: 132071158
Change-Id: Icdd5d5d12dfbf4d656885360bfceca15da2f7008

Bug: 131331407
Change-Id: I91ccd3cd8e24b2b946e3c469568085195b7b1953

Bug: 132070707
Change-Id: I707f23e3eb37a7468ad1fc00d77985ad0d1a21b9

Fixes #195

Bug: 132071668
Change-Id: Ic0f076c0b745dcb7e8a7e6bbe36a6a9251dee6f1

EditorUtility.DisplayProgressBar() is very flakey, it can end up in odd
states where it can never be cleared.

This removes the use of EditorUtility.DisplayProgressBar from the Android
Resolver, instead moving the progress bar display to the CommandLineDialog.
In addition, long running operations like labeling assets, have been made
asynchronous by scheduling each iteration on the main thread.

Finally, this leaves the Android Resolver window open if resolution fails,
results in one or more warnings or verbose logging is enabled so that it's
easier to inspect the failure logs.

Bug: 132070706
Change-Id: I31ed32659d3871f501aab7305cbfe4df99613e89

Bug: 131100117
Change-Id: I4a9c57a1094f1c76c23dbb8ee96c36a7300ea1bd

* Version Handler: Fixed occasional hang on startup.

Bug: 131100117
Change-Id: I617c8245f4ab4d6f7d0ca28ee6e6752ec1edf512

Also, fixed use of Unity methods from a static constructor.
This *may* have been contributing to a hang when the version handler plugin
starts up.

Bug: 131100117
Change-Id: I6dc4c2252b470520275b3e1763bb006ab3869f44

Bug: 131865569
Change-Id: Ia77e447e142ab10385268ac8cb07b8233d0739b4

* Version Handler: Added support for enabling / disabling assets that do not
  support the PluginImporter, based upon build target selection.
* Android Resolver: Added support for the global specification of maven repos.
* iOS Resolver: Added support for the global specification of Cocoapod sources.

Change-Id: I2e8fecd140788dc61d045e49d1f978bfbd9a5ee0

Currently, we disable certain files per-platform by using PluginHandler, but this only works for libraries (.dll and the like), and does not work on some earlier versions of unity.  This change adds the ability for VersionHandler to disable files by modifying their file extension (from .zzz -> .zzz_DISABLED) based on the platform being targeted - using the same Asset Labels already being used for PluginHandler files.

Change-Id: I658ff0d37f68508cff6956beb8aa7084138c0fa4

Also, remove unused variables in IOSResolver and fix local paths in test data.

Bug: 131865569
Change-Id: I339ccb813236e8f67605acb1a7c7a45ea8eca1e2

* iOS Resolver: Added support for development pods in Xcode project
  integration mode.
* iOS Resolver: Added support for source pods with resources in Xcode
  project integration mode.

Bug: 131784278
Change-Id: I0011ac264c0d90df57e783ec5f5fada95b20d91d

Revise the way Xcode Project Integration works, in order to let cocoapods do more of the heavy lifting.

Revise the way Xcode Project Integration works, in order to let cocoapods do more of the heavy lifting.

Basically, just add the Pods project to the Unity-iPhone project as a "subproject" (the way you used to do multiproject builds before workspaces), and add it to the build of the main target.  Also, don't suppress the pod command's normal project integration (i.e., don't add the line "install! 'cocoapods', :integrate_targets => false" to the Podfile) since that step does all of the work in setting up the build dependencies between the Unity-iPhone project and the Pods project.  That includes propagating build settings (search paths, flags, etc) from the pods into the main project.  (I believe this means the "bitcodeEnabled" attribute is now superfluous, but I didn't disturb the implementation of it for backwards compatibility.)

This change, aside from simplifying the code quite a bit, also lifts some restrictions that the old implementation had.  Local (i.e., "Development") pods that are located outside the Pods subdirectory are now supported.  Also, the resources in source pods are properly included in the app build.

Also leveraged some static calls provided by Unity's PBXProject class for finding the path project and main target name, so that logic is no longer needed in this code.

Feedback:

Revert some stuff needed by precompiled DLLs and certain plugins.  Also use an older overload of PBXProject.AddFile() for backwards compatibility with older versions of PBXProject.

* Android Resolver: Fixed reference to Java tool path in logs.
* Android and iOS Resolvers: Changed command line execution to emit a warning
  rather than throwing an exception and failing, when it is not possible to
  change the console input and output encoding to UTF-8.
* Android Resolver: Added menu option and API to delete resolved libraries.
* Android Resolver: Added menu option and API to log the repos and libraries
  currently included in the project.
* Android Resolver: If Plugins/Android/mainTemplate.gradle file is present
  and Gradle is selected as the build type, resolution will simply patch the
  file with Android dependencies specified by plugins in the project.

Change-Id: I22b8ceab279533081e3ee85c72df8dd9835f25f1

If Plugins/Android/mainTemplate.gradle is present in the project and Gradle is
selected as the build system, the Android resolver will now patch the file
with Android library the dependencies it is tracking.

Bug: 131331407
Change-Id: Ib9e25bb8c6287a8412a73ab24b5a12a1d4b86d86

The new menu item
`Assets > Play Services Resolver > Android Resolver > Display Libraries`

shows output that can be merged into a gradle file like this:

allprojects {
  repositories {
    maven {
      url "file:////Users/unity/auth/client/unity/testapp/Assets/Firebase/m2repository" // Assets/Firebase/Editor/AppDependencies.xml:23, Assets/Firebase/Editor/AuthDependencies.xml:23
    }
  }
}
dependencies {
  implementation 'com.google.auto.value:auto-value-annotations:1.6.3' // Assets/Firebase/Editor/AppDependencies.xml:25
  implementation 'com.google.firebase:firebase-app-unity:5.6.0' // Assets/Firebase/Editor/AppDependencies.xml:23
  implementation 'com.google.firebase:firebase-auth:16.2.0' // Assets/Firebase/Editor/AuthDependencies.xml:16
  implementation 'com.google.firebase:firebase-auth-unity:5.6.0' // Assets/Firebase/Editor/AuthDependencies.xml:23
  implementation 'com.google.firebase:firebase-common:16.1.0' // Assets/Firebase/Editor/AppDependencies.xml:16
  implementation 'com.google.firebase:firebase-core:16.0.7' // Assets/Firebase/Editor/AuthDependencies.xml:18
}

Bug: 127302270
Change-Id: I255098e9e715bcba78253bf396e6e8091c9dc252

Some users want to disable the Android resolver and instead manually
integrate Android dependencies into their projects.  This allows users
to remove all libraries added by the Android resolver via a menu item
or API.

Bug: 127302270
Change-Id: Ic17fe35688ef3f91d75130597b3b75a8de17b439

The console encoding needs to be set to UTF8 to run Cocoapods
command line tools and pipe data to the Android SDK manager.  In
some environments it's not possible to change the encoding from the
default so warn the user instead of throwing an exception and failing
to run the command entirely since the command will report an error to
Unity's log output if it fails.

Fixes #300
Bug: 127302270

Change-Id: I44773ca539b7723f6c4e6bb8b18add4e65108032

Properly reference java tool name in log

* Android Resolver: Changed Android ABI selection method from using whitelisted
  Unity versions to type availability.  This fixes an exception on resolution
  in some versions of Unity 2017.4.

Change-Id: Ic3622a928d447d0b3e97b12d8759cd386b8d063e

* Android Resolver: Changed Android ABI selection method from using whitelisted
  Unity versions to type availability.  This fixes an exception on resolution
  in some versions of Unity 2017.4.

Change-Id: I57e05623f993e3548a5344427b6f229f5571a268

Patch releases of Unity 2017.4 support different modes of Android ABI
selection which breaks the whitelisting process of determining the
ABI selection procedure.  This commit changes the ABI selection mode
based upon the ABI selection types that exposed by Unity rather than
relying upon whitelisted versions.

Bug: 130250379
Change-Id: Ib8d7bc7b28d2d014f8e38536265377e40443c892

The ToolNotFoundException contains the right reference but the Unity Editor log contained the unresolved path, an empty string.

* Android Resolver: Whitelisted Unity 2017.4 and above with ARM64 support.
* Android Resolver: Fixed Java version check to work with Java SE 12 and above.

Change-Id: I341a4776cf5bc86ca514d7a6091d245cb6cba2bf

Some versions of the JDK do not have the minor version when reporting
their version. Changing to use the Version class to help handle the
parsing.

Change-Id: I0eeea1ad69da4afeac6da1e8f035377d71156446