Upgrade android-activity 0.6.0 → 0.6.1

[ErichDonGubler]

• Split out from chore(deps): update cargo.lock #9336.

• Blocked on Bump jni-sys to 0.4.0 and jni to 0.22 rust-mobile/ndk#433.

  This is being pushed forward by none other than the @MarijnS95, who we know from other contributions. ❤️

2026-03-30 EDIT: There are some complications noted by @rib below that mean I will likely not be driving this to completion. A new champion of upgrading this piece (or not) is welcome to appear!

[ErichDonGubler]

CC @MarijnS95.

[rib]

Btw, this probably doesnt need to be blocked on a new ndk release.

The ndk crate only really depends on the jni-sys crate (it just has an optional dependency on the jni crate for documentation).

We have a series of dependencies from winit 0.30 -> android-activity 0.6 -> ndk 0.9 -> jni-sys 0.3 that block us from updating the jni-sys dependency for the ndk 0.9 crate without breaking compatibility with winit 0.30

Since the ndk crate exposes the jni-sys 0.3 JNIEnv pointer type in its public API, it would be a semver breaking change to update it to jni-sys 0.4

In turn the android-activity crate re-exports the ndk 0.9 API and it would be a semver breaking change to update to an ndk 0.10 release.

Finally, winit 0.30 depends on android-activity 0.6 and so I'm currently quite reluctant to make any semver breaking changes in android-activity while winit 0.30 is the most widely used stable release.

Although it's not ideal that we currently end up pulling in jni-sys 0.3 and 0.4, this shouldn't be too bad in practice while these sys crates only contain a relatively small number of type definitions (no code). jni-sys types are only referenced in a few unsafe ndk APIs and could be easily cast from the corresponding jni-sys 0.4 pointer type.

For reference jni-sys 0.3.1 uses the semver trick to re-export compatible types like jobject from jni-sys 0.4 but sice the JNIEnv type definition changes from being a struct to a union in jni-sys 0.4, we can't use the semver trick here.

[ErichDonGubler]

With those complications in mind, I'm going to move this PR to draft, and invite somebody to champion its work (perhaps in their own PR). I want the PR open as a signal that there's some interest in doing it. However, that interest will ultimately need to manifest from the community in the form of additional work that I don't expect I'll be doing myself. Unfortunately, I can't justify doing this with Mozilla's current priorities. 😅

[rib]

My comment was only really intending to point out that this isnt blocked on a ndk release. There's hopefully no other complication here except to tell cargo-deny know that it's expected that there will be two versions of the jni-sys crate. So I guess your PR was pretty much done.

Pulling in two versions of the jni-sys crate should be reasonable, considering that these crates contain no code. Considering that jni-sys uses the semver trick then anyone depending on jni-sys 0.3 will also bring in jni-sys 0.4 anyway.