Bug 25518 - [Android] Unable to update Android Support libraries building via CC.NET / MSBuild
Summary: [Android] Unable to update Android Support libraries building via CC.NET / MS...
Status: RESOLVED INVALID
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 4.20.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Jon Dick
URL:
Depends on:
Blocks:
 
Reported: 2014-12-18 19:01 UTC by Kent Green [MSFT]
Modified: 2014-12-29 14:15 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Html file of customer's build logs (2.47 MB, text/html)
2014-12-18 19:01 UTC, Kent Green [MSFT]
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED INVALID

Description Kent Green [MSFT] 2014-12-18 19:01:36 UTC
Created attachment 9136 [details]
Html file of customer's build logs

---Overview---
From this desk case:
https://xamarin.desk.com/agent/case/111704

Customer reports they're unable to update Android Support libraries building via CC.NET / MSBuild. They also noted that some of the paths appeared to be wrong:

> <message level="normal"><![CDATA[ C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v7.AppCompat\20.0.0\content\support/v7/appcompat]]></message>

The customer reported they were able to partially workaround the issue by using the Xamarin NuGet packages as opposed to including them manually; which corrected the invalid paths but still caused the wrong package versions to be included. After this change, they noted the following from the build log:

AdditionalAndroidResourcePaths:
> T:\trunk\Thirdparty\Packages\Xamarin.GooglePlayServices.22.0.0.0\lib\MonoAndroid41\22.0.0\embedded\./
> C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v4\21.0.3\embedded\./
> C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v7.AppCompat\21.0.3\embedded\./
> C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v7.MediaRouter\21.0.3\embedded\./

But the actual version present is still in the same folder:
> C:\Users\Administrator\AppData\Local\Xamarin\Android.Support.v7.AppCompat\18\content\support\v13

---Additional Note---
Attaching customer's build logs they sent as well. (Note that these logs are *very* large)
Comment 1 Jonathan Pryor 2014-12-19 12:26:21 UTC
@Redth: Support libraries are your baby, and I'm not entirely sure what's going wrong here. :-(

My one guess is our %MAX_PATH% "optimization" in which we extract resources for Xamarin.* assemblies into %USERPROFILE% (as seen above), but I don't understand why this would be a problem...
Comment 2 Richard Urwin 2014-12-20 05:45:55 UTC
Hi,

Our build path is longer than MAX_PATH by default, so we've mapped a network drive to enable it to work:

E:\CCNet\Projects\NativeApps\Android

=>

T:\

I can't immediately see why this should be an issue either though.

All I know is that when building via VS2013, the support libs get copied into this path:

C:\Users\Rich\AppData\Local\Xamarin

I can see folders in here, for example:

Android.Support.v4
Android.Support.v7.AppCompat
Android.Support.v7.MediaRouter
etc.

And (as an example) the first of which contains folders corresponding to API versions:

18, 20, 21.0.3

No such folders get created when building from CC.NET (i.e. MSBuild) however.

Cheers,
Rich
Comment 3 Richard Urwin 2014-12-20 05:47:55 UTC
(ignore the 'Rich' in the path - that's copied from my dev computer, but the same happens on the actual build computer).
Comment 4 Jon Dick 2014-12-22 09:34:58 UTC
So the build works fine in VS2013?

Is the CC.NET build server not able to access a %USERPROFILE% path for some reason?  

The fact that you see logs with AppCompat\20.0.0 paths sounds like something is still being cached, or maybe one project is still referencing an older version?  

Have you switched everything over to use NuGet packages now, and are you sure the packages.config files all reference the correct version of the packages?
Comment 5 Richard Urwin 2014-12-23 07:19:57 UTC
Hi,

Yes, the build is fine in VS2013.

It was also previously OK in CC.NET / MSBuild as well though so I'm not sure what's changed.

CruiseControl.NET is running as LocalSystem. Perhaps this is it?

We have indeed switched everything to NuGet. 

I've cleaned / updated / rebuilt, and now all of the versions in the build log are correct, it's just that the corresponding support lib files aren't getting copied in to the folder where they're needed for the build. Here are the packages we're currently referencing that aren't getting copied:

Xamarin.Android.Support.v4.21.0.3.0
Xamarin.Android.Support.v7.AppCompat.21.0.3.0
Xamarin.Android.Support.v7.MediaRouter.21.0.3.0
Xamarin.GooglePlayServices.22.0.0.0

and here are the AdditionalAndroidResourcePaths:

AdditionalAndroidResourcePaths: ]]></message>
              <message level="normal"><![CDATA[    T:\trunk\Thirdparty\Packages\Xamarin.GooglePlayServices.22.0.0.0\lib\MonoAndroid41\22.0.0\embedded\./]]></message>
              <message level="normal"><![CDATA[    C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v4\21.0.3\embedded\./]]></message>
              <message level="normal"><![CDATA[    C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v7.AppCompat\21.0.3\embedded\./]]></message>
              <message level="normal"><![CDATA[    C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v7.MediaRouter\21.0.3\embedded\./]]></message>

