ProcessAARs task failed unexpectedly


(Jolyon Direnko-Smith) #1

I’m trying to incorporate Google Play Services in an Oxygene project (Elements 9.0 RTM release) and am stumbling at a very early hurdle.

I (eventually!) came across the information that google-play-services is now decomposed into constituent aar packages, but when I try to add these as references to my project the build fails with a “ProcessAARs task failed unexpectedly” error.

The output window suggests that the ProcessAARs, um, process, is trying to locate the aar files in the project folder itself (no subdirectory or other path):

(MSB4018) The "ProcessAARs" task failed unexpectedly.
System.IO.FileNotFoundException: Could not find file
File name: 'C:\Users\jolyon\Dropbox\dev\src\elements\AndroidApp\play-services-10.0.1.aar'
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
at System.IO.Compression.ZipStorer.Open(String _filename, FileAccess _access)
at RemObjects.Oxygene.MSBuild.Android.ProcessAARs.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()

I also noticed that aar references are added with Copy Local set False where-as jar references are added with this set True. Changing the setting (for aar references) doesn’t make any difference to the error, or the path involved.

I have tried adding references to the aars in their Android SDK\extras location and copying them to a subfolder of my project folder and adding references to them from there with no change on the outcome.

What am I doing wrong ? :frowning:

UPDATE: Since the process was insisting on looking in the project folder, I tried putting the aars in that folder, and now the ProcessAARs task no longer fails but I am now getting an “unreferenced assembly” error (indirectly referencing type

There being no play services aar for “common” I am at a (further) loss. :frowning:

(Carlo Kok) #2

hrmm this sounds wrong. We’ll look into it.

(RemObjects) #3

Thanks, logged as bugs://76897

(Jolyon Direnko-Smith) #4

Thanks Carlo. Does the “bug” encompass the subsequent ReflectedParcelable issue as well ?

i.e. if aar references were working correctly the ReflectedParcelable reference problem would also be addressed.

Or is that a separate issue ? If it’s a separate issue is it one that can I deal with in the meantime by adding some other jar or aar reference (and which one(s)) ?

Many thanks in advance.

(Jolyon Direnko-Smith) #5

Update: I’ve tried referencing the aar’s from their original SDK\extras location using the 9.1 beta and the ProcessAARs task error does not occur (and the references are added as Copy Local true).

Hmmmm, perhaps I should have tried that earlier but I was wary of using such an early beta after an RTM.

However, I am still getting the error:

(E326) Indirectly used type "" is defined in an unreferenced assembly

This may simply be because I haven’t added the required package reference to support those packages that I have added references for, but I have no idea which reference that is supposed to be !!

Should I be using a build.gradle for this ?

I tried adding a build.gradle file with the dependencies as directed by the various steps for all this (for Android Studio based projects) but as far as I could tell this made absolutely no difference to my build or project, either in the compilation output or the results. I have installed gradle and set the path in the Visual Studio settings.

What should I expect to see if the build.gradle is being processed (or not) ?

Am I barking up completely the wrong arboretum ? O.o

On this score, Google Play Services are (seemingly) such a fundamental aspect of Android development it might be worth considering some direct tooling support in this area, if applicable/possible (assuming that the solution to my problem isn’t entirely straightforward).

e.g. wizards to add the required packages for specific Play Services Api’s.

Anyhoo, fingers crossed I can get past this and crack on with building my app soon. :slight_smile:

(Carlo Kok) #6

Curious yes, I didn’t expect the beta to have changes in regards to this. I’llcheck.

ReflectedParcelable isn’t really related to this, it’s basically because that type is defined in another jar/aar which isn’t referenced. It’s defined in play-services-awareness-10*.

Gradle has a template issue, it needs Build Action: Gradle instead of Content, already logged. Unfortunately, latest Gradle has broken it’s interface again. Older gradle versions work fine, newer ones don’t.

(Jolyon Direnko-Smith) #7

I have fixed the Build Action, removed the manually added references and have the following in my build.gradle file:

dependencies {
    compile ''
    compile '' 

Assuming that is correct, the problem now is that although I am now seeing gradle output in my build ( \o/ ) unfortunately that output indicates an error that has me befuddled all over again:

assemble UP-TO-DATE
:check UP-TO-DATE

FAILURE: Build failed with an exception.

* What went wrong:
Failed to capture snapshot of output files for task 'copyDeps' property 'destinationDir' during up-to-date check.
> Failed to create MD5 hash for file 'C:\Users\jolyon\Dropbox\dev\src\elements\MyAndroidApp\obj\Debug\Android\dependencies\.gradle\2.14\taskArtifacts\'.
> The process cannot access the file because another process has locked a portion of the file

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

Would it help at all to run with those suggested options (if so, how ?) or is this simply related to the version of gradle I’ve installed ? I’ve tried 3.2.1 (the latest, before I had this warning) and now 3.1 and 2.14 (which I noticed was the version referenced in a screen shot of the docs so figured that was a likely candidate).

I get the exact same error with each version I’ve tried (thus far). The only minor variation being that the line about the “locked portion of the file” is only present when running with 2.14.

FYI just in case I’ve messed up with the install/config… I have placed each version of gradle I have tried (thus far) into folders as follows:


With each version, I have set a GRADLE_HOME environment variable to one of the above folders (with %GRADLE_HOME%\bin in my path). After making any changes here I obviously restart Visual Studio to make sure it picks up the new environment.

Finally, in Visual Studio I have then also set the Gradle folder setting to the corresponding c:\gradle<ver> folder. The gradle version is reflected in the different folder paths emitted in the error above but other than that the errors are consistent: I get the same MD5 hash issue with each of the above versions.

How much older are the versions that “work fine” ? What version should I be using ? O.o

Many thanks in advance,

PS - I presume the original problem with manually adding AAR’s was a complete wild goose chase. The “first problem” was the fact that the gradle dependencies weren’t coming in because of the Build Action issue, leaving me now just to solve this final puzzle ? I hope ? :slight_smile:

(Carlo Kok) #8

I think it would be a lot easier to just wait for tomorrows build :slight_smile: Not sure which version does this. If you’re in a rush, ping me privately, I’ll send a fixed build.

(Jolyon Direnko-Smith) #9

OK, awesome. I’ll wait for the new build. Thanks. :slight_smile:

(marc hoffman) #10

there will be a build tomorrow? :wink:

(Jolyon Direnko-Smith) #11

Don’t rush on my account. This weekend is this years 24 hour movie marathon (an annual event - this year marking my 10th straight!). It kicks off at around 3pm tomorrow, but we line up from around 1pm and the morning is spent stocking and packing our survival “kit”.

Bottom line: I won’t be able to spend much time with any new build this weekend.

Having said that, I have Monday off, so … :slight_smile:

(marc hoffman) #12

Is this issue resolved for you?

(RemObjects) #13

bugs://76897 got closed with status fixed.

(Jolyon Direnko-Smith) #14

Yep, thanks. :slight_smile:

Side bar: Aside from the actual problem with the Gradle support, my problem wasn’t helped by having to fumble around in the dark initially not knowing really what I was supposed to do and what to expect when things were working (making it difficult to know if/when things weren’t working as expected).

Are there any plans to provide documentation on this stuff ?

(marc hoffman) #15

yes :wink: