Device is unauthorized

[red-avtovo]

Latest emulator doesn't provide debugging option enabled by default, which doesn't allow to run automation on Android 7.x

Operating System:
Debian 9

Docker Image:
butomo1989/docker-android-x86-7.1.1

Docker Version:
18.03.1-ce, build 9ee9f40

Docker Command to start docker-android:

docker run -d \
	--privileged \
	--restart=unless-stopped \
	--link selenium-hub:hub \
	-p 6080:6080 \
	-p 4724:4723 \
	-e DEVICE="Nexus 5" \
	-e APPIUM=True \
	-e CONNECT_TO_GRID=True \
	-e APPIUM_HOST="ip" \
	-e SELENIUM_HOST="hub" \
	-e APPIUM_PORT=4724 \
	-e SELENIUM_PORT=4444 \
	-e MOBILE_WEB_TEST=True \
	-e BROWSER=chrome \
	--name android-container711 \
	butomo1989/docker-android-x86-7.1.1

Expected Behavior

Device is authorized or at least asking for authorization, like on android 8.x images

Actual Behavior

[budtmo]

I think it is possible to do it manually under Developer Option @red-avtovo , but yes, we need to automate it somehow.

[red-avtovo]

I'm digging in it and I really hope, that this is just 1 argument to avd creation or emulator starting

[diemol]

I bumped into the same issue some weeks ago, the root cause is because when the emulator is using Google Play Services it assumes that it is a "production build", so no root access is possible.

To install apps and so on, adb uses the common mechanism of private and public keys. And this error pops up when the emulator does not have the public key of the adb server.

The way I fixed it in our project was to do "adb devices" before starting the emulator. This is implicitly starting the adb server and generating the keys before the emulator is started, and when the emulator starts it will have the adb server keys.

That is what needs to be automated in order to have it working.

[red-avtovo]

Will try that! Thank @diemol

[red-avtovo]

@diemol that would be super easy, but it didn't work. I see the keys, but emulator doesn't know about them.

[red-avtovo]

I solved an issue by starting emulator with -wipe-data flag.

[budtmo]

Hi @red-avtovo ,

Could you create a PR for it? It would be great.

[diemol]

ah ok, the adb devices thing works when the AVD has not been created yet, which is the approach I was using (and I omitted that part).

Your solution seems pretty good as well, I didn't think about it :) But I guess that can make the boot process slightly slower?

[red-avtovo]

I didn't make a PR yet, because I'm pretty sure, that we need this tweak just for first container run.
After container restart that would be quite annoying to loose all data.

[budtmo]

Fixed in release 1.2

[shadow1163]

@butomo1989 @red-avtovo Hi, I can reproduce this issue using image "butomo1989/docker-android-x86-7.1.1" tag 1.2, its image id is "ace02bf9cf03".

Here is docker command

docker run --privileged --network external --ip 10.2.2.71 -d -p 6080:6080 -p 5554:5554 -p 5555:5555 -p 4723:4723 -e DEVICE="Samsung Galaxy S6" -e APPIUM=true --name android7 butomo1989/docker-android-x86-7.1.1

Container logs are here.

2018-07-16 23:54:05,355 CRIT Supervisor running as root (no user in config file)
2018-07-16 23:54:05,371 INFO supervisord started with pid 8
2018-07-16 23:54:06,374 INFO spawned: 'xvfb' with pid 11
2018-07-16 23:54:06,375 INFO spawned: 'port-forward' with pid 12
2018-07-16 23:54:06,377 INFO spawned: 'novnc' with pid 13
2018-07-16 23:54:06,379 INFO spawned: 'openbox' with pid 14
2018-07-16 23:54:06,382 INFO spawned: 'x11vnc' with pid 15
2018-07-16 23:54:06,383 INFO spawned: 'android-screen-mirror' with pid 16
2018-07-16 23:54:06,384 INFO spawned: 'docker-appium' with pid 17
2018-07-16 23:54:06,386 INFO spawned: 'auto-recording' with pid 18
2018-07-16 23:54:06,892 INFO success: android-screen-mirror entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2018-07-16 23:54:06,893 INFO exited: android-screen-mirror (exit status 0; expected)
2018-07-16 23:54:07,600 INFO success: xvfb entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-07-16 23:54:07,600 INFO success: port-forward entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-07-16 23:54:07,600 INFO success: novnc entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-07-16 23:54:07,600 INFO success: openbox entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-07-16 23:54:07,600 INFO success: x11vnc entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-07-16 23:54:07,600 INFO success: docker-appium entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-07-16 23:54:07,600 INFO success: auto-recording entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-07-16 23:54:12,896 INFO exited: auto-recording (exit status 0; expected)