Incidentally, at one point, I was getting confused between the Administrator userprofile and the LocalSystem userprofile. As you can see, the latter is here:

C:\Windows\System32\config\systemprofile\AppData\Local

but there's still nothing in it.

- Is there some sort of pre build step that I can run to extract and copy the files into the correct place?

- Perhaps there's a path I can somehow add to the javac.exe command to replace (for example) the following?

C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v4\21.0.3\embedded\classes.jar;

The full javac.exe command is here:

<message level="high"><![CDATA[C:\Program Files\Java\jdk1.7.0_71\\bin\javac.exe -J-Dfile.encoding=UTF8 -d obj\Release\android\bin\classes -classpath "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v5.0\mono.android.jar;obj\Release\__library_projects__\AmazonMobileAnalytics\library_project_imports\aws-android-sdk-2.1.1-core.jar;obj\Release\__library_projects__\AmazonMobileAnalytics\library_project_imports\aws-android-sdk-2.1.1-mobileanalytics.jar;obj\Release\__library_projects__\HockeyApp.Android\library_project_imports\HockeyApp.Android.Jars.HockeySDK-3.0.1.jar;obj\Release\__library_projects__\R1Connect\library_project_imports\LibR1Connect.jar;obj\Release\__library_projects__\UniversalImageLoader\library_project_imports\UniversalImageLoader.Jars.universal-image-loader-1.9.2.jar;obj\Release\__library_projects__\UniversalImageLoader\library_project_imports\__reference__opencv library - 2.4.9.jar;obj\Release\__library_projects__\Xamarin.Facebook\library_project_imports\Xamarin.Facebook.Jars.AudienceNetwork.jar;obj\Release\__library_projects__\Xamarin.Facebook\library_project_imports\Xamarin.Facebook.Jars.bolts.jar;obj\Release\__library_projects__\Xamarin.Facebook\library_project_imports\bin\classes.jar;T:\trunk\Thirdparty\Packages\Xamarin.GooglePlayServices.22.0.0.0\lib\MonoAndroid41\22.0.0\embedded\classes.jar;C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v4\21.0.3\embedded\classes.jar;C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v4\21.0.3\embedded\libs/internal_impl-21.0.3.jar;C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v7.AppCompat\21.0.3\embedded\classes.jar;C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v7.MediaRouter\21.0.3\embedded\classes.jar;C:\Windows\system32\config\systemprofile\AppData\Local\Xamarin\Android.Support.v7.MediaRouter\21.0.3\embedded\libs/internal_impl-21.0.3.jar" -bootclasspath "C:\Program Files (x86)\Android\android-sdk\platforms\android-21\android.jar" -encoding UTF-8 "@C:\Windows\TEMP\tmp2C10.tmp" ]]></message>

We're getting pretty desperate because we need to release the new Android app ASAP.

Thanks,
Rich
Comment 6 Richard Urwin 2014-12-23 07:30:43 UTC
This looks like a similar problem:

