avdmanger doesnt exists in android_home/tools/bin

[karl4458]

Bug Report

Problem

when run cordova requirements, cordova cli try to search avdmanger from android_home/tools/bin. but it doesnt exist since 2024.03

reference. https://learn.microsoft.com/en-us/previous-versions/xamarin/android/troubleshooting/sdk-cli-tooling-changes

what happend

avdmanger not found

Environment, Platform, Device

windows 10 21H2

cordova version

12.0.0

android studio version

Android Studio Narwhal Feature Drop | 2025.1.2 Patch 1 Build #AI-251.26094.121.2512.13930704, built on August 14, 2025 Runtime version: 21.0.6+-13391695-b895.109 amd64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. Toolkit: sun.awt.windows.WToolkit Windows 10.0 Kotlin plugin: K2 mode GC: G1 Young Generation, G1 Concurrent GC, G1 Old Generation Memory: 2048M Cores: 16 Registry: ide.experimental.ui=true

• [x] I searched for existing GitHub issues
• [x] I updated all Cordova tooling to most recent version
• [x] I included all the necessary information above

[dpogue]

The relevant code seems to be here: https://github.com/apache/cordova-android/blob/e4457f7fdb7eb854d166bb87b144bf4e1873cf61/lib/check_reqs.js#L218-L228

My guess is that it's finding avdmanager on the path, and then checking the parent folders and throwing an error that it doesn't match an old structure.

FWIW, my avdmanager is at ./cmdline-tools/latest/bin/avdmanager

[dpogue]

I've reproduced this when ANDROID_HOME is not set but avdmanager is available on the path:

dpogue@bedwyr:~/cdvTest$ unset ANDROID_HOME
dpogue@bedwyr:~/cdvTest$ npx cordova@nightly requirements
Warning: using prerelease version 13.0.0-nightly.20250903002306003.sha.cd548591 ([email protected])

Requirements check results for android:
Java JDK: installed 21.0.8
Android SDK: not installed
Failed to find 'ANDROID_HOME' environment variable. Try setting it manually.
Detected 'avdmanager' command at ~/.android/SDK/cmdline-tools/latest/bin but no 'tools/bin' directory found near.
Try reinstall Android SDK or update your PATH to include valid path to SDK/tools/bin directory.
Android target: installed android-35,android-33
Gradle: installed /usr/share/java/gradle/bin/gradle
Some of requirements check failed
(node:1937201) [DEP0187] DeprecationWarning: Passing invalid argument types to fs.existsSync is deprecated
(Use `node --trace-deprecation ...` to show where the warning was created)

@karl4458 If this error is blocking you from building with Cordova, you can work around it by setting the ANDROID_HOME environment variable to the path to your Android SDK folder.

[breautek]

Yah for context, the $ANDROID_HOME/tools is the old obsolete tools set. It requires Java 8 runtime to operate and is basically not compatible with modern tooling. Cordova shouldn't be trying to use it.

cmdline-tools is the replacement, and the tools are versioned. The user environment may have multiple cmdline-tools installed at the same time. The user could also have a "latest" version installed in which a $ANDROID_HOME/cmdline-tools/latest/... path will exist, but that may include breaking changes. Namely in the JRE requirements to run the tools. They started at requiring JRE 11, and I believe the current versions require JRE 17.

I feel like Cordova should start pinning a required cmdline-tools version, similar to what we do for build tools version. Then we can appropriately check for the avdmanager in the proper spot.

Honestly if we do this, we can probably look into automating some stuff for the user, since we can then use sdkmanager. So instead of having the user using the SDK manager themselves to install the expected build tools version, and android platform, etc... Cordova could perhaps use the SDK Manager to install these packages for the user. I think the only requirement is that we do it in a way where the user explicitly accepts any license requirements if prompted. But anyway that's just a thought, and definitely out of scope of this issue.

[dpogue]

Maybe the quick fix here is to add an else if block that looks for a bin folder 1 level up, and a cmdline-tools folder 3 levels up (since 2 levels up will be either a specific version or latest)

[breautek]

im in the process of writing a resolver, which will find the latest version installed on the workstation.

I'll then use said resolver to refactor our the /tools usage where applicable.