Error on Ubuntu-24.04

[ViliusSutkus89]

Hello,

First of all, emulators on Linux images are pretty cool. Having said that, I've noticed an issue - it doesn't work on Ubuntu-24.04 (beta). We need to use Ubuntu-22.04 (latest).

Just wanted to file this as an issue, because it took me some time to figure out why my CI is red.

Here's a sample run with Ubuntu-22.04 and Ubuntu-24.04 - https://github.com/ViliusSutkus89/android-emulator-runner-ubuntu-24.04/actions/runs/9594927854

Ubuntu-24.04 errors out:

2024-06-20T09:23:17.9214746Z [command]/usr/bin/sh -c \echo no | avdmanager create avd --force -n test --abi 'default/x86' --package 'system-images;android-29;default;x86'
2024-06-20T09:23:18.6029378Z Loading local repository...                                                     
2024-06-20T09:23:18.6035642Z [=========                              ] 25% Loading local repository...       
2024-06-20T09:23:18.6036583Z [=========                              ] 25% Fetch remote repository...        
2024-06-20T09:23:18.6045879Z [=======================================] 100% Fetch remote repository...       
2024-06-20T09:23:18.7430306Z Do you wish to create a custom hardware profile? [no] [command]/usr/bin/sh -c \printf 'hw.cpu.ncore=2
2024-06-20T09:23:18.7431804Z ' >> /home/runner/.android/avd/test.avd/config.ini
2024-06-20T09:23:18.7449816Z /usr/bin/sh: 1: cannot create /home/runner/.android/avd/test.avd/config.ini: Directory nonexistent
2024-06-20T09:23:18.7456105Z ##[endgroup]
2024-06-20T09:23:18.7457248Z ##[group]Terminate Emulator

Workflow file:

name: CI
on: push
jobs:
  build:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os:
          - ubuntu-22.04
          - ubuntu-24.04
    steps:
      - name: Enable KVM group perms
        run: |
          echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' | sudo tee /etc/udev/rules.d/99-kvm4all.rules
          sudo udevadm control --reload-rules
          sudo udevadm trigger --name-match=kvm

      - uses: reactivecircus/android-emulator-runner@v2
        with:
          api-level: 29
          script: /bin/true

[hfhbd]

Is there any workaround?

[torokati44]

I also ran into this.
Seems like #327 could fix this...?

[mikehardy]

At its heart it is an environment variable problem. With some console.logs from a forked version of this repo you can see that the AVD-related pathing is messed up for some reason:

https://github.com/ankidroid/Anki-Android-Backend/actions/runs/11281139144/job/31383662978#step:4:90

  /usr/bin/sh -c \echo no | avdmanager create avd --force -n test --abi 'default/x86_64' --package 'system-images;android-23;default;x86_64' --device 'Nexus 6'
  Loading local repository...                                                     
  [=========                              ] 25% Loading local repository...       
  [=========                              ] 25% Fetch remote repository...        
  [=======================================] 100% Fetch remote repository...       
  /usr/bin/sh -c avdmanager list avd
  Available Android Virtual Devices:
      Name: test
    Device: Nexus 6 (Google)
      Path: /home/runner/.config/.android/avd/test.avd

What is that ??

  Path: /home/runner/.config/.android/avd/test.avd

...there is an extra .config path segment in there that shouldn't be.

I'll post a PR that patches it up here but I think you could add this to an env block in your workflow and it might fix things:

ANDROID_USER_HOME: /home/runner/.android
ANDROID_EMULATOR_HOME: /home/runner/.android
ANDROID_AVD_HOME: /home/runner/.android/avd

(from here https://developer.android.com/tools/variables#envar)

When I set those in my forked + fixed version of the action things started working https://github.com/ankidroid/Anki-Android-Backend/actions/runs/11281139144/job/31384483722

[ychescale9]

@mikehardy thanks for the investigation. From my testing it seems like it's due to the following directory no longer ${process.env.HOME}/.android/avd being available with the new 24.04 image.

After creating the directory the tests started working: https://github.com/ReactiveCircus/android-emulator-runner/actions/runs/11284138596/job/31384839511

[mikehardy]

that's strange @ychescale9 because I didn't have to create the directory to get it working, I just had to define the env vars 😆 - I just about have the commits lined up and a PR for it - obviously if you've got it fixed then that's fine to close, but a published vs of the fork with just env vars defined did work.

[mikehardy]

There you go @ychescale9 - I just posted up a batch of PRs that worked together to get things working well on my end - hopefully they are useful? I've been using this action forever and I really appreciate the maintenance, just offering the PRs in case they're useful. Cheers

[ychescale9]

This hopefully has been fixed in the latest commit. Would anyone be able to test your workflows on ubuntu-24.04 with reactivecircus/android-emulator-runner@8c07710601c4b0e50139034f86054e4b09abf601?

[mikehardy]

@ychescale9 this is queued and will run against that SHA once a runner is assigned: https://github.com/ankidroid/Anki-Android-Backend/actions/runs/11284602925/job/31386054640

(the build itself will have instrumented test failures inside the emulator but the emulator should start up fine)

[mikehardy]

Okay, so that test failed - the problem with that commit is a typical actions developer problem I found when I forked this repo and tried to fix it myself:

@actions/core not found - it's because the patch is maybe good, but you have to have the node_modules directory committed for the action to work. You have that on the release/v2 branch but not on the main branch (so people won't run off main, which is probably a good thing)

