KhronosGroup
Publish an AAR for Android developers.
This extends the existing Android workflow to collect the validation layer libraries into an AAR that is published to the repository's GitHub Packages Repository. This way, Android Gradle users can point their build at this repository and add a new dependency to their build.gradle.kts file rather than needing to download and manage the artifacts manually.
Fixes https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/8167
The alternate implementation would be to restructure all of the Android build as a Gradle project. Most of this workflow (and both of the Python scripts it calls) could be deleted since this behavior is all included in the Android Gradle Plugin (AGP). I opted not to do that because it's much more invasive, and people that aren't already Gradle users generally don't like Gradle being added to their projects :) It'd also have an impact on the build speed of the project (but only for this workflow, which only runs for new tags), since AGP builds each ABI in series rather than in parallel like the current workflow does. If you would actually prefer I do it that way, lmk, I don't think it's actually much work to migrate to that, since it's mostly deleting code.
You can see this in action on my fork: https://github.com/DanAlbert/Vulkan-ValidationLayers/actions/runs/9999981314 publishes https://github.com/DanAlbert/Vulkan-ValidationLayers/packages/2208155, which can be used like https://github.com/android/ndk-samples/pull/1072.
Unfortunately I've just found out that GitHub requires authentication to read public packages for maven/gradle registries (everything but docker images?)
https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-apache-maven-registry
You need an access token to publish, install, and delete private, internal, and public packages.
That actually makes this quite annoying to use (especially for anyone that would want their repository to be easy to build and clone without configuring that, which is probably most). I'd suggested GHR in the feature request because I'd thought it would be easiest. Since that seems to not be true, this should probably be tweaked to publish somewhere like Maven Central?
Author DanAlbert not on autobuild list. Waiting for curator authorization before starting CI build.
Since that seems to not be true, this should probably be tweaked to publish somewhere like Maven Central?
The PR doesn't have to change much for this, but someone on the Khronos side would need to set up an account somewhere (I've never done it, so I'm not sure exactly what's involved, but if you're okay with doing that I'll figure it out as part of reworking the PR and let you know, I expect it's easy). Maven Central would be the easiest on developers since every AGP project already has that repo configured, but if there's a preference for a different host, lmk.
Author DanAlbert not on autobuild list. Waiting for curator authorization before starting CI build.
Can ignore the CI bot for now, I'll un-draft this once it's ready for review, but I have to push to test it.
@DanAlbert sorry this has got stale, what is the status of this effort, happy to re-help get this in anyway possible
I haven't had any time to work on it, unfortunately. None of the easy solutions worked. I think the last option (use maven central) isn't too much work but it's definitely all paged out of my brain :( If someone else wants to pick up the work I'd certainly be grateful, but if not I'll be able to get back to it eventually (though maybe not even this year tbh).