Update bindgen to v0.69.4 to fix building on clang18

[shadow3aaa]

No description provided.

[rsglobal]

Hello folks,

I noticed this change wasn't merged, but it is necessary for this project to function on Ubuntu 24.04.

Also this diff code is required, otherwise libbinder_ndk isn't built.

--- a/binder_ndk_sys/build.rs
+++ b/binder_ndk_sys/build.rs
@@ -17,6 +17,8 @@ rust-version = "1.67"
 
 [lib]
 crate-type = ["cdylib"]
+
+[workspace]
 "#;
 
 fn build_stub() -> Result<()> {

So, is this project still alive? Do you need a help maintaining it? I would be happy to participate.

[MarijnS95]

Traverse-Research@41045c6 - this commit also fails build.rs when nested cargo build fails, instead of silently continuing :).
I can PR that instead if you're interested.

@rsglobal just notice that Google engineers have published their upstream codebase to crates.io: rust-mobile/ndk#490 (comment)

That is the same codebase that this project was originally copied from (and furthermore never updated/maintained), but this was never mentioned in the README.

[rsglobal]

Hi @MarijnS95 , It is nice to see you here.

I looked at the links you sent me and noticed the description Bindgen bindings to the Android binder, restricted to the NDK. This probably means some symbols necessary to run vendor services (HALs) are not visible/accessible.

While this project has a different approach, which allows runtime linking with /vendor/lib{64}/libbinder_ndk.so

And it looks like maintainers abandoned it, which is sad.

[MarijnS95]

@rsglobal nice to see you here too, seems our Android interests stay aligned and extend to Rust too.

Yes, those bindings are what the libbinder_ndk stub is for: https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/ndk/libbinder_ndk.map.txt;l=95-97;drc=0555fbf9ecde50d339ca2e8788ec0539d4397701

The symbols are there but cannot be dynamically linked at build-time, but they're found at runtime.

It's unfortunate to have two crates with ~exactly the same Rust code just to be able to change what and how it's linked. At runtime you might get away with dlopen() though? It's been a while since I experimented with connecting to services. Makes no sense that these symbols are hidden, since services can be connected to in Java as well.