So somewhere around the start of COVID I finally switched my "daily driver" from my old Mac laptop to a Windows 10 desktop, but there are two things that I continued doing on the Mac laptop exclusively:

- Building APKs with the command line tools, because it's kind of partially reliant on a UNIX toolchain

- Running "FileMerge.app", because I still haven't worked out how to launch Meld correctly from inside WSL.

UPDATE: After some fiddling, I am invoking the cmake installed by Android Studio with the Android toolchain file installed by Android Studio and on running it the first thing it does is print an error about Microsoft Visual Studio not being properly configured, which is definitely not the error you want to be seeing when you are trying to build an Android APK

FURTHER UPDATE: Trying to re-invoke a previously invoked line in Windows command line I accidentally copy-pasted

C:\Users\Andi\work\g\lovr\build-apk>%ANDROID_HOME%\cmake\3.22.1\bin\cmake.exe

into the command line, which if you think about it attempted to invoke the current directory as a command, failed, printed nothing to stdout, redirected that nothing to the path to cmake.exe, and truncated cmake.exe to be a 0-length file which now obviously can't be executed

This has lead me to discover that Android Studio is technically speaking unable to uninstall a damaged installation of a tool it previously installed, for example in case you accidentally damaged it and now you want to uninstall it for that exact reason

Computers.

UPDATE: It works now but I'm only about 30% certain I know why

Now that I am able to invoke CMake at all, I am hitting a different wall: LuaJIT builds a Windows helper application as part of its build, but now that I have craftily set up to invoke Android CMake, it cannot build a Windows exe from the Ninja generator.

I search Google for this problem, and the second hit, and first relevant hit, is… a Twitter thread I made in 2020, me, the last time I hit this exact problem. Reading the thread, at that time I did not find a solution.

https://twitter.com/mcclure111/status/1220822530904084480?lang=en

I have bodged around the cross compile problem with a highly non-replicable local hack and how have hit what feels like a "final boss" error message:

-Djava.ext.dirs=C:\Users\Andi\AppData\Local\Android\Sdk\build-tools\33.0.1\lib is not supported. Use -classpath instead.

At no point does -Djava.ext.dirs appear in the invocation line that produces this error. In addition, the application I am building is written in C

Update: After further drilling, the problem turns out to be that d8, a standard Android tool and **actually secretly a bat file**, contains an incompatibility with modern Java. This is the "new" dexer introduced in 2017. It requires Java 8 or older to run. No idea where I'm supposed to get that; Android Studio installed Java 11.

https://stackoverflow.com/questions/59896708/error-while-running-dx-or-d8-tool-for-android

SO notes you can edit the file to fix this but "However, since Android Studio notices such changes, it removes those files from time to time"

Final(?) update: I was able to resolve the nightmare bat problem by upgrading my Android build tools from 33.0.1 to 34.0.0-rc2. The problem just disappeared. Terrifying.

After a full workday of fiddling I am now able to build APKs on Windows as long as I invoke the build three times, after each of the first two unsuccessful builds manually copying a file that CMake put in the wrong place. This is one of those successes that makes you just feel more defeated than if you'd lost

I mentioned my various problems to the guy who runs the engine project I was trying to compile this whole time, and he observed that he simply builds inside WSL and it works really great and there are no problems at all.

I GUESS MAYBE I'LL DO THAT NEXT TIME.

Postscript: Although I believed I had succeeded last night due to producing a complete APK, what I did not know was the APK I thus built does not *run*; installing it leads to "Failed to extract native libraries, res=-2]", a recurring bug with several possible causes but seeming to imply a bug in a official Android tool such as zipalign.

I have returned to building the Android binaries on my old Mac laptop, and those work.

@mcc That's why I'm only ever producing builds of my games using Linux containers, cross-compiling to all other platforms. Once the container image is done, it will keep working on whichever machine I run it on, making automated CI trivial. Rebuilding the container itself is also automated, so updating the SDK or augmenting with additional libs if necessary is not a big deal either.
I got sick of having to rely on some arcane SDK installation on a single system that I was then afraid to touch :P