Rebuild repackaged Android SDK/NDK with API-34 support

[tosti007]

The minimal android SDK version required by the Google Play store to be able to publish an app has been bumped to version 34. However the current release of xbuild does not support this, being maxed at 33.

[jmetz]

As far as I can tell all that really needs to happen is for the sdk workflow to be re-run (possibly with minor updates, I'm not sure). It simply packages the sdk libs and puts them on the release assets page, and the ubuntu-latest runner image which is used (at least for the linux part of that workflow) contains SDK versions 33-35.

Then the hard-coded link in the xbuild source would have to be updated to pull the latest release assets for the SDK as before.

[jmetz]

PS As a temporary workaround, I copied my standalone android sdk platform and ndk libs into ~/.cache/x/, in the same layout as what's already there, and changed the version to 34 in the xbuild src. That got things working for me, in case you need a hacky workaround until this gets fixed.

Alternatively, the cargo-mobile2 tool by the tauri peeps uses whatever android system you have installed, so you're fairly free to do as you please with that, though their android support is in the process of being updated.

[SolidTux]

This also would require making a new release, which would be good anyway as the last one is over two years old by now.

[SolidTux]

I made a fork and a release in case anyone else needs this.

[MarijnS95]

I made a fork and a release in case anyone else needs this.

It might have been nicer to submit your changes as a PR to this repository, so that the original xbuild tool can be released with those improvements?

[SolidTux]

I do agree in general, but there aren't any changes in here apart from updating the URLs in the code to my fork. There are no necessary changes to the original tool except updating one string constant.

Basically, the only thing the original tool needs to do is to create another release.

Edit: This string constant being this one

[SolidTux]

The only reason I made a fork is that there I can trigger a release.

[MarijnS95]

@SolidTux unless I'm misunderstanding you, I don't think a public tool maintained under a shared-ownership GitHub organization should switch its download URL to the release of a singular person on GitHub who happened to perform an update. If anything we can very easily incorporate the required changes into our repository and perform an "official" release ourselves, and ultimately release a new xbuild that uses the new release.

That said, most of your changes are fixing indentation mistakes and it looks like not a lot needs to be done to support a newer NDK. I can push those myself and trigger the release instead, but having a PR with the required changes would have been appreciated.

[SolidTux]

I don't think a public tool maintained under a shared-ownership GitHub organization should switch its download URL to the release of a singular person on GitHub who happened to perform an update

@MarijnS95 That's not what I'm saying.

I needed to update the URLs, so I can use the release of my fork.
The public tool doesn't need to update any URLs, that's why I didn't submit a PR.
The change of URLs is just a temporary band-aid that is not required in the original one.

If anything we can very easily incorporate the required changes into our repository and perform an "official" release ourselves.

That's exactly what I meant. I just made the fork for myself in the meantime (and mentioned it here, so anyone can use it until there's an official release).

The indentation stuff was accidental from autoformatting. As I said, the only change needed in the original repository is updating the VERSION constant, which I can't do in a PR, as it depends on how the maintainers of the original tool decide to increment the version. So from the original tool, what's needed is:

1. decide on a new version (e.g. "0.2.1") and update the Cargo manifests
2. update the string constant accordingly
3. make a new release

Number 1. and 3. can't happen in a PR, so all of this sadly has to be done by the maintainer.

[MarijnS95]

@SolidTux you seem to have also had to change a lib64 -> lib, that's the kind of research+change I was hoping to see in a PR.

You are right that this system is dumbfoundedly built on a release trigger: we first have to point xbuild to a new, nonexistent "SDK release" and publish that on GitHub, before the CI starts to build the actual repackaged SDKs and allowing us to test it.

Perhaps we can preempt that by creating a so-called "pre-release" so that not every user subscribed to this repo is triggered by a new, possibly-dysfunctional and untested xbuild release. At least it doesn't seem to publish it to crates.io yet, which is where the majority of users might read it.

Note

This might simply be a "workaround" to publish persistent blobs to GitHub. I haven't seen an easy way to create artifacts in a CI action (i.e. a manual trigger) and attach them to a release when "drafting a release".

---

A new release might still be a some time out. I haven't been able to work on Rust for the better part of 6 months and my co-maintainer equally didn't seem to have spent much time here. I prefer to get at least most of the low-hanging fruit (open PRs and issues) merged or fixed before pushing out a new release.

[SolidTux]

Oh, my bad, I totally forgot about that change because I played around with xbuild afterwards. Sorry about that.

I will prepare a PR then (also without all the unnecessary indentation changes)! Should I update the version to something like 0.2.1-alpha? That would also signify to cargo that it's not a full release.

Maybe the SDKs should not be tied to xbuild. What do you think of splitting this action into a different repository (xbuild-sdks) and have the xbuild code point to that? Then one could

• make a release in the SDK repo
• update the version constant in the xbuild code
• test xbuild with the new SDKs
• maybe make a xbuild release

[MarijnS95]

Honestly, I don't want to be playing too much with (the layout of) this repository/tool. I've already written about this on the cargo-apk repository after "soft-deprecating" it, that the original maintainer has "pretty much" left xbuild after pushing it out into the world with a promise that it would supersede cargo-apk.

Most of my (free!) time so far has only been spent on fixing issues in xbuild that have been addressed long ago in cargo-apk, or weren't even a problem there because it was a smaller/simpler project with higher code-quality standards.

As it stands neither cargo-apk nor xbuild comes out a clear winner, both have their own unique advantages and features. In an "ideal" world, the Rust ecosystem would have stuck its heads together to create and maintain/improve one coherent tool but it seems individuals and organizations in the wider Rust(+Android?) ecosystem are more than happy to fork and own rather than share and collaborate.

Given that xbuild has never seen a significant and healthy influx of external contributions - which would be necessary to solve outstanding issues and surpass cargo-apk at some distant point in the future, I don't see how anyone can confidently migrate to xbuild when fully deprecating cargo-apk. End result: my time and efforts are split maintaining two "duplicate" tools 😠

---

And to actually address your points about SDK/NDK repackaging: at some point I've wanted xbuild to use the NDK as-is, no repackaging needed. It's "nice" that we can use the host cross-compiler on developed OSes like Linux and MacOS, but when we're in the stone age on Windows, using the cross-compiler directly from Google's latest NDK release is a lot less problematic than figuring out how to correctly install+configure LLVM on Windows (i.e. a simple winget install llvm misses PATH).

[MarijnS95]

I've started testing at https://github.com/rust-mobile/xbuild/releases/tag/v0.2.1-alpha. Probably won't make a crates.io release until finishing existing open PRs, as alluded to before.

[SolidTux]

I'm sorry, I wasn't aware of this full situation ☹️

Thank you so much for still taking care of stuff around here! ❤️

I started using xbuild as it was, like you said, proposed as a replacement and because I need AAB support.

[SolidTux]

I'm splitting up the other changes I did and preparing PRs. Please tell if I'm overstepping or demanding too much somewhere, this sounds like a tricky social situation to manoeuvre, and I'm not intending to cause more problems, but rather be helpful.

[MarijnS95]

Splitting out changes into separate PRs is fine as long as they don't overlap with PRs that are already open.

There's nothing tricky here on the social side regarding code contributions, the above is my "excuse" or reason for not feeling happy when working on xbuild as a developer nor maintainer. If you ever see a lack of activity here, it's likely because I'm spending a more joyful time with cargo-apk.