we are always happy to help here in anyway with Android, unfortunately I don't personally do much Android development as I use to, so my knowledge of the latest best practices for build flow/processes are low so having your help do the work would be awesome and I can help enable and repo settings needed

SG, I'll send a PR soonish. It may be a few weeks (US holidays coming up next week).

Uploaded #8303. As I mention in the PR, GHR doesn't work as well as I'd hoped (authentication is required even to read public packages), so the simplest option isn't actually very good.

The last thing I was going to try (publish to Maven Central) requires that the packages be signed, and I know just enough to know that I don't know enough to set up a secure signing workflow in GHA (in particular, I don't know how to protect keys from exposure in malicious PRs), so unfortunately I don't think I'm going to make any more progress here.

If someone else feels confident setting up signing, #8303 actually only needs minor tweaks to do that, as far as I can tell. The following guides explain how:

• https://central.sonatype.org/publish/publish-manual/
• https://central.sonatype.org/publish/requirements/#provide-files-checksums
• https://central.sonatype.org/publish/publish-guide/
• https://maven.apache.org/repository/guide-central-repository-upload.html

(in particular, I don't know how to protect keys from exposure in malicious PRs)

so I am pretty sure that this can be done with Github Secrets (which I can access/setup for this repo), not it does say

Anyone with collaborator access to this repository can use these secrets and variables for actions. They are not passed to workflows that are triggered by a pull request from a fork.

so no malicious 3rd-party PR can use them, from there, we can setup something like https://theoverengineered.blog/posts/publishing-my-first-artifact-to-maven-central-using-github-actions

and just like we currently have

  androidUpload:
      needs: android
      if: github.ref == 'refs/heads/main'

we can have it as a rolling release per commit (or if needed maybe once a week, like we do with our current tagging weekly snapshots

They are not passed to workflows that are triggered by a pull request from a fork.

Oh, I had missed this bit. That was the part I was worried about. Thanks!

Okay, in that case I think I know how to go about this. I should have time to look at this again in the next few weeks.

Not a bug, so neither template seems to apply.

Using the validation layers on Android requires jumping through a few hoops: https://developer.android.com/ndk/guides/graphics/validation-layer

This repo does already publish prebuilt libraries (thank you, that does simplify their use a lot), but just as a bare zip/tarball of libraries (and chrome flags the download as malware). Users have to vendor these libraries into their repo and remember to keep them up to date.

If they were instead an AAR and published to https://docs.github.com/en/packages (free for public repos), those instructions reduce down to just defining the repo and declaring the dependency as described in https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-gradle-registry#using-a-published-package. Android Studio would also highlight the dependency as out of date whenever a new version was available (I think so, anyway, maybe it only does that for specific libraries).

Is that something the maintainers here would be open to? Looking at https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/main/scripts/android.py and https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/main/.github/workflows/sdk_android_build.yml, it's not a whole lot of work to produce the AAR, and I can volunteer to do that part, but an owner here would need to enable the github package repo.