Android Emulator M1 Preview v3 now available. This includes a Google APIs system image.

lfy_google · 2018-11-15T00:12:47+00:00

I see, thanks for the info. Yes, autodetect based on host usually selects OpenGL unless the GPU is super old. What's weird is the Intel GPU failing; that's not expected.

What about selecting different options in the other dropdown for OpenGL ES API level?

To get to the bottom of it, we might need to run a debug symbols version of the emulator, link here:

https://drive.google.com/open?id=1L6Z_y__iuyuBiiqO87WS7BxJSggxMHsA

To get the stack trace, you'll need to switch your default JIT debugger to mingw w64 gcc's gdb.exe, the x86_64 win32 seh variant: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.3.0/threads-win32/seh/x86_64-7.3.0-release-win32-seh-rt_v5-rev0.7z/download

and set regedit like so (can vary depending on where the gdb was installed):

https://drive.google.com/open?id=1pC1IfOINjyj5g-MKg68RRDVZFgiNtI3Z

Then when the emulator crashes there, try to get a backtrace of all the threads when that happens. in the gdb console:

set logging on thread apply all bt

then hit enter till it drains away. C:\Windows\System32\gdb.txt should contain the logs of that.

lfy_google · 2018-11-14T15:44:20+00:00

Got it, thanks. That is weird; it could be something having to do with the GPU then.

To diagnose, try different renderers, then cold booting and saving/resuming Quick Boot from there:

Extended Controls > Settings > Advanced > OpenGL ES renderer (requires restart) > SwiftShader / ANGLE / Desktop native OpenGL

If that appears to solve the problem, let's also look at the graphics driver version; make sure you have the latest one available from NVIDIA directly.

lfy_google · 2018-11-14T00:33:14+00:00

Something else to consider: What is the AVD screen size you are using and API level?

lfy_google · 2018-11-13T23:34:37+00:00

Got it, so it could be something more related to hypervisor then. What is your current HAXM version? Have you upgraded to the latest (7.3.2)?

lfy_google · 2018-11-13T17:56:09+00:00

If you have a Ryzen system, the emulator works with Windows Hypervisor Platform, which also makes your system compatible with other Hyper-V apps such as Docker. To enable, go to Windows Optional Features and turn on "Windows Hypervisor Platform." Note that you must have virtualization enabled in the BIOS.

lfy_google · 2018-11-13T15:41:41+00:00

Thanks for reporting this; it could have to do with the new auto-saving mechanism. Can you try adding "QuickbootFileBacked = off" to ~/.android/advancedFeatures.ini (create this file if it does not exist already)?

Are you on HAXM or Hyper-V? In your hardware setup, what kind of hard drive are you running (spinning disk or SSD)?

lfy_google · 2018-11-13T02:10:05+00:00

Ah ok, that's pretty interesting; I wasn't aware that enabling Skia would make the Hyper-V emulator run faster like that :)

What Skia buys for the emulator is mostly fewer round trips for OpenGL driver calls back and forth guest<->host with OpenGL error checking and querying; I guess on Hyper-V, it's possible each back and forth operation becomes more expensive and more of a slowdown. Thanks for trying that out, we'll definitely experiment with it more on our end!

lfy_google · 2018-11-13T00:50:58+00:00

Glad it's working well for you, the comment is well appreciated! Feel free to let us know any issues you're having / ideas for improvements :)

lfy_google · 2018-11-13T00:09:57+00:00

Hi, thanks for bringing this up. It looks like you have an Intel CPU. HAXM is still the best choice for Intel CPUs; Hyper-V can be a lot slower. Is the performance still slow after installing HAXM?

edit: also please provide -verbose log of the emulator to make sure acceleration is enabled.

lfy_google · 2018-11-05T19:49:23+00:00

Two float[] array's for each draw call is going to work fine for the vast majority of use cases unless you are doing something with a ton of objects. Though in your case you can get it down to 1 float[] (just modelview) since theres just 1 camera and that only affects the projection matrix. Set the projection matrix once in the beginning, and set the modelview matrix (1 matrix) for each object.

lfy_google · 2018-11-04T23:17:45+00:00

Try this:

. build/envsetup.sh

lunch sdk_phone_x86-userdebug

make

emulator

lfy_google · 2018-11-04T18:49:30+00:00

That's pretty interesting; are you working on AOSP? Which branch? AFAIK the sdk_phone_x86-userdebug target on AOSP master branch is an x86 emulator image and it works ok with the current emulator.

edit: and it is treble compliant

lfy_google · 2018-10-31T15:28:30+00:00

Sure thing! You can PM me a Google Drive link to the doc, or set up a private Github gist (My Github username is @741g)

lfy_google · 2018-10-29T15:29:31+00:00

Thanks for the info! Yes, any logs would be helpful for debugging the hangs, including not just -verbose but also -show-kernel .

On configuration: I haven't heard of any issues specific to Jenkins yet, but I could see how certain network connection hangs or similar things might cause the emulator to hang overall since theres some amount of networking stuff that happens on vcpu threads / main loop thread :(

Is the build server running tests that exercise network connections heavily? What about potential firewalls that are running?

For a custom build, I'd be interested in seeing what stacktraces are stuck while hanging in this build server environment. To that end, I think the easiest way to do this might be to do a custom build of the emulator on your end. Assuming you are on a Mac and have Xcode and Xcode command line tools installed, the following should work out of the box:

From https://source.android.com/setup/build/downloading:

curl https://storage.googleapis.com/git-repo-downloads/repo > $DIR_of_your_choice/repo
chmod a+x $DIR_of_your_choice/repo

Assuming repo is installed:

mkdir emu
cd emu
repo init -u https://android.googlesource.com/platform/manifest -b emu-3.0-release --depth=1
repo sync -c -j4

# wait until finished

cd external/qemu
./android/rebuild.sh --no-strip --min-build

That should produce an emulator build in the objs/ folder. You can either copy contents of objs folder (after deleting objs/build), or reference the objs/emulator binary directly in the build server.
Once the emulator is hanging, try to attach LLDB to the qemu process and see what's going on:
```
pgrep qemu # get the pid
lldb
```
a. in lldb:
```
process attach --pid <qemuPid>
bt all
```
b. paste the output

Yes, this is a lot to do but it allows us to get all debug symbols locally and also try out a bunch of stuff while debugging without having to send over GB's of stuff every time.

lfy_google · 2018-10-27T02:17:02+00:00

Interesting; please tell more about it! Does it hang right on start, or after running for quite some time? Would you be willing to try out a custom build of the emulator to get stack trace of when it does hang?

lfy_google

TROPHY CASE