AzimoLabs/fastlane-plugin-automated-test-emulator-run

android command fails after sdk update

markuskallander opened this issue · 23 comments

WI the latest Android SDK I get this error trying to use the plugin:

+------------------+--------------------------------+ [14:45:30]: Exit status of command '/Users/markus/Library/Android/sdk/tools/android list avd' was 1 instead of 0. The android command is no longer available. For manual SDK and AVD management, please use Android Studio. For command-line tools, use tools/bin/sdkmanager and tools/bin/avdmanager

Hi, I have also noticed the change like 5 minutes ago.
I won't be able to fix it instantly as I need to rewrite a lot of stuff.
Expect fix/adjustment to new SDK at start of next week.
Sorry for inconvenience.

Thanks for a quick reply! And good luck with the change :)

I have tried to play with new Build Tools today for like 10 hours and in my opinion it's very buggy. AVD seems to randomly do not receive authorisation and stays in "unauthorized" adb status. The same AVD can launch and then after turning it off it can be "unauthorized" on next launch.

It sometimes happened to me when I created and launched them by Android Studio but in 90% it's terminal launch that seems to malfunction.

Created issue for it in Google Issues.

Workaround for it could be attempt to restart ADB every time "adb devices" return device with "unauthorized" status. But I don't like this idea as some people asked me to create switch for "restart adb" option in plugin. They probably would not like it either.

Still looking for good solution.

Did you maybe notice something?

No, I have not had any problems running the emulators locally after the SDK upgrade...

Downgrading to SDK Tools, Revision 25.2.5 did the thing. But a fix to handle new SDK would be nice :)

Yeah I am working on it. Expect fix soon guys.
AVDs don't launch poperly on my PC though from shell... but that might be my PC config issue.

I have a request.

Could you please help me to detect an issue and try this?

Create 3 AVDs.

echo "no" | $ANDROID_HOME/tools/bin/avdmanager create avd --name "Test-Emulator-API23-Nexus-5-0" --package "system-images;android-23;google_apis;x86_64" --device "Nexus 5X" --tag "google_apis" --abi "x86_64"
echo "no" | $ANDROID_HOME/tools/bin/avdmanager create avd --name "Test-Emulator-API23-Nexus-5-1" --package "system-images;android-23;google_apis;x86_64" --device "Nexus 5X" --tag "google_apis" --abi "x86_64"
echo "no" | $ANDROID_HOME/tools/bin/avdmanager create avd --name "Test-Emulator-API23-Nexus-5-2" --package "system-images;android-23;google_apis;x86_64" --device "Nexus 5X" --tag "google_apis" --abi "x86_64"

Try to boot:
Run first command, wait till full boot

$ANDROID_HOME/tools/emulator -avd "Test-Emulator-API23-Nexus-5-0" -port 5556 -gpu on -show-kernel -verbose &>/dev/null &

Run second command, wait till full boot

$ANDROID_HOME/tools/emulator -avd "Test-Emulator-API23-Nexus-5-1" -port 5558 -gpu on -show-kernel -verbose &>/dev/null &

Run third command, wait till full boot

$ANDROID_HOME/tools/emulator -avd "Test-Emulator-API23-Nexus-5-2" -port 5560 -gpu on -show-kernel -verbose &>/dev/null &

Then try:

adb devices

Are all devices set to status device? Because I very very often get unauthorized.

If yes: repeat once again please.
If no: Just report to me.

I would be really glad for help and your cooperation. I'd like to detect if issue exists only on my side.

[10:53:06]: $ echo 'no' | avdmanager create avd --name 'Test-Emulator-API23-Nexus-5-0' --package 'system-images;android-23;google_apis;x86_64' --device 'Nexus 5X'
[10:53:09]: ▸ Error: Invalid --tag default for the selected package.

Add --tag google_apis did the trick

Hi, try again. I have updated commands with --tag and --abi.

Generally I have just checked on my peer PC and he has the same problem with "unauthrozed" devices. And and one more I haven't seen even once on my life :P

