[GH-ISSUE #87 ] Device is unauthorized #69

Author

Owner

@budtmo commented on GitHub (Jul 6, 2018):

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

@budtmo commented on GitHub (Jul 6, 2018): I think it is possible to do it manually under Developer Option @red-avtovo , but yes, we need to automate it somehow.

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 6, 2018):

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

@red-avtovo commented on GitHub (Jul 6, 2018): I'm digging in it and I really hope, that this is just 1 argument to avd creation or emulator starting

kerem commented

Author

Owner

@diemol commented on GitHub (Jul 6, 2018):

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.

@diemol commented on GitHub (Jul 6, 2018): 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.

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 6, 2018):

Will try that! Thank @diemol

@red-avtovo commented on GitHub (Jul 6, 2018): Will try that! Thank @diemol

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 9, 2018):

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

@red-avtovo commented on GitHub (Jul 9, 2018): @diemol that would be super easy, but it didn't work. I see the keys, but emulator doesn't know about them.

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 9, 2018):

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

@red-avtovo commented on GitHub (Jul 9, 2018): I solved an issue by starting emulator with `-wipe-data` flag.

kerem commented

Author

Owner

@budtmo commented on GitHub (Jul 9, 2018):

Hi @red-avtovo ,

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

@budtmo commented on GitHub (Jul 9, 2018): Hi @red-avtovo , Could you create a PR for it? It would be great.

kerem commented

Author

Owner

@diemol commented on GitHub (Jul 9, 2018):

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?

@diemol commented on GitHub (Jul 9, 2018): 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?

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 9, 2018):

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.

@red-avtovo commented on GitHub (Jul 9, 2018): 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.

kerem commented

Author

Owner

@budtmo commented on GitHub (Jul 10, 2018):

Fixed in release 1.2

@budtmo commented on GitHub (Jul 10, 2018): Fixed in release [1.2](https://github.com/butomo1989/docker-android/releases/tag/1.2)

kerem commented

Author

Owner

@shadow1163 commented on GitHub (Jul 17, 2018):

@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?

@shadow1163 commented on GitHub (Jul 17, 2018): @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". ![docker-android-7 1 1-adb-devices](https://user-images.githubusercontent.com/8413967/42801811-7310f878-89d3-11e8-83ef-7057bec6d889.png) 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?

kerem commented

Author

Owner

@JoeSSS commented on GitHub (Jul 17, 2018):

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 commented on GitHub (Jul 17, 2018): 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..

kerem commented

Author

Owner

@JoeSSS commented on GitHub (Jul 17, 2018):

@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 :))

@JoeSSS commented on GitHub (Jul 17, 2018): @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 :))

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 17, 2018):

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

@red-avtovo commented on GitHub (Jul 17, 2018): @butomo1989 please open this issue @JoeSSS @shadow1163 I will try to fix it tomorrow

kerem commented

Author

Owner

@JoeSSS commented on GitHub (Jul 17, 2018):

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

@JoeSSS commented on GitHub (Jul 17, 2018): 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

kerem commented

Author

Owner

@budtmo commented on GitHub (Jul 17, 2018):

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

@budtmo commented on GitHub (Jul 17, 2018): Sorry guys @red-avtovo @JoeSSS @shadow1163 , I have a visit until end of next week so I cannot help :(

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 17, 2018):

@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

@red-avtovo commented on GitHub (Jul 17, 2018): @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

kerem commented

Author

Owner

@JoeSSS commented on GitHub (Jul 17, 2018):

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

@JoeSSS commented on GitHub (Jul 17, 2018): so, you must run tests inside the container? I use it from running Calabash tests and they are outside.

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 17, 2018):

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 commented on GitHub (Jul 17, 2018): 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

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 17, 2018):

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

@red-avtovo commented on GitHub (Jul 17, 2018): @shadow1163 do you try to connect to emulator through exposed port outside of container?

kerem commented

Author

Owner

@JoeSSS commented on GitHub (Jul 17, 2018):

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 commented on GitHub (Jul 17, 2018): 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](https://github.com/butomo1989/docker-android/blob/master/src/port_forward.sh) 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 :)

kerem commented

Author

Owner

@JoeSSS commented on GitHub (Jul 17, 2018):

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

@JoeSSS commented on GitHub (Jul 17, 2018): 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

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 17, 2018):

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

@red-avtovo commented on GitHub (Jul 17, 2018): 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

kerem commented

Author

Owner

@JoeSSS commented on GitHub (Jul 17, 2018):

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

@JoeSSS commented on GitHub (Jul 17, 2018): I will try it tomorrow when I have access to my laptop :) Thanks a lot @red-avtovo

kerem commented

Author

Owner

@shadow1163 commented on GitHub (Jul 18, 2018):

@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?

@shadow1163 commented on GitHub (Jul 18, 2018): @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?

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 18, 2018):

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 commented on GitHub (Jul 18, 2018): 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.

kerem commented

Author

Owner

@red-avtovo commented on GitHub (Jul 18, 2018):

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

@red-avtovo commented on GitHub (Jul 18, 2018): @JoeSSS what are your findings? Did you find time to verify proposed solution?

kerem commented

Author

Owner

@shadow1163 commented on GitHub (Jul 19, 2018):

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.

@shadow1163 commented on GitHub (Jul 19, 2018): 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.

kerem commented

Author

Owner

@JoeSSS commented on GitHub (Jul 19, 2018):

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

@JoeSSS commented on GitHub (Jul 19, 2018): @red-avtovo not yet, was busy yesterday. Checking it now

kerem commented