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.

[rnikander]

Just pinging to see if there is any update here. I've got Rust on iOS working by building a static app and using Xcode to create a super barebones "app" that just calls my static lib from main.m's main() function. Maybe I can do the same on Android and I don't need a cargo apk package tool? I don't know; I just starting to try to get my winit/wgpu code to run on Android. No clue yet how to do this.

[MarijnS95]

There's no update here as there's not much to do; cargo-apk just needs the deprecation warning removed, and a fresh release with the latest changes - but it's still available and usable daily. That's all orthogonal to the question of whether you need this tool at all: that completely depends on how and for what purposes you're building your app.

[anderspitman]

Just wanted to chime in and say cargo-apk is working great for me (for building a Slint app). Definitely appreciate your effort in keeping a simple option available.

[wuwbobo2021]

I have got familiar with building dex file with android-build in the android support library's build script and loading it with jni-min-helper at runtime.

However there is a serious limitation: custom Activity and Service classes must be defined in the android manifest, and currently cargo-apk doesn't support them.

I'm bothered by uglyoldbob/jni-min-helper#1 (comment) and #67 and realized that there could have been a simpler tool, requiring the user to write the Android manifest manually, so it would not need so many items added in the cargo configuration. Ideally, the cargo configuration may only specify the path of the Android manifest XML file, optional resource folder, and an optional Java source folder in which custom activities and services can be defined, compiled, and packaged into the APK file.

One may build such a new tool, probably named cargo-apkg, which don't have to be a fork of cargo-apk. It may be much simpler, giving more choices to the user. However, I don't have enough time to do it for now.

[MarijnS95]

Only 1% of cargo-apk is dedicated to declaring and updating an AndroidManifest.xml to let the users' Rust project work (almost) flawlessly out of the box as an Android app. Your suggestion @wuwbobo2021 to copy/fork all other 99% of this codebase is directly opposing the spirit of this issue: to consolidate and revive a simple tool for building "minimal" Android applications from pure Rust codebases.

I wouldn't be opposed to adding a feature that parses and merges into a user-defined AndroidManifest.xml, voiding the need to extend our serde Manifest struct definitions every time Google adds a new feature (and subsequently possibly deleting the metadata-based parsing except for a few library-related fields). Getting the merge strategy just right might be tricky though.

Would that help you not having to create yet another clone?

[wuwbobo2021]

Your suggestion @wuwbobo2021 to copy/fork all other 99% of this codebase is directly opposing the spirit of this issue: to consolidate and revive a simple tool for building "minimal" Android applications from pure Rust codebases.

Sorry, I don't mean "copying all other 99% of this codebase". Before discovering cargo-apk in the Slint documentation, I had tried building an apk (with a Rust cdylib library) manually by Android SDK tools like d8, aapt, zipalign and apksigner. Recently I found that there's already a clone: https://github.com/mzdk100/cargo-apk2, claiming to update more frequently; however it looks strange because its documentation has been changed to poorly-translated Chinese text; and then I found yet another crate: https://crates.io/crates/cargo-sdl-apk, which is much simpler and is dedicated for supporting libsdl based applications, but it inspired me to get the idea expressed in my last post.

I wouldn't be opposed to adding a feature that parses and merges into a user-defined AndroidManifest.xml, voiding the need to extend our serde Manifest struct definitions every time Google adds a new feature (and subsequently possibly deleting the metadata-based parsing except for a few library-related fields).

Thanks, of course it helps. However, I know that this cargo-apk crate hasn't been updated for almost 2 years. Did you have enough permission of merging any pull request?

[wuwbobo2021]

@MarijnS95 In #72 (comment), you've reminded me that "your work and implementation doesn't align with the future plans I have for cargo-apk.". Would you like to describe your future plan briefly in the current README.md or some issue so that others may be aware of keeping aligned with your goal before opening PRs?