Job times out due to package id being in inconsistent location

[XiangRongLin]

My CI job was cancelled after 6h because the android emulator runner action got stuck

Logs
https://github.com/TeamNewPipe/NewPipe/pull/6673/checks?check_run_id=3080440435

logs.zip

 /usr/bin/unzip -o -q emulator.zip -d /Users/runner/Library/Android/sdk
Installing system images.
/bin/sh -c \sdkmanager --install 'system-images;android-29;default;x86' > /dev/null
Warning: Observed package id 'ndk;21.4.7075529' in inconsistent location '/Users/runner/Library/Android/sdk/ndk-bundle' (Expected '/Users/runner/Library/Android/sdk/ndk/21.4.7075529')
Warning: Observed package id 'ndk;21.4.7075529' in inconsistent location '/Users/runner/Library/Android/sdk/ndk-bundle' (Expected '/Users/runner/Library/Android/sdk/ndk/21.4.7075529')
Error: The operation was canceled.

I'm running the action on API level 21 and 29, the 21 one succeeds, the 29 one fails. workflow.

Because of this i don't know what the problem is

[bsalesc]

I have the same issue with 28 API level and was working in the last build 21 hours ago, but the warnings above isn't the problem because the build which passed had the same, so the problem happens between installing the system images and creating AVD.

[JohnBellSageCom]

Saw the same issue a couple of days ago, then changed the config which resolved the issue for 24 hours. The issue is now back again. I can also confirm that the warnings were present on the successful builds as mentioned by @bsalesc.

[bsalesc]

Changing from the API level from 28 to 27 worked.

[marcuspridham]

Ran into this also. First tried changing emulator-build but that didn't help.

Changing the target to google_apis worked though.

        with:
          api-level: 28
          target: google_apis

You don't need to change the api level then.

[mrsarm]

I think the problem is that the sdkmanager is hanging the script because waits the user to accept the SDK license terms.

How I get to that conclusion? I just tried to execute the last command before the job get frozen in my local computer, and the command does nothing other than wait for nothing like in my Github Action job:

$ sdkmanager --install 'system-images;android-29;default;x86' > /dev/null

But if you remove the > /dev/null suffix, it clears what happens:

$ sdkmanager --install 'system-images;android-29;default;x86'
License android-sdk-preview-license:    ] 10% Computing updates...              
---------------------------------------
To get started with the Android SDK Preview, you must agree to the following terms and conditions. As described below, please note that this is a preview version of the Android SDK, subject to change, that you use at your own risk. The Android SDK Preview is not a stable release, and may contain errors and defects that can result in serious damage to your computer systems, devices and data.

This is the Android SDK Preview License Agreement (the "License Agreement").

1. Introduction

1.1 The Android SDK Previ ...
...
..................... LONG LICENSE TERMS .....................
...

June 2014.
---------------------------------------
Accept? (y/N):

Unfortunately there is no option to auto-accept terms of conditions, what I saw in other posts with similar issues trying to run the sdkmanager in CI enviroments is to execute it piped with the yes command:

$ yes | sdkmanager --install 'system-images;android-29;default;x86' > /dev/null

[mrsarm]

Confirmed that what I mention is the problem, because using the workaround mentioned by @marcuspridham of setting target: google_apis works, and looking at the CLI, what is executed is:

sdkmanager --install 'system-images;android-30;google_apis;x86' > /dev/null

And executing the same in my local computer, sdkmager does not ask me to confirm any license agreement.

I have created the PR #170 with the patch.

[ashutoshgngwr]

Thanks, @marcuspridham and @ychescale9 for resolving it in a timely manner. When can we expect it to be released?

[ychescale9]

Will try to do a release in a few hours

[ychescale9]

This has been released. Thanks again @marcuspridham for the fix!