Android google play release workflow failing due to outdated target SDK

[Rezan7CC]

As can be read here from August 31 the android dev console started requiring a target SDK of API level 34 or higher:
https://developer.android.com/google/play/requirements/target-sdk

As a result the release-android-google-play.yaml workflow has been failing for me complaining about a low target sdk level.

xbuild (both the original and your fork) have a hard-coded API level of 33 in xbuild/src/config.rs. However I found a workaround which is setting each of these in the manifest.yaml:

  manifest:
    compile_sdk_version: 34
    platform_build_version_code: 34
    compile_sdk_version_codename: 14
    platform_build_version_name: 14
    sdk:
      target_sdk_version: 34
      min_sdk_version: 21

However then we run into the next xbuild issue which is Error: ndk doesn't support sdk version 34.

It took me quite a bit of time to try to investigate how the ndk / dependencies for xbuild can be upgraded. The latest state of my investigation is that I believe the dependencies are updated for the xbuild repository by the sdk.yaml action when creating a new release in xbuild.
I tried creating a fork from your xbuild fork to give running the action a try by creating a new release but this is when I'm running into the next error:

Run cp -r $CLANG/lib/linux/aarch64/* Android.ndk/usr/lib/aarch64-linux-android/
  cp -r $CLANG/lib/linux/aarch64/* Android.ndk/usr/lib/aarch64-linux-android/
  shell: /usr/bin/bash -e {0}
  env:
    TOOLCHAIN: /usr/local/lib/android/sdk/ndk/[2](https://github.com/Rezan7CC/xbuild/actions/runs/11021585909/job/30608981092#step:9:2)7.1.12297006/toolchains/llvm/prebuilt/linux-x86_64
    CLANG_VERSION: 
    CLANG: /usr/local/lib/android/sdk/ndk/27.1.12297006/toolchains/llvm/prebuilt/linux-x86_6[4](https://github.com/Rezan7CC/xbuild/actions/runs/11021585909/job/30608981092#step:9:4)/lib64/clang/
cp: cannot stat '/usr/local/lib/android/sdk/ndk/27.1.12297006/toolchains/llvm/prebuilt/linux-x8[6](https://github.com/Rezan7CC/xbuild/actions/runs/11021585909/job/30608981092#step:9:6)_64/lib64/clang//lib/linux/aarch64/*': No such file or directory
Error: Process completed with exit code 1.

And this is the current point where I'm stuck now to get the playstore release action to work.

[Rezan7CC]

I tried quite a bit of different things by now including changes in the game template workflow and the xbuild code-base itself (like in the hard-coded app gradle build config) but I'm encountering the same error after upgrading sdk version still.
Screenshot attached in case it helps.

In this xbuild fork you can see some of the things I tried btw. But maybe I missed something super obvious so I will pause this investigation from my side now.
https://github.com/Rezan7CC/xbuild

[jmetz]

Suggest migrating this issue to https://github.com/NiklasEi/xbuild

[Rezan7CC]

Yeah I would but that repository doesn't have issues enabled. And it affects this repository directly anyway. https://github.com/NiklasEi/xbuild is just a fork with patches to serve this one here.

[jmetz]

Ah right - so I guess submit the issue to the parent repo - https://github.com/rust-mobile/xbuild

[Rezan7CC]

Yeah maybe I will open it up there too. It looks a little bit abandoned/completed though which is why the fork for this game template here was necessary I think.
I had a quick chat with @NiklasEi on discord who wanted to have a look at what's going on. Let's see what comes out of that when he gets to it and then we will see if changes should go into fork or PRd into the original repro.

[jmetz]

Interesting hacky development on my end; I simply updated xbuild/src/config.rs to use SDK 34, and then copied over folders from my standalone android build tools installs, e.g.

cp -rp ~/android/ndk/26.2.11394342/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/34 ~/.cache/x/Android.ndk/usr/lib/aarch64-linux-android/

and that seems to have worked!

The issue is just that xbuild uses a precompiled version of these folders from ~2 years ago, which are cached to ~/.cache/x/Android.ndk/ (they're pulled from the assets page here: https://github.com/rust-mobile/xbuild/releases for release v0.1.0+3 as far as I can tell).

It seems that simply adding more folders in there for newer SDK versions seems to work at the moment... though very hacky solution. Might just be enough to get Play Store releases out for now though.

[NiklasEi]

I think my path forward here, would be to migrate to use the new Bevy mobile setup with GameActivity. I haven't tried it out, but it seems to use cargo-ndk and gradle directly.

[jmetz]

Just in case it slipped through the net - it could also be worth keeping an eye on cargo-mobile2 ( https://github.com/tauri-apps/cargo-mobile2 ) which is maintained by the tauri peeps and so might be able to sustain more development. I've tried it in the past but the bevy example and template still had issues.

[Rezan7CC]

@jmetz Interesting hack.. I have a xbuild fork where I'm pretty close to the xbuild workflows (including the release one) running through successfully. But something seems to be missing still.

Where/how exactly do you execute the command? For the repository somehow or as part of an action?

[jmetz]

Ah this is just on my local machine, not as part of the workflow. I'm not totally familiar with the layout and setup included in the workflow images.

But essentially the cp command takes folders from under the standalone android ndk install folders, and puts them in the xbuild ndk cache folder. Symlinks could work too, I didn't try that.

Essentially though, xbuild itself is mainly fine, just needs bumping the API from 33 to 34. The issue is just then giving it access to the correct ndk folders, as the xbuild peeps didn't update their built versions in a while.

[Rezan7CC]

Yeah makes sense. That's why for the workflow setup I tried to repair the xbuild build pipeline so that new builds can be created.

There were a bunch of extra issues there like java versions etc (and some issues remaining).

But let's see if I can get it to update the build files correctly. If not, I might see if I can manually upload it.

And in the long-term it's nice that we're looking at approaches that are not abandoned (and rely on a bunch of hard-coded stuff) of course :P

[jmetz]

My own preference would be to remove java-tools from the loop entirely, and I'm currently working to reproduce the workflow mentioned by https://www.reddit.com/user/coderstephen/ here https://www.reddit.com/r/rust/comments/17dr46y/comment/k60o3is/.

Supposedly, it's essentially just

• cargo ndk to build .so s for the architectures you want to support
• aapt2 to prepare the files to include in your APK and then zip them into an APK file
• zipalign to align the archive structure
• apksigner to sign with your key

So similar to what @NiklasEi suggested above, but replacing gradle with the standard CLI android build tools.

[jmetz]

@Rezan7CC + @NiklasEi - thought you'd both be interested in my cargo-mobile2 version of this game template. That said, it's heavily stripped down (single lib.rs) and I replaced the ActionsPlugin with Events: https://github.com/jmetz/cargo-mobile2-bevy-example

[jmetz]

Also I created a "minimal approach", though I haven't tried this yet with assets etc, here: https://github.com/jmetz/minimal-rust-android-workflow-without-java

[NiklasEi]

FYI: we need to support building AABs next to APKs in all workflows. The Play Store only allows publishing AABs.