Anyway guys. I'd appreciate your feedback. Idea is to create 3 AVD from terminal and launch them one by one and then check adb statuses.

I will bring plugin to shape you can use. If tools are buggy or not is a secondary thing but in my honest opinion latest changes won't do any good for us.

Yes, same issue on macOS Sierra:

List of devices attached
emulator-5560   unauthorized
emulator-5558   device
emulator-5556   device

I got unauthorized on one of three on a Macbook Pro 2015.

List of devices attached
emulator-5560 unauthorized
emulator-5558 device
emulator-5556 device

So in general my plugin won't be able to start any AVDs in your case because it waits for AVD statuses to become device. We will need to restart ADB every time we get unauthorized device status to workaround this.

I will add this thread to my google issue to show that it is not only my problem.

Hey guys.
Now it should be usable.

Give me any feedback you want. I can make some adjustments and changes.

I get the following error:

Exception: Lane was stopped by plugin /Library/Ruby/Gems/2.0.0/gems/fastlane-plugin-automated_test_emulator_run-1.4.0/lib/fastlane/plugin/automated_test_emulator_run/provider/avd_setup_provider.rb:168:in throw_error'
/Library/Ruby/Gems/2.0.0/gems/fastlane-plugin-automated_test_emulator_run-1.4.0/lib/fastlane/plugin/automated_test_emulator_run/provider/avd_setup_provider.rb:46:in block in get_avd_schemes' /Library/Ruby/Gems/2.0.0/gems/fastlane-plugin-automated_test_emulator_run-1.4.0/lib/fastlane/plugin/automated_test_emulator_run/provider/avd_setup_provider.rb:25:in each'
/Library/Ruby/Gems/2.0.0/gems/fastlane-plugin-automated_test_emulator_run-1.4.0/lib/fastlane/plugin/automated_test_emulator_run/provider/avd_setup_provider.rb:25:in get_avd_schemes' /Library/Ruby/Gems/2.0.0/gems/fastlane-plugin-automated_test_emulator_run-1.4.0/lib/fastlane/plugin/automated_test_emulator_run/actions/automated_test_emulator_run_action.rb:12:in run'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/runner.rb:243:in block (2 levels) in execute_action' /Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/actions/actions_helper.rb:50:in execute_action'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/runner.rb:221:in block in execute_action' /Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/runner.rb:217:in chdir'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/runner.rb:217:in execute_action' /Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/runner.rb:139:in trigger_action_by_name'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/fast_file.rb:146:in method_missing' Fastfile:98:in block (2 levels) in parsing_binding'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/lane.rb:33:in call' /Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/lane.rb:33:in call'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/runner.rb:49:in block in execute' /Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/runner.rb:45:in chdir'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/runner.rb:45:in execute' /Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/lane_manager.rb:52:in cruise_lane'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/command_line_handler.rb:30:in handle' /Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/commands_generator.rb:105:in block (2 levels) in run'
/Library/Ruby/Gems/2.0.0/gems/commander-4.4.3/lib/commander/command.rb:178:in call' /Library/Ruby/Gems/2.0.0/gems/commander-4.4.3/lib/commander/command.rb:178:in call'
/Library/Ruby/Gems/2.0.0/gems/commander-4.4.3/lib/commander/command.rb:153:in run' /Library/Ruby/Gems/2.0.0/gems/commander-4.4.3/lib/commander/runner.rb:446:in run_active_command'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:38:in run!' /Library/Ruby/Gems/2.0.0/gems/commander-4.4.3/lib/commander/delegates.rb:15:in run!'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/commands_generator.rb:302:in run' /Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/commands_generator.rb:42:in start'
/Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/fastlane/lib/fastlane/cli_tools_distributor.rb:65:in take_off' /Library/Ruby/Gems/2.0.0/gems/fastlane-2.19.3/bin/fastlane:15:in <top (required)>'
/usr/local/bin/fastlane:23:in load' /usr/local/bin/fastlane:23:in <top (required)>'`

Here is the avd config:

{ "avd_list": [ { "avd_name": "lvl24", "create_avd_target": "android-24", "create_avd_abi": "default/armeabi-v7a", "create_avd_hardware_config_filepath": "", "create_avd_additional_options": "", "launch_avd_snapshot_filepath": "", "launch_avd_launch_binary_name": "emulator64-arm", "launch_avd_port": "", "launch_avd_additional_options": "-no-boot-anim -no-window -skin \"768x1280\"" } ] }

With your config I get this:

screen shot 2017-03-13 at 16 48 44

In general problem is that config json has changed. Avdmanager requires to use totally different fields so now it will look like more like that:

{
    "avd_list": [
        {
          "avd_name": "Test-Emulator-API23-Nexus-5-1",

          "create_avd_package": "system-images;android-23;google_apis;x86_64",
          "create_avd_device": "Nexus 5X",
          "create_avd_tag": "google_apis",
          "create_avd_abi": "x86_64",
          "create_avd_additional_options": "",
          "create_avd_hardware_config_filepath": "~/Android/AVD_Snapshots/Nexus_5X_API_23/Test-Emulator-API23-Nexus-5-1.ini",

          "launch_avd_port": "",
          "launch_avd_snapshot_filepath": "~/Android/AVD_Snapshots/Nexus_5X_API_23/Nexus_5X_API_23_SNAPSHOT.img",
          "launch_avd_launch_binary_name": "emulator",
          "launch_avd_additional_options": "-gpu on -show-kernel -verbose"
        }
    ]
}

As you can see there is no "target" anymore and there is "package" and "tag", "abi" uses different values than before.

Try something like that maybe?
Not sure if "default" is must-be there.

{  
    "avd_list":[  
        {  
          "avd_name": "lvl24",

          "create_avd_package": "system-images;android-24;default;armeabi-v7a",
          "create_avd_device": "",
          "create_avd_tag": "default", 
          "create_avd_abi": "armeabi-v7a",
          "create_avd_additional_options": "",
          "create_avd_hardware_config_filepath": "",

          "launch_avd_port": "",
          "launch_avd_snapshot_filepath": "",
          "launch_avd_launch_binary_name": "emulator64-arm",
          "launch_avd_additional_options": "-no-boot-anim -no-window -skin \"768x1280\""
        }
    ]
}

One step forward, but receiving this error message now:

[16:58:06]: AVD with name 'lvl24' does not exist. Creating new AVD.
[16:58:06]: $ echo "no" | /Users/markus/Library/Android/sdk/tools/bin/avdmanager create avd --name "lvl24" --package "system-images;android-24;default;armeabi-v7a" --tag default --abi armeabi-v7a
[16:58:12]: ▸ Do you wish to create a custom hardware profile? [no]
[16:58:12]: Restarting adb
[16:58:12]: $ /Users/markus/Library/Android/sdk/platform-tools/adb kill-server
[16:58:12]: $ /Users/markus/Library/Android/sdk/platform-tools/adb start-server
[16:58:12]: ▸ error: protocol fault (couldn't read status): Connection reset by peer
+------------------+--------------------------------+
| Lane Context |
+------------------+--------------------------------+
| DEFAULT_PLATFORM | android |
| PLATFORM_NAME | android |
| LANE_NAME | android instrumentation_single |
+------------------+--------------------------------+
[16:58:12]: Exit status of command '/Users/markus/Library/Android/sdk/platform-tools/adb start-server' was 255 instead of 0.
error: protocol fault (couldn't read status): Connection reset by peer

That's a bit weird because ADB restart was there on previous version too.

Can you do it manually?

Like open terminal and try to type:

adb kill-server
adb start-server
adb devices

Hey guys.
I got response from Google that they are working on issue.
@markuskallander are you still having problem with ADB restart?
Does it happen always?
Does it happen only when you use the plugin?

Hello guys. Seems like with update of new tools 'unauthorized' bug has disappeared.

Additionally when you update SDK Tools to 26.0.0 emulator binary is now located in sdk/emulator/ directory rather than sdk/tools/ directory so if you update SDK please use latest plugin ver 1.4.1 to avoid crashes.

Furthermore plugin is successfully ported to use new binaries which was topic of this ticket.