Suggestions for improving build/iteration speed for Daydream projects?

[rje]

I recently started working on a daydream project and for the most part everything is working great, but we've noticed that iteration speed is much worse than it is with a stock android project. Most notably, after launching to device I'd expect a subsequent launch with no changes to be quick (and in a stock android project, it is - just a few seconds).

But configured for daydream each launch takes about 3 minutes regardless of whether or not we've changed anything.

Notably, it seems to be configuring and compiling the apk twice? From watching the build process it seems like this is definitely the lion's share of the time. Is there something in the googlevr plugin that would cause this to happen?

I've attached a sample output log from a launch attempt. This is a subsequent run with no changes made to the project since the previous launch, and you can see it's taking just shy of 200 seconds to completely deploy to device. Even if it's just some hints for where to start looking to improve the situation, I'd greatly appreciate any advice!

[bsawler]

This is a major pain point for us as well. Multi-minute delays just trying to re-launch via the editor for even a small data change (changing an .ini file) or even no change at all.

[rje]

Out of curiosity I created a blank project and tried enabling/disabling several different plugins/settings to try and nail down the root cause of the issue.

• Stock blank project: works as expected (~3s for subsequent launches)
• Stock blank project + googlevr plugin: Does not work as expected
• Stock blank project + googlevr controller plugin: Does not work as expected
• Stock blank project + arm64: works as expected (~3s for subsequent launches)
• Stock blank project + arm64 + googlevr plugin: Does not work as expected
• Stock blank project + arm64 + googlevr controller plugin: Does not work as expected

Is there something in a build.cs or UPL script that would cause a full rebuild to occur?

[Chris Babcock]

Turning on a plugin makes the project considered a code project since it needs to be relinked (does not use the prebuilt .so in Engine/Binaries/Android).

[rje]

Turning on a plugin makes the project considered a code project since it needs to be relinked (does not use the prebuilt .so in Engine/Binaries/Android).

Hey Chris, thanks for the reply. Just so I'm clear - it's expected behavior that building and relinking is required for every launch if you're using a plugin? I certainly understand it's required for the initial launch after enabling it, I'm surprised that it's required for subsequent launches. Any thoughts as to why it appears to be building the apk twice per build? Or am I just misreading what's occurring during the build process?

[Chris Babcock]

I think UPL is confusing it; the timestamps might be changed by it copying the files into place.

[aussieburger]

I think UPL is confusing it; the timestamps might be changed by it copying the files into place.

So it's really expected behavior that subsequent build times take this long for a daydream project even if you change something very minor (or nothing at all)? Surely something could be improved there for 4.15? as it really slows devs down...

[Chris Babcock]

I'll look into it, but I can't guarantee it for 4.15.

[JonTerp]

Has any progress been made on this? Android iteration times are very long, it takes sometimes up to 5 minutes to deploy a small iterative build even with all the "Cook / deploy only modified files" option checked.