I was only able to test my changes when I worked off the release/v2 branch on my fork for that reason

I believe your changes will work, but not until merged on to release/v2 or unless you make a branch where the node_modules that results from npm i --omit=dev is committed and pushed

Separately, I was able to get a raw emulator working with just the env vars as mentioned above, in a repo where I don't use this action, the diff that fixed that workflow was just this in the env: block at top of workflow job:

+      ANDROID_USER_HOME: /home/runner/.android
+      ANDROID_EMULATOR_HOME: /home/runner/.android
+      ANDROID_AVD_HOME: /home/runner/.android/avd

https://github.com/react-native-device-info/react-native-device-info/pull/1667/files

[ychescale9]

Thanks @mikehardy. I also agree that #405 might be a better fix as IIRC setting that envar explicitly was to better support self hosted runners.

I'll try to verify that quickly.

[ychescale9]

So looks like it's all working now even without the changes in #409 😅 Maybe something was fixed upstream? It's due to avd caching in the test workflow.

[mikehardy]

Perhaps - but the mingling of ANDROID_AVD_HOME with XDG_CONFIG_HOME is something that shouldn't be left to chance I think, and not setting the other variables (ANDROID_USER_HOME / ANDROID_EMULATOR_HOME) is also leaving things to chance

Plus, the command line tools issue where there is a simple directory check to trigger install vs either purging+forcing-current (you're style) or checking-version+installing-if-needed (my PR) is a thing

And finally, the chown thing will make this action fragile to future changes as they may also purge out parts of android toolchain in ubuntu-26 and the chown will fail as it tries to operate on non-existent files - so it should either be removed (as you did) or done safely (as I proposed)

So - still some real issues here, but the action may be able to continue functioning without change now, maybe with some env vars defined, maybe not even that...

[ychescale9]

The fix is available in the latest release: https://github.com/ReactiveCircus/android-emulator-runner/releases/tag/v2.33.0

[mikehardy]

@ychescale9 champion! Thanks again in general for this action, as mentioned way way above, I use it in lots of repos and I really appreciate it. Now that the emergency compatibility for ubuntu-24 appears to be handled, do you have any interest in rebased / updated PRs for the things I saw?

• command line tools is not verified to be the version we expect (currently checks for directory existence vs actual version)
• the ANDROID_AVD_HOME var is clobber-set instead of checking for existence, and ANDROID_USER_HOME / ANDROID_EMULATOR_HOME (documented upstream) are not set but could be (and those would have fixed this issue as well actually!)

I'd be happy to clean up my PRs for those and resubmit but I also don't want to waste your time if you are tired of the whole thing and want to ignore it at least for now :-). Cheers

[ychescale9]

Thanks @mikehardy

command line tools is not verified to be the version we expect (currently checks for directory existence vs actual version)

I think in the past the cmdline-tools wasn't pre-installed in the runners so I wanted to always install and use the tools from the cmdline tools (instead of the deprecated ones) when running the action.

Now that the cmdline-tools is pre-installed I'm not sure it's worth always checking the version, deleting it, downloading and installing the latest at the start of every action run.

If we do want to support overriding the default version installed perhaps providing an action input option makes more sense. Though I'm leaning towards just removing that step from our end.

BTW checking the existence of the path was to support #74

Re. the ANDROID_AVD_HOME I did some experiment and it seemed like the env var is always undefined so I didn't look into setting it dynamically.

Anyway I'm happy to continue the conversation in separate issues / github discussions.

[mikehardy]

Re. the ANDROID_AVD_HOME I did some experiment and it seemed like the env var is always undefined so I didn't look into setting it dynamically.

don't forget the self-hosted runner case :-)

I think in the past the cmdline-tools wasn't pre-installed in the runners so I wanted to always install and use the tools from the cmdline tools (instead of the deprecated ones) when running the action.

They go stale, for instance current installed version is version 12, but 16 is out. v12 sdkmanager cannot handle XML v4 while v16 sdkmanager can, so updating can reduce log spam

I'll log issues I guess ? The PRs already exist I guess I'll just make my case there then either close them or not