Fixed the problem with not being able to find emulators.

[aethertap]

tl;dr: On my system, the avd folder is in $HOME/.config/.android, not $HOME/.android, and that causes it to fail. Symlinking fixed it.

I am new to nativescript and android development, and after following the instructions for the plain typescript quick start, I couldn't get it to work because it couldn't find any emulators (they were correctly installed). It turns out that the emulator tool in android studio is looking for its avds in $HOME/.android/avd, but on my Manjaro Linux system the avd is in $HOME/.config/.android/avd. I symlinked the true location to the expected location and the demo app launches and runs now.

I discovered this by bumbling around trying to manually launch the emulator from the command line using the $ANDROID_HOME/emulator/emulator tool, which had enough error output that it gave me a clue. Looking up the actual path in Studio showed that it was storing avds in a different place from where it was looking for them.

I wasn't sure where to post this; it doesn't seem to be a nativescript issue at all, but it was stopping me from using nativescript so I thought I'd mention it here. There are questions about it all over the Internet and I have no idea if this is the same problem that others are having. However, if everything seems to be set up right and you still can't get the emulator to launch, make sure the avd directory is reachable from $HOME/.android/avd.

[tmaly1980]

DId you ever figure out what was causing the ~/.config/.android/avd folder to be used? For me, "avdmanager create avd" put it in that folder and "avdmanager list avd" shows the emulator, but "emulator -list-avds" shows nothing. I'm guessing it's still looking in ~/.android/avd . Frustrating that the tools from the same library aren't able to work with each other out of the box. Is it a bug in the new android SDK tools perhaps?

[aethertap]

I never did. I kind of suspect that it's something like an update intended to make it query for the user's preferences directory from the OS that didn't make it through the whole codebase, so part of it is still using the old way of doing things. I have not investigated at all after this note was posted, just a wild guess from the behavior.