Revive cargo-apk!

[thequver]

Can anyone continue development of this project? The advertised xbuild is unintuitive to use, lacks documentation and seems to be dead from the start (the last release was in 2022). Cargo apk is way better for simple building android apps without extra bloat functionality like store publish.

[MarijnS95]

This is something I've been wanting to do for a long time - and why this repository was never truly archived and PRs were still merged or received feedback long after its deprecation was announced.

---

xbuild promised a lot: reduced dependencies by having most tools natively implemented in Rust, utilizing cross-compiling functionality of a single host-installed clang toolchain (easy to do on most Linux distros, but hard to set up correctly on Windows...), and packaging applications for publishing to various platforms and their stores. The latter - which you strangely call bloat - is the most important: without this, all Rust Android apps are mere examples, tests, or prototypes. Isn't our goal to eventually ship Rust-based Android applications to end-users? And if not supported by a main tool like xbuild or cargo-apk, why use different tools, setups and configurations for that?

Looking at the rest of the Rust Android ecosystem, and not wanting to fall for the same mistake of providing the community yet another half-maintained hard fork and causing the usual "but which of these 10 tools should I pick for my purpose" confusion, I set an ultimatum to either continue on cargo-apk or deprecate it and continue solely on xbuild. On paper, when merely comparing features, xbuild appeared to be a no-brainer.

But as you pointed out, a few years down the line this didn't turn out to become reality. xbuild lacked adoption and active leadership/maintenance from the start. A bunch of cargo-apk features were still unimplemented and I personally found the whole codebase to be a lot less structured and maintainable than where I had brought cargo-apk and ndk-build (the latter would have been an excellent crate to offload and share common Android code between the two tools). Specifically, I ran into a lot of "older" cargo-apk code snippets spread around xbuild, typically resulting in "didn't I fix this bug in this snippet in cargo-apk a month or two ago" realization.

So here we are right now. cargo-apk is still my go-to driver for maintaining various Android projects including the ndk, winit, glutin and softbuffer, while xbuild every so often sees contributions to make publishing possible, as well as occasional bugfixes and other small features. Having to split my attention between the two is crates is quite frankly frustrating, if not impossible on an incredibly tight time budget. At least cargo-apk "just works" and didn't need any maintenance (besides missing features).

There's one specific design and feature I'd like to add to both build tools. Once that's done, I think I will remove the deprecation notice here and publish a new version, including all the fixes that were merged but never made it to a release.

Meanwhile, issues and PRs are open to receive contributions. Hopefully revival entices more non-code contributions in particular, such as assistance with triaging help requests and reviewing pull requests, which is always the main bottleneck (and source of frustration).

---

And one final note on publishing and "bloat": this is not xbuilds fault per se. Google and Android keep changing and raising the requirements and complexity of publishing applications. The AAB format is so involved, that xbuild currently defers to generating a gradle build (like cargo-mobile and forks/friends!) to make this happen rather than packaging it (and the various files it needs) in-house.

[thequver]

@MarijnS95, thanks for the detailed explanation about why things are the way they are, I personally don't like the store publish functionality exactly because of

Google and Android keep changing and raising the requirements and complexity of publishing applications

This is just a maintenance burden and will be an endless race with a corporation making changes for the sake of changes, wasting time of maintainers. Especially if they suddenly restrict something like publishing apps using only their tools.
Maybe less work only if not taking Play Store into account. Cargo-apk is great because it focuses only on building while the store publishing is separate and independent from it. But this is only my opinion.
Feel free to close the issue if it is not needed

[MarijnS95]

I still think it's worth having something that takes into account the packaging for publishing, but cargo-apk can do that for "alternative" stores and simple shareable files/download-links where (correctly signed) APKs are enough.

I think we can close this as "cargo-apk was never truly deprecated" after removing the deprecation notice from the README and publishing a new release.