discussion for moving the rust on android ecosystem forward

[dvc94ch]

so currently a lot of the core components are spread out among various maintainers. it's hit @MarijnS95 the hardest since he is still maintaining legacy code which unless a company explicitly requires and pays for this doesn't make any sense what so ever. my suggestion would be this:

• create a new org
• move rust-windowing/android-ndk-rs, rib/android-activity, cloudpeers/xbuild into new org
• rm -rf ndk-glue ndk-macro ndk-build cargo-apk

to move in this direction I think that @rib @MarijnS95 @msiglreith would need to agree that this is the way forward. I'm maintaining xbuild as part of my day job, but it's unlikely I'll be able to contribute much to android-ndk-rs and android-activity.

[rib]

Thanks for starting this discussion.

I had recently been wondering if we could modularize the android-ndk-rs repo via git filter-branch and then as suggested here it could then make sense to put those repos under a new org.

That way we could perhaps "archive" the monolithic repo. In the case of ndk-glue / ndk-macros I suppose it could be a separate question whether to split those out and then immediately archive or else could simply end up archived as part of the monolithic repo.

For cargo apk and ndk-build maybe that's more a question for you and @MarijnS95 than me. Splitting them out as separate repos seems like it would make sense to me though.

[rib]

since it sounded like there was some agreement on the idea (from the other threads too that lead us to this issue) I think for starters I'll take a stab at filter branching android-ndk-rs and put those repos up here https://github.com/Android-Rust if that vaguely works and can invite you all as co-owners if that looks like a viable direction

[dvc94ch]

As I said I'm mostly interested in maintaining xbuild as the defacto tool for building and deploying cross platform rust applications. The main blocker so far was no real rust gui framework. But for now I think dioxus is good enough and in a few years glacier/piet-gpu/xilem will probably be the way to go. I can continue maintaining it in the cloudpeers repo for now, as it seems that @MarijnS95 and @rib only care about android at the moment. Yeah there is a lot of experimental code in xbuild, but the android and iOS parts are getting thoroughly tested and used and improved.

[rib]

I wonder if an organisation that was framed more like "Mobile Rust" might be more practical than one that is android specific? considering how common it would be to want to make crates that are useful cross-platform?

[rib]

Okey for reference it was pretty straightforward to filter out each android-ndk-rs project, and initial repos can be seen here: https://github.com/Android-Rust

This is how I filtered them all:

git-filter-repo

(nicer than using git filter-branch)

git clone https://github.com/newren/git-filter-repo

ndk-sys

(takes into account that the code originally moved from android-ndk-sys/)

git clone https://github.com/rust-windowing/android-ndk-rs.git ndk-sys
cd ndk-sys
py ../git-filter-repo/git-filter-repo --subdirectory-filter ndk-sys --subdirectory-filter android-ndk-sys

ndk

(takes into account that the code originally moved from android-ndk/)

git clone https://github.com/rust-windowing/android-ndk-rs.git ndk
cd ndk
py ../git-filter-repo/git-filter-repo --subdirectory-filter ndk --subdirectory-filter android-ndk

cargo apk

git clone https://github.com/rust-windowing/android-ndk-rs.git cargo-apk
cd cargo-apk
py ../git-filter-repo/git-filter-repo --subdirectory-filter cargo-apk

ndk-build

git clone https://github.com/rust-windowing/android-ndk-rs.git ndk-build
cd ndk-build
py ../git-filter-repo/git-filter-repo --subdirectory-filter ndk-build

ndk-glue

git clone https://github.com/rust-windowing/android-ndk-rs.git ndk-glue
cd ndk-glue
py ../git-filter-repo/git-filter-repo --subdirectory-filter ndk-glue

ndk-macro

git clone https://github.com/rust-windowing/android-ndk-rs.git ndk-macro
cd ndk-macro
py ../git-filter-repo/git-filter-repo --subdirectory-filter ndk-macro

ndk-context

git clone https://github.com/rust-windowing/android-ndk-rs.git ndk-context
cd ndk-context
py ../git-filter-repo/git-filter-repo --subdirectory-filter ndk-context

[MarijnS95]

@rib heh I intended to name it Rust-Android to put emphasis on Rust :)

I'm fine to start and drop ndk-glue and ndk-macros now that winit migrated to @rib's crate. Not sure if we need to publish a new crate with a big DEPRECATED marker at the top and/or #[deprecated] annotations the moment winit 0.28 releases, I'll leave that to @rib. Again, I think most ndk-glue users are using it in conjunction with winit, and having active markers here might help otherwise-unaware users (those that don't read changelogs or happen to be copypasting an older example) discover that winit changed crates entirely.

---

More importantly for me however: we should nuke ndk-context. We discussed many times before that statics are error-prone by design and extermely annoying to use. At the same time they are (currently) representing an Activity which some crates may have come to rely on, blocking support for multiple Activitys unless we start storing getApplicationContext(). I originally suggested that the "main" function should receive an object representing its Activity and passing that on to all crates needing it, solving all those problems. This is effectively what @rib ended up implementing in his android-activity crate, together with winits AndroidApp::with_android_app(). I suggest we force all crates to use a similar flow (perhaps with ndk-context exclusively hosting struct AndroidContext for conciseness), as that would have also helped us solve the following app_dirs2 issues more cleanly:

#126
app-dirs-rs/app_dirs2#33
tectonic-typesetting/tectonic#926

[rib]

okey, I've sent owner invites for that org, and I guess we can decide whether that seems like the right direction vs e.g. leaving the repos under the rust-windowing org or not splitting these out etc

[rib]

@rib heh I intended to name it Rust-Android to put emphasis on Rust :)

Yeah we can rename. I was also pondering the more general "Mobile Rust" or "Rust Mobile".

[rib]

(we can also just delete crates like ndk-glue / ndk-macro if we figure it's fine that they are archived in the original repo)

[dvc94ch]

Do other people feel this way about ndk-context? I don't think the webbrowser crate would have been possible without it [0]. I consider it a major success story.

• [0] https://github.com/amodm/webbrowser-rs/blob/main/src/android.rs

[dvc94ch]

in my opinion you should drop ndk-glue and ndk-macro. the idea is coming up with a plan for the future not maintaining backwards compatibility. anyone using rust on mobile must understand that it's experimental.

[dvc94ch]

but yeah extending ndk-context to multiple activities means that any activity that wants to use rust needs to update ndk-context onCreate. currently we panic if we overwrite an existing ptr. I now think that's a mistake.

[MarijnS95]

(I cannot give detailed responses now, expect more detail in an hour)

@dvc94ch your link doesn't render correctly.

@rib I'd still prefer to bundle relevant repos together, if possible. Ndk+ndk-sys, and cargo-apk+ndk-build. Ndk-glue and ndk-macros can remain here to get their deprecation marks and be ultimately removed.

Not sure how to deal with open PRs though; merge them here and bring the result to the new org?

For starters we can also transfer the entire repo to the new org and leave the split for some time later.