Android and Daydream UBT issue.txt

So, a rough outline of the problem (NB- I'm using 'Launch' as a scenario here, but a similar set 
of issues occur when trying to package):

The Issue
* I create a blank UE4 project
* I add a single C++ class (an AActor subclass, but any C++ game code would work)
* I use the Launch menu to launch to my attached android phone
* I sit around for a while as it does a bunch of building and eventually deploys, success!

- PROBLEMS START HERE -

* Without changing anything in my project, I hit Launch again
* It fully rebuilds the apk, for no good reason
* It fully rebuilds the apk AGAIN, still for no good reason
* It finally deploys to device
* Me: (╯°□°)╯︵ ┻━┻

Analysis So far
Since this makes any Launch command take 4-5 minutes, I decided to dig in and try and figure out 
what's going on and why a rebuild is getting triggered. These are my notes:

* A rebuild is triggered when either build settings change (makes sense) or when the android 
manifest file has changed (sure also makes sense)
* The launch command actually calls UEDeployAndroid.MakeApk() multiple times. I don't really 
understand the reasoning behind this, but it's called in both the build and deploy steps.
* MakeApk() is what generates the manifest, based on the parameters passed in.
* One of the MakeApk() calls has some hardcoded parameters that differ from what gets passed in the 
other call. This leads to a really dumb ping-pong of constant rebuilds like so:

- Start Build -
Configure with argument set A
We need to build! Build.
Configure with argument set B
We previously built with argument set A, rebuild...
- End Build -

- Start Next Build -
Configure with argument set A
We previously built with argument set B, rebuild...
Configure with argument set B
We previously built with argument set A, rebuild...
- End Build -

Last set of steps re-occurs every subsequent time you build

So once I sorted that out, my next step was determining what in the manifests was changing, 
and it looks like there are two different elements:
* In one of the calls the cookflavor that's being specified by the launch command isn't being 
respected. It's hardcoded to enable *all* possible texture compression variants. Each variant gets 
a line in the manifest. In the other call the cookflavor is respected, and so only the lines for that 
texture format get added to the manifest
* One of the calls sets the manifest to expect an obb file, the other call does not. For a launch 
expecting an obb does not make sense, since data is not packaged that way (individual assets are 
streamed to a spot in phone storage and picked up from there, it allows faster testing)

So at the lowest level that's what's causing the issue. I tested 'fixing' this by forcing the 
cookflavor and obb setting in MakeApk() and as expected the Launch times go from ~250-300 seconds, 
to ~20 seconds. Much better!

Where I'm stuck
I have no clue on how to take this knowledge and revamp the calls to respect the parameters 
determined by launch. I'm currently following a chain of stuff from the launcher c++ -> RunUAT.bat 
-> the C# files for automation tool and build tool.

The broken MakeApk() call is in UEDeployAndroid.PrepTargetForDeployment(), the correct one is 
in UEDeployAndroid.PrepForUATPackageOrDeploy(). PrepTargetForDeployment doesn't seem to have an 
easy way to access all the values that PrepForUATPackageOrDeploy() does? This is where I'm still 
digging to try and figure out how to make the values consistent between the calls.