Could you help to confirm it, please?

[JoeSSS]

I also have the issue but only with playstore image.. tried everything there and rolling back to normal google_apis as I cannot understand what playstore needs..

[JoeSSS]

@red-avtovo @butomo1989 can you please reopen the issue? The issue is still there on the playstore image. Tried to fix it in the several ways today but I'm out of ideas, need new sources :))

[red-avtovo]

@butomo1989 please open this issue
@JoeSSS @shadow1163 I will try to fix it tomorrow

[JoeSSS]

Do you have ideas of what can be done there? Interesting is that:
a) This doesn't happen when you access emulator from the inside of container. It happens only on adb start-server from outside the container
b) Clicking remember checkbox doesn't really help. After adb kill-server && adb start-server it will request the access again.. I thought that it can be related to adbkey from .android and copied it over to local linux machine but it also didn't work

[budtmo]

Sorry guys @red-avtovo @JoeSSS @shadow1163 , I have a visit until end of next week so I cannot help :(

[red-avtovo]

@JoeSSS oh, that happens, because you are not sharing the same Android key with container.
Right after we create the container, we generate new identity and then newly created emulator remembers the key of his creator.
My fix did not imply the case, when you try to access the emulator from outside of container

[JoeSSS]

so, you must run tests inside the container? I use it from running Calabash tests and they are outside.

[red-avtovo]

Would be good if you will try to use the container as a Grid node. It will proxy all requests through Appium server and eventually execute all commands on container locally

[red-avtovo]

@shadow1163 do you try to connect to emulator through exposed port outside of container?

[JoeSSS]

I mean, I may be able to workaround it by just including my tests to the container and just run them inside. But I think that this guy will still trigger adb from outside to get acces + I believe that there are situations when people just want to use the emulator from local :)

[JoeSSS]

do you think that it is possible to do something here? for example using the same key for both envs if one already exist or defined

[red-avtovo]

Then you should run your container with passing directory sharing option:

docker run ... -v <local Android key directory>:/root/.android/

Your local Android key should already be here: ~/.android
After first run of the container, the new emulator instance will be created with your own key and it will solve the issue

[JoeSSS]

I will try it tomorrow when I have access to my laptop :) Thanks a lot @red-avtovo

[shadow1163]

@red-avtovo I have tried to connect Android on remote machine, the result is same.

    if not is_initialized():
        cmd = 'emulator/emulator @{name} -gpu off -verbose -wipe-data'.format(name=avd_name)
    else:
        cmd = 'emulator/emulator @{name} -gpu off -verbose'.format(name=avd_name)

I checked the source code, the cmd string always be not include flag "-wipe-data", does it?

[red-avtovo]

I added -wipe-data for the first run to initialise emulator with the key, that was generated inside of container.
To improve boot time and to let people to keep data inside of emulator storage, container starts from the second time without this flag.

[red-avtovo]

@JoeSSS what are your findings? Did you find time to verify proposed solution?

[shadow1163]

The container was run first time, the line app.py line 203 has created file "/root/init", so the line 210 should always return false.

[JoeSSS]

@red-avtovo not yet, was busy yesterday. Checking it now

[shadow1163]

I created a PR, please help to review it, thanks very much. @red-avtovo @butomo1989

[JoeSSS]

@red-avtovo it works as a charm! I think I will create a README note about this #96 . Thanks a lot.