run-android should also open default simulator, like run-ios

[grabbou]

Right now, run-android will fail when there's no emulator. It can be annoying sometimes. I think it would be great to have this feature supported.

@ferrannp was investigating this issue already

[pjay79]

Agreed.

On first running the react-native run-android command, assuming a hardware device was not connected at the time, could you add command line prompts to allow selection of which emulator and virtual device to run as a default for the current project? eg:

react-native run-android
Choose your emulator? (Android Studio, Genymotion)
Enter your virtual device name:

After this, react-native run-android should run without any prompts and automatically open up the emulator and virtual device (if they are not already open), and build the app. If you want to update the emulator or virtual device settings you could re-run react-native run-android with some flags. eg:

react-native run-android --emulator="Genymotion" --device="Google Nexus 5X"

[grabbou]

I was digging around today and found there's emulator command we can use to list available devices and make similar actions as we do on run-ios. Alternatively, I guess it's newer, non deprecated version, is avdmanager

[michalchudziak]

@grabbou How would you determine default emulator?

@pjay79 I think your solution is good, but the prompt might be confusing especially for the newcomers.

I feel like choosing the first emulator listed by emulator / avdmanager, and logging some statement in there is none is also a reasonable approach.

[grabbou]

Not sure, I would just keep it in sync with whatever we do on iOS. I believe we just take the first simulator unless explicitly specified.

…

On Tue, 5 Feb 2019 at 17:52 Michał Chudziak ***@***.***> wrote: @grabbou <https://github.com/grabbou> How would you determine default emulator? @pjay79 <https://github.com/pjay79> I think your solution is good, but the prompt might be confusing especially for the newcomers. I feel like choosing the first emulator listed by emulator / avdmanager, and logging some statement in there is none is also a reasonable approach. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#142 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWcxnDE4gdMnLs8NqI_3oXG06bnCTudks5vKbbggaJpZM4aeOJN> .

[pjay79]

@grabbou @michalchudziak

Yes, avdmanager +/- emulator is probably a better approach.

If using emulator, listing and starting a device is easy enough:

emulator -list-avds
emulator -avd Nexus_5X_API_23

But what if there is no device created yet, or it's a really old device on an older API? Could this cause problems? Also you have to implement the logic to decide which device to select. Using avdmanager you can just specify which device to create as shown below, although this will force overwrite any existing device with the same name I believe:

avdmanager create avd -f -n Nexus_6P_API_28 -d 'Nexus 6P' -k 'system-images;android-28;google_apis_playstore;x86'

Could not find how to actually start a device with avdmanager, but you can use emulator again as follows:

emulator -avd Nexus_6P_API_28

I think a similar command line process exists for genymotion.

[sidferreira]

@pjay79 maybe have a .reactnativecli or in packages.json a place to set the engine (avd/genymotion) and the emulator name

[pjay79]

@sidferreira Yes that sounds reasonable.

Although...

On the Genymotion front, there is Genymotion shell that can be opened from the command line. But it can only be used to interact with an already opened virtual device.

Genymotion also has something called the GM Tool that can be used to list already installed virtual devices, and start them from the command line, but this requires an Indie ($136/year) or Business ($412) license. In view of this, it might be simpler to focus on getting things running with Android Studio to start with...?

[sidferreira]

@pjay79 I think genymotion shouldn't be in the focus yet. But we should contact their team in order to get help to make this work. I believe they will be interested in it just like we do.

[grabbou]

@sidferreira this is another topic - how (and what) we allow to be configured. Right now, there's rn-cli.config.js that is used by Metro (and all use-cases should be converted to metro.config.js).

I think we should/could use cosmiconfig, but we need to figure out what we need first.

to set the engine (avd/genymotion) and the emulator name

How about we detect whether there's Genymotion available on the machine and if yes, we concat Genymotion devices with Android Emulator devices.

Then, users just need to select the name instead of the engine, which becomes irrelevant at that point.

[sidferreira]

@grabbou I think genymotion is the least prio. About the config, I agree with cosmiconfig but my suggestion was just an idea, not something we need to prio.

IMHO (each item being one step of development, don't need to be all at once):

1. Check avd and load the first available and show an error if none is available;
2. Try to create an AVD (which one?), maybe ask if the user wants to create one
3. Create it as a "module" allowing it to be replaced (then Genymotion guy can take over from here?)
4. Save options

[grabbou]

Sounds good to me. To be honest, I am using Android Emulator recently as its quality much improved.

…

On Wed, 6 Feb 2019 at 12:42 Sid Ferreira ***@***.***> wrote: @grabbou <https://github.com/grabbou> I think genymotion is the least prio. About the config, I agree with cosmiconfig but my suggestion was just an idea, not something we *need* to prio. IMHO (each item being one step of development, don't need to be all at once): 1. Check avd and load the first available and show an error if none is available; 2. Try to create an AVD (which one?), maybe ask if the user wants to create one 3. Create it as a "module" allowing it to be replaced (then Genymotion guy can take over from here?) 4. Save options — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#142 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWcxoFyOnbRUuaKQ5GS2olS8LoreKURks5vKr-ngaJpZM4aeOJN> .

[sidferreira]

@pjay79 What if we ask about (create) the emulator and stuff on project setup (too)?

[pjay79]

@sidferreira @grabbou @michalchudziak

On the topic of which android device to select or create if one does not already exist...

If I have remembered correctly with react-native run-ios, older RN versions opened up older iPhone devices as the default. But an app built with the latest RN version, on my setup at least, automatically opens up iPhone X with iOS 12.1.

In a similar way should react-native run-android by default select a newer device and more current API as the default? If that is the case that means something like Google Pixel 3 with Android 9.0 Pie API 28. Personally, in the early stages, I tend to build with older android devices with older API's (eg Nexus 5x with Android 6.0 Marshmallow API 23), this decision somewhat based on the Google Play distribution stats (see below):

https://developer.android.com/about/dashboards/

At least on the create device point, an agreed default device/API (subject to change in future), and an easy way to adjust the default to suit developer preferences would be nice. I think it would be ok to prompt the user on setup regarding creating a device +/- providing a default device that could be accepted or amended. Alternatively the ability to add these details to a config file and a documentation for that seems ok too.