Android Packaging Taking > 12hrs. What's up?

Development Platform & Builds
, , , , ,
1

I am using a custom source build of UE4.21.1 from GitHub and am trying to deploy a mobile GoogleVR app to android for the first time. This is my first time deploying since installing the Android prerequisites in Engine/Extras/AndroidWorks and for some reason my packaging is taking forever. I started one build last night and it wasn’t finished in the 9 hours I was away, so I stopped and restarted it and it has been running for over 12 hours now. The output log has been stuck at

UATHelper: Packaging (Android (Multi:ASTC,PVRTC,DXT,ATC,ETC2,ETC1)): LogCook: Display: Sandbox cleanup took 0.037 seconds for platforms Android_Multi iterative false

for the vast majority of that time and no further output has been logged. UAT has been, and still is, running according to TaskManager.

As you can see from the line above, I am doing a first time package for all Android targets, so I expected this to take a while, but should this really take 12 hours on a reasonable development rig?

I’m running Win 8.1 - 64bit with 32GB RAM a 3.4GHz i7-6800K and a GTX1070.

Anyone seen this before? Anyone know why this might be happening? Any help would be greatly appreciated.

Update: I’ve attached a full log. I’ve now tried this while packaging with ATC separately and ETC1 separately and it seems to stop outputting anything after the “Unable to read previous cook inisettings for platform Android_ETC1 invalidating cook” step. Still not really sure where to go from here, but that last part leads my to believe it’s going into the weeds during the cooking process.

2

Answer to my own question:

I appears that Avast! antivirus was blocking the package process by refusing to run some Incredibuild executables without letting me know. I was able to package by disabling Avast! and I suspect adding an exception for the Xoreax program file directories should eliminate this problem, but I will need to confirm that.

Update: I have confirmed that this was indeed the issue and that adding an exception to Avast for the AndroidSDK and Xoreax directories resolved the issue.