hello_xr: Bump AGP to 7.0.4

[utzcoz]

Fixes: #327.

It will help to fix building of hello_xr on macOS M1.

[utzcoz]

Hi @rpavlik , I only update AGP for hello_xr, and I can build it on M1 now. I don't change AGP of loader, so IMO it will not affect loader's building and release.

[rpavlik]

Ah great! The release binaries for the loader actually don't even use Gradle, so no problem to upgrade that too.

[utzcoz]

@rpavlik What about updating loader AGP version at later PR?

[rpavlik]

Sure, no problem. I was just struggling with some upgrades today on the broker, but the main OpenXR repo is simpler since it's basically c++ only.

[utzcoz]

I will first update AGP for OpenXR-CTS to ensure I can build it on M1 device.

[rpavlik]

Any particular reason to update to this version instead of the latest?

(Also the loader gradle probably shouldn't get used much since I expect I won't be able to do the equivalent of #332 to it, we were already using the bash+cmake scripts to make the aar's for releases because at least older AGP made a huge mess with duplicate files in them, but yes, I'll update that. FWIW, any pull request on any of these repos does get imported into the internal one once merged, it just won't make it back out to other repos until the next release.)

Testing now, looks good, thanks!

[utzcoz]

Any particular reason to update to this version instead of the latest?

This PR just wants to building Android works on M1. I can try to update it to latest 7.3.0.

Also the loader gradle probably shouldn't get used much

I often debug loader with HelloXR together. In personal need, I hope it can work with HelloXR one.

I know bash + cmake are used to build aar release artifact, but I also hope it can be done by Gradle directly with just one command.

Thanks for reviewing.

[rpavlik]

Any particular reason to update to this version instead of the latest?

This PR just wants to building Android works on M1. I can try to update it to latest 7.3.0.

ah, sounds good, no problem.

Also the loader gradle probably shouldn't get used much

I often debug loader with HelloXR together. In personal need, I hope it can work with HelloXR one.

Do you build hello_xr separately like not in the same tree as the loader and using the loader AAR?

I know bash + cmake are used to build aar release artifact, but I also hope it can be done by Gradle directly with just one command.

FWIW, you can run maintainer-scripts/build-aar.sh and a few minutes later you'll get the AAR :)

Thanks for reviewing.

[utzcoz]

FWIW, you can run maintainer-scripts/build-aar.sh and a few minutes later you'll get the AAR :)

Thanks. I will give a try. Looks like it is very simple.

Do you build hello_xr separately like not in the same tree as the loader and using the loader AAR?

I often build HelloXR with loader in the same tree. Oh looks like Loader is integrated into HelloXR with cmake. It's safe to update loader's AGP version. I can try this weekend or next week to update all of them to the latest version.

[rpavlik]

Yeah, the loader, hello_xr, layers, and CTS are all in the same CMake build system. Very convenient for early spec development, very not-convenient for public consumption and contribution 🤣 All of the Gradle build systems that actually build code in the tree, all point to the root CMake, they just pick different subsets of projects to build. Until very recently, Android Gradle Plugin didn't support dependencies between native modules in a single build, so we have some fairly repetitive gradle stuff, but it works.

Thanks for all your hard work and contributions to OpenXR on Android, I really appreciate it. Feel free to send me an email some time and introduce yourself, I'd be interested to know more about your background and what motivates these great contributions. 👍