Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] ugly screenshot hack to make emulator work #27

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nwlunatic
Copy link

#12

This PR is view only, I think.

Actually minicap work on emulators without Host GPU on.
With Host GPU on it work with help of screenshotClient and, probably, OpenGL under the hood.
I am not being able to make it work using GLConsumer yet though.

@gzliuqingyun
Copy link

Hi, @nwlunatic
case download and rebuild will take a long time, so I want to know is this really work on emulator?

@nwlunatic
Copy link
Author

@qingyunliu Yes, it does. And actually on emulator we are using (Android emulator version 25.1.6.0), it's working quite fast.
If you would like to check, here is minicap.so https://www.dropbox.com/s/6j8vppbz66tud2u/minicap.so?dl=0
You should put it in stf/vendor/minicap/shared/android-23/x86/
Works only with android emulator sdk version 23, as you can see.

@sorccu
Copy link
Member

sorccu commented Jul 7, 2016

I think we could probably do this by implementing a fallback for emulators, if the ScreenshotClient works there. I can't promise when but I definitely want to take a look into this. Thank you for sharing your findings.

So everything else works, like touch events etc?

@nwlunatic
Copy link
Author

Yes, everything works just fine (minitouch, minirev), no provider erros or something, stf treats emulator as a usual device

@adpenev
Copy link

adpenev commented Jul 11, 2016

@nwlunatic Hi, I see it really works just fine for API level 23 and I would like to apply the fix for the other API levels as well. Thus, I would like to ask you how did you build this minicap.so file? Have you followed all the build steps under minicap-shared page(https://github.com/openstf/minicap/tree/master/jni/minicap-shared )? Building minicap-shared following the steps seems hard, that's why I would like to be sure this is the right way.

@nwlunatic
Copy link
Author

@adpenev Hi! Yes, I followed minicap-shared build steps and they seem quite simple in comparison to building without docker-container. Still it require quite a lot of disk space (about all of my linux laptop 150 GB (to fetch android repo) ssd to build only android-23). Si I've simplified this Makefile, to build only android-23. I've also faced this issue, but I guess building only x86 is not affected.

@adpenev
Copy link

adpenev commented Jul 12, 2016

@nwlunatic Thanks much for your answer. One more question, what linux OS did you use - Ubuntu, Mint or something? I'm on OS X and having in mind it cannot be used for the build I was thinking to create a Linux virtual machine on Virtual Box for the build.

@sorccu
Copy link
Member

sorccu commented Jul 12, 2016

By the way if you don't care about ever being able to sync the branch
again, you can remove the .repo folder to decrease disk usage. Builds will
still work fine, but repo commands won't.

On Tuesday, 12 July 2016, Igor Pavlov [email protected] wrote:

@adpenev https://github.com/adpenev Hi! Yes, I followed minicap-shared
build steps and they seem quite simple in comparison to building without
docker-container. Still it require quite a lot of disk space (about all of
my linux laptop 150 GB (to fetch android repo) ssd to build only
android-23). Si I've simplified this Makefile
https://github.com/openstf/minicap/blob/master/jni/minicap-shared/aosp/Makefile,
to build only android-23. I've also faced this issue
#24, but I guess building only
x86 is not affected.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#27 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAB-_QssOQ7KAzqQ7Hy545RHQnbrgF3yks5qU20qgaJpZM4H6eA3
.

@nwlunatic
Copy link
Author

Yep, .repo deleted 100GB, but it was a challenge to fetch all the source before deleting it )

I've used ubuntu. But I'm pretty sure you can use any linux. The only issue with OS X is case-insensitive fs by default. You can also try to make case-sensitive disk tho'

@sorccu
Copy link
Member

sorccu commented Jul 12, 2016

Yes I experienced the same thing. Making a case sensitive disk is OK, but older branches require older versions of Xcode... making it extremely annoying if not borderline impossible to build all the branches.

@nwlunatic
Copy link
Author

Oh, well. I was sure all the software to build android tree is inside the docker image. And you only need an mounted fs from host machine to put and get artifacts.
So using docker beta for OS X (docker xhyve) it is only a matter of fs case-sensitivity.

@sorccu
Copy link
Member

sorccu commented Jul 12, 2016

Right, the docker image works fine, it contains what's needed. I thought you were talking about building directly on OS X.

@adpenev
Copy link

adpenev commented Jul 14, 2016

@nwlunatic and @sorccu Thank you for your answers guys. :)

@adpenev
Copy link

adpenev commented Jul 18, 2016

Everything with the build works just fine. Thanks. :)

One question, @sorccu and @nwlunatic I remember you are using Linux what IDE and configuration do you use in order to write code, debug and build the minicap-shared project? Actually, debugging using IDE is what I really would like to setup. I downloaded and built the code on Linux Mint VM and there will be the development environment as well.

@bexp
Copy link

bexp commented Aug 15, 2016

Can you guys tell what emulator configuration you used for testing ?
I can help with that, so far I'm still seeing black screen with android-23 x86 emulator

@nwlunatic
Copy link
Author

@sorccu Hi, again ) I would like to invest some time to make normal implementation for emulator (i'm targeting x86 23 for now).
I feel myself bad with current changes, because we are using all the stuff (VirtualDisplay, FrameBuffer, CpuConsumer etc.) just to tell if we have a new frame.
Maybe you can say in general words how do you think implementation should look like in your opinion? For example, should we explicitly distinguish between device and emulator?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants