stf
stf copied to clipboard
Basic emulators support, for use with API
Hi!
In issues #57, #181 it was mentioned that emulator support won't be implemented soon, because it is low priority feature.
No, STF isn't designed to work with emulators. It's because they don't use SurfaceFlinger for rendering like real devices. It might be possible to make some emulators work, but I don't think it's worth the time and effort. If you have a compelling use case, feel free to let us know.
Since STF has REST API and is used for test automation, it seems there is quite useful but cheap (?) feature like "Basic Emulators Support":
- it has nothing to do with emulator's screen - neither you can see it, nor interact (it makes feature cheap)
- you can reserve/release emulator using API
- emulator is available in interface, you can install apk, push/pull files, inspect logcat, etc.
Such feature is useful if you use emulators for test automation, and you want to integrate STF in this process, and it seems shouldn't be very expensive to add it.
So, what do you think about such feature? Does it correlate with STF concept?
Yeah, it would be great and it's definitely something we'd like to have at some point. However, nearly all our development time is unpaid right now, and I guesstimate it would take up to several weeks of full time work to get it done. So basically there's a financial barrier that's keeping this from being implemented for now.
This ticket will be kept open as the official emulator support ticket.
OK, thanks for response. Maybe I will try to implement this
Probably some good news about Android Emulators:
"New" Android Emulator Beta, which comes with Android Studio 2.0 (http://tools.android.com/tech-docs/emulator) works almost fine with stf without any improvements:
- it is visible in interface, you can bind it, you can establish a remote connection via adb connect. You only can't see the screen of emulator, although you can interact with this "black screen" you see in stf web interface and control emulator's screen!
@rseek Nice. That means that you might have to only change minicap to make the screen work also. Let us know if you make any progress ;)
Hi, Anyone can share what are the required changes in minicap? I'd like to use openstf to remote control emulators
Some emulator are based on virtualbox maybe you could try with virtualbox api
anyone tried how it works with emulators: @rseek ?
@bexp, STF works just fine with emulators except one thing - you won't be able to see emulator's screen in stf.
Also, you can user this dirty hacked minicap, which provides screen support for emulators.
how do you use it ? I've tried to manually build minicap and push it on emulator but STF still shows black screen. I found that minicap executable located in data/local/tmp/minicap-devel so I copy it to one level above. Anything that I'm missing ?
Hi, I'm facing the same problem. Tryed rseek's solution, but I think I'm missing something on the build. Tryed to run on the root directory:
ndk-build clean
ndk-build V=1
But with the same result. Can anyone share some light, pls?
I noticed the same problems as you when I created avd: Galaxy_Nexus_API_25 and I tried to connect emulator to stf.
What I done: I checkout minicap: https://github.com/openstf/minicap and I done building process using android-ndk-r15c.
Basing on informations from run, when you are running minicap with run.sh is:
adb shell 'mkdir /data/local/tmp/minicap-devel 2>/dev/null || true'
- adb push libs/x86/minicap /data/local/tmp/minicap-devel 3891 KB/s (989164 bytes in 0.248s)
- '[' -e jni/minicap-shared/aosp/libs/android-7.1.1/x86/minicap.so ']'
- adb push jni/minicap-shared/aosp/libs/android-25/x86/minicap.so /data/local/tmp/minicap-devel 316 KB/s (17848 bytes in 0.055s)
- adb shell LD_LIBRARY_PATH=/data/local/tmp/minicap-devel /data/local/tmp/minicap-devel/minicap -P 1080x1920@1080x1920/0 PID: 4232 INFO: Using projection 1080x1920@1080x1920/0
So what was important in my case, was to copy correct minicap.so ( jni/minicap-shared/aosp/libs/android-25/x86/minicap.so) to /home/luze/stf/stf/node_modules/minicap-prebuilt/prebuilt/x86/lib/android-25/ folder. ( I created emulator folder to separate real devices,from emulators.)
After that I copied:
- libs/x86/minicap
- libs/x86/minicap-nopie
to stf/stf/node_modules/minicap-prebuilt/prebuilt/x86/bin ( in my case emulator). If you will not add as me emulator folder under prebuilt folders, screensharing of emulator framebuffer to STF should still work for you, but it will cause issue with real devices.
I'm in progress of adding changes to emulator folder to split real devices libs and binaries from emulator one. As created new binaries are not compatible with real device(with my nexus 5, so I think also with other one devices). So splitting minicap binaries for emulators and real device need to be done. If you are using separate stf, you can feel free to use one stf provider to run only emulators.
It works quietly good. I'm running at current one emulator, and my machine is not powerful, so I observe some lags, which might to be caused with performance of my machine. It will be good to investigate this.
I have hope that part of described steps will help you to enable emulator with screen sharing on your stf.
Small changes, which enable running emulator and real devices( need to create separate binaries and libs and put them inside: node_modules/minicap-prebuilt/prebuilt/x86/lib/android-X/emulator/ node_modules/minicap-prebuilt/prebuilt/x86/bin folders you can find at: https://github.com/lukzeg/stf/tree/enable_android_emulators ) It is in progress, so my apologies. I'm not guru from nodejs, so please forgive me any mistakes
Hi @sorccu, Is there any possibility to add: https://github.com/openstf/minicap/tree/master/jni/minicap-shared/aosp/libs to minicap-prebuild npm package as separate aosp libs, which can be used for emulators? Also if this will be possible, can we add two more binaries, generated during building process:
minicap minicap-niop to this repository under x86/bin sub-folder(aosp or emulator as I done locally)?
Or do you agree to add those libs under vendor folder of STF, to enable emulator support? I can share with you binaries, generated during building process which works for me on my ubuntu 16.04 LTS and macOS Sierra 10.12.6. Those binaries were tested for API25 and API26, or you can generate them by yourself.
Binaries were generated from minicap project: https://github.com/openstf/minicap
rev: 61cd2e6b747a38d420a0fafe2a3443cc7a06fa72
build by cmd:
<path>/android-ndk-r15c/ndk-build NDK_DEBUG=0
Can you explain a little more about what you want to do? What is minicap-niop? Where's the link to the changes? Currently your links go to our repository, which doesn't have any of those changes.
I can't include any binaries that I haven't built myself, but I would consider adding them to the package if I was able to build them myself. Again, more details needed, though.
Hi @sorccu , My apologies for my last not fully clear comment.
The changes to run emulators(also restart emulators on localhost) are stored at this branch: https://github.com/lukzeg/stf/tree/enable_android_emulators
Inside those changes: lib/units/device/resources/minicap.js
I'm changing location from where we load used by emulator minicap.so (to stream screen), as well generated during building process minicap and minicap-niope files( created from master source code: https://github.com/openstf/minicap)
The minicap.so is not changed binary, which was copied from: https://github.com/openstf/minicap/tree/master/jni/minicap-shared/aosp/libs/ to minicap-prebuild node module: node_modules/minicap-prebuilt/prebuilt/x86/lib/android-X/emulator/
About minicap-niop. I done typo, I should write minicap-niope. I double checked minicap-niope and minicap binaries, and there is no need to created any new one. Mostly mentioned in this ticket problems with streaming screen from emulator to stf was connected with usage generated minicap.so libs on emulator instead of prebuild from: https://github.com/openstf/minicap/tree/master/jni/minicap-shared/aosp/libs/
I'm not sure, should I create pull request with my current changes or no. I will be grateful for anyone code review, and opinion, did those changes will be useful, or no, or what should be changed.
I know that mentioned by me implementation is limited(as emulators can be restarted on localhost of STF machine) but I will be grateful for any info.
Also I will add I hope today additional method to switch orientation of emulator, as adb cmd is changing orientation for a second. To change screen orientation of emulator, I should use as for restarting emulator telnet: https://developer.android.com/studio/run/emulator-console.html with cmd: ''' rotate '''
Once more, I will be grateful for any suggestions, what should be changed, to move those changes maybe to pull request.
I am slightly confused, but if the emulator is x86, wouldn’t STF already attempt to load the x86 minicap and minicap.so? You mentioned earlier that the generated binaries didn’t work on a real device, so they needed to be in a separate folder. But Nexus 5 isn’t an x86 device. Did you perhaps attempt to run the x86 binaries on your Nexus?
If there are no changes to the binaries, I don’t really see how it would break real devices. Let me know if I’ve misunderstood, though.
Hi @sorccu,
Today I wanted to reproduce all my previous issues, to deliver you as much informations as possible. I checkout latest repo and repo with sha: c953779b983a487096a6d6afe49f1cd9bcd863f7
and I'm not able to reproduce my problems with screen sharing, which was caused by minicap.so. The emulators works without any troubles. I'm not sure what happened, I installed qt5 but this should not have any impact on way, how stf works.
I can't say, how guilty I feel by disturbing you right now. Once more time, my apologies.
Don't worry you provided details and tested things out. Good work.
This issue is still valid?
Hi @mariuszs , This is a good question. Basic API, viewing screen and making action woks without on emulators which I created from AVD(Android Studio v3.0.1 - Linux). So we can say yes. The problems with setup of emulators you might to start to observe, when you have few providers. In current implementation, when you have two emulators working on the same port 5554 and both of them works on two different providers, the last started one will override data in db (device table). I described this problem in issue: https://github.com/openstf/stf/issues/753 I done changes which solve this issue. Instead of storing 'emulator-XXXX' serial number for emulator(which is not unique), I'm storing 'privder_hostname-XXXX' as unique serial number, which I'm parsing in the code to emulator-XXXX. This is not nice solution, but it works. Also I added some extra functionality: a) provider at start discover created by user emulators and add them to device table b) in view of devices, end user will be able to find not runnign emulators, and start them. At current moment, emulators will be started with those flags: -wipe-data -no-boot-anim -no-window Description of those flags you can find at: https://developer.android.com/studio/run/emulator-commandline.html#startup-options. The changes are located at: https://github.com/lukzeg/stf/tree/enable_android_emulators
I'm not sure, should I create PR with those changes or no, as I'm not the guru from JS. If someone is interested to look at those changes, thats great. I will be grateful for any suggestions about what should be fixed and maybe how :).
Is there any update on this issue? I'd love to know we can use emulators.
UP: Can you share actual status on 2021 year?
Hi! Is there any progress?
Thanks!