http://stackoverflow.com/questions/21068646/how-do-i-set-up-teamcity-ci-so-that-it-unpacks-xamarin-components

is there a way I can do this easily?
Comment 7 Richard Urwin 2014-12-23 08:59:19 UTC
I've copied the Xamarin folder from my local computer:

C:\Users\Rich\AppData\Local\Xamarin

to

C:\Windows\System32\config\systemprofile\AppData\Local\Xamarin

which seems to mitigate this problem (until the Android API version changes at least) however the next issue is this; classes from GooglePlayservices can't be found - e.g.

com.google.android.gms.drive.events.DriveEvent.Listener

One issue I can see is that it's looking here:

 AdditionalAndroidResourcePaths: ]]></message>
              <message level="normal"><![CDATA[    T:\trunk\Thirdparty\Packages\Xamarin.GooglePlayServices.22.0.0.0\lib\MonoAndroid41\22.0.0\embedded\./]]></message>

wheras I suspect it should be looking here:

T:\trunk\Thirdparty\Packages\Xamarin.GooglePlayServices.22.0.0.0\lib\MonoAndroid41\22.0.0\embedded\

Note that the './' on the end of the path make it invalid.

Help!
Comment 8 Jon Dick 2014-12-23 15:53:49 UTC
Adding Dean to this issue.  I'm not sure exactly what the problem is yet.  I'm not convinced the ./ at the end of the path is an issue.  I'd expect it to fail in VS2013 as well if that were the case. 

Is there any way you can get CC.NET to build as a local user instead?

Perhaps you can build locally for your upcoming release.  I suspect this won't be resolved before the new year.
Comment 9 Richard Urwin 2014-12-24 08:36:34 UTC
Hi,

If I cut and paste the path with the ./ on the end into Windows Explorer, I get an error - path invalid. If i try without, it works fine. The decompressed GPS libraries are in this folder, so fixing this would fix the problem.

We might be able to have CC.NET run as Administrator, but it may cause permissions issues. I'd quite like to get it running as is, especially since it worked before.

Unfortunately we perform lots of configuration during the build, so building locally would require a lot of manual intervention.

Is there a way in which I can somehow add another path (the valid one) to the AdditionalAndroidResourcePaths? Perhaps in a Xamarin build config somewhere?

Cheers,
Rich
Comment 10 Richard Urwin 2014-12-26 05:26:22 UTC
This path is also output in the VS2013 (diagnostic) build output:

T:\trunk\Thirdparty\Packages\Xamarin.GooglePlayServices.22.0.0.0\lib\MonoAndroid41\22.0.0\embedded\./

so back to the drawing board...
Comment 11 Richard Urwin 2014-12-26 15:20:37 UTC
Hi,

Which version of java is recommended? I have SE 71 32-bit.

Thanks,
Rich
Comment 12 Richard Urwin 2014-12-27 03:59:24 UTC
(I previously had v7, 64-bit).

I now get lots of:

COMPILETODALVIK : warning : Ignoring InnerClasses attribute for an anonymous inner class 

followed by:

COMPILETODALVIK : UNEXPECTED TOP-LEVEL error :  [T:\trunk\Source\Psonar.Apps\Psonar.Apps.Droid\Psonar.Apps.Droid.PayPerPlay\Psonar.Apps.Droid.PayPerPlay.csproj]
  java.lang.OutOfMemoryError: Java heap space (TaskId:1132)
...

despite having set the heap size to 2G
Comment 13 Richard Urwin 2014-12-27 13:07:47 UTC
Finally managed to fix it:

1) 64-bit java doesn't work

2) I needed to add the heap size to each of the build configurations in the .csproj file since adding the settings as environment variables to _JAVA_OPTIONS / JAVA_OPTS doesn't work.

1G is enough for the heap size.
Comment 14 Jon Dick 2014-12-29 13:32:07 UTC
@Richard thanks for posting your progress in fixing this, and apologies that the holidays got in the way of responding to it more timely.

Glad it's resolved!
Comment 15 Richard Urwin 2014-12-29 14:15:36 UTC
No worries - thanks!

Rich