ndk-sys: Regenerate against NDK r23

[MarijnS95]

Android 12 reached platform stability today, including the first stable release of NDK r23.

---

Will add some of the new API surface to our safe wrappers in a separate PR. Perhaps it's a good idea to regenerate against identical (r22.1, beta 3) headers first but with newer bindgen, to make the diff more clear? Not that it matters for squash-merges unless we put that in a separate PR too, LMK.

At the same time we might want to start thinking about guarding symbols based on a user-selected version. We could for example have a feature version per NDK or per SDK/API version so that there is a clear up-front contract for the programmer that they can only call certain certain functions if at least some version feature is enabled; that's how the various gtk-rs bindings do it. They have the advantage of directly querying that exact version from pkg-build though, and running into linker errors immediately if things don't match.

[msiglreith]

I'm generally fine with the PR as is.

At the same time we might want to start thinking about guarding symbols based on a user-selected version. We could for example have a feature version per NDK or per SDK/API version so that there is a clear up-front contract for the programmer that they can only call certain certain functions if at least some version feature is enabled; that's how the various gtk-rs bindings do it. They have the advantage of directly querying that exact version from pkg-build though, and running into linker errors immediately if things don't match.

Is this feature guarding on a per iterm level or generating having different. seperately generated bindings per API version? Does Android NDK provide fine grained metadata to do this?

[MarijnS95]

Is this feature guarding on a per iterm level or generating having different. seperately generated bindings per API version? Does Android NDK provide fine grained metadata to do this?

I don't think we can apply this to bindgen code, and afaik the version constraints are only specified in documentation comments. The idea was to only apply this to the handwritten wrappers in ndk (not ndk-sys), but it's not really an idea since we already have this:

https://github.com/rust-windowing/android-ndk-rs/blob/a8c13855f4c651496e26c203fa22d9639b6cb77c/ndk/Cargo.toml#L23-L30

I don't exactly remember why I was suggesting this if we clearly already have it, maybe I was looking at functions that were not guarded by these yet. Will have to re-check, but I'm definitely using it on the new code.

[msiglreith]

I think this needs a CHANGELOG entry as well. Technically, some parts seem breaking API changes even though it may affect types no-one uses anyway (e.g ACameraMetadata_entry__bindgen_ty_1)

[MarijnS95]

I think this needs a CHANGELOG entry as well.

Added, thanks!

Technically, some parts seem breaking API changes even though it may affect types no-one uses anyway (e.g ACameraMetadata_entry__bindgen_ty_1)

Let's perform a minor release for this. Even though the NDK itself is backwards-compatible, these files generated with a newer bingen definitely are not. Might want to give it some time while we add the new APIs, though.