Cache bleed between Windows/Android builds, ETC1 texture error. Bug?

Hi,

I'm developing our build system to output Windows/Android/others in one go, and I'm sporadically getting this error:

"ETC1 compressed textures are not supported when publishing to Standalone"

This happens consistently when doing a Windows build after having last done an Android build, leading me to think that there's some cache bleed between the two platforms, causing Android textures to be attempted used on Windows. Strangely, a second Windows build then works.

I'm looking for tips on how I can work around this. It appears to have been a bug for a long time. I'm on 2022.1.0a7, but I'm seeing reports going back several years. Presumably there's some cache I'd be able to clear to work around it, although wiping the entire cache would be devastating, since I'm doing incremental builds of asset bundles and have a lot of assets.

Per

 

I'm starting to understand this better, although seems still to be a bug.

I've been trying to SwitchActiveBuildTarget in script prior to running BuildPipeline for that target, and it's no better. Now I'm finding this note in the docs at https://docs.unity3d.com/ScriptReference/EditorUserBuildSettings.SwitchActiveBuildTarget.html :

Note: This method is not available when running the Editor in batch mode. This is because changing the build target requires recompiling script code for the given target which cannot be done while script code is executing (not a problem in in the editor as the operation is simply deferred but batch mode will immediately exit after having executed the designated script code). To set the build target to use in batch mode, use the buildTarget command-line switch.

Of course, that's what I did from the beginning, and it didn't work. So I think that BuildPipeline.BuildPlayer is broken, in that there's an additional step the editor need to do when switching from Android to Windows that it can't get to do during batch mode. But switching in the editor and then running the build script for Windows works.

It seems like it would take half a day to create a reproduction project for this, so I'd love to hear if others agree that it's a bug before I put in the work.

In the meanwhile, my build system runs on a lot of async/await, and this is part of why the BuildPipeline can't come up for air after switching platform but before building. I'm going to capitalize on the fact that I'm running my build system from within the editor, and roll some kind of Timer-based callback thing instead, which would allow the editor to stabilize after switching platforms but before building.

 

After having gone in circles all day, the workaround cannot work, and it's not possible at all to make a build script that builds several platforms unattended:

*

buildPlayerOptions.target = target;

is supposed to change the target during batch build, but it has a bug when switching from Android to Windows that requires Editor idle cycles to resolve, or Android ETC1 textures get fed into the Windows build (and what else bleeds over?).

* EditorUserBuildSettings.SwitchActiveBuildTargetAsync can't be used in batch mode because it recompiles scripts, thereby also stopping execution of your build script.

I'm going to bite the bullet and have a manual step for switching platform and running the build script. Super duper bummer.

I wonder if this bug is there in Cloud Build too, that platform switch isn't complete even when feeding the right options to BuildPlayer.

 

It's this bug, which has remained unresolved (but marked fixed) for several years: https://issuetracker.unity3d.com/is...n-build-after-switching-platform-from-android

This example specifically switches from Android to Windows during a build, and predictably gets the "ETC1 compressed textures are not supported when publishing to Standalone".

And this makes it effectively impossible to make an unattended build system for multiple platforms. I have to suspect that Cloud Build has the same bug.

I am finding that this is specifically about Android not switching properly to Windows, and by putting builds in the right order, and ensuring that I'm standing on desktop before starting, I can build Windows, Linux and Android in one go unattended. So the workaround is that I've put a warning dialog into the build system, to ensure the operator takes this step first.

 

Since original report is marked fixed (but isn't), I've opened case 1372016.