Reproduced on elm device 58.0.3029.18/9334.10.0

+Elijah seems like a P0. Any ideas what is happening?

verified it works on 57.0.2987.112 beta samus

The failure is that we're unable to create a native EGL surface on init, this is breaking all ARC apps.  There is a GPU process failure: https://chromium.googlesource.com/chromium/src/+blame/3799bf204600f04680a4925073038516fec75035/ui/gl/init/gl_factory_ozone.cc#88 .  This code was added in 57, but maybe another change which makes our surface params "not default" was added between then and now.

Can we bisect to find out where this broke?  

58.0.3001.0 / 9263.0.0 has working ARC, I'll bisect between that and 58.0.3027.0 to find where things broke.

Bisecting reveals this started failing at https://codereview.chromium.org/2698573002 (git hash 89ec6233). One revision earlier in Chrome has no issue launching Amazon Workspaces.

For reasons not yet determined, "HelloAndroid" has no problem running from a ./launch_chrome execution, while API Demos.apk does fail as well, with 

[22251:22251:0320/182637.656201:ERROR:gl_factory_ozone.cc(149)] NOTREACHED() hit.
CONDITION !native_context_ WAS TRUE AT mods/graphics_translation/egl/egl_context_impl.cpp:96
F/libegl:          Could not create native context.
main.nexe(arc::BacktraceInterface::Print()+0x7f) [0xf3e4d92f]
libposix_translation.so(__wrap_abort+0x4a) [0xf38b0e0a]
main.nexe(__android_log_assert_with_source_and_add_to_crash_report+0x0) [0xf3e50bc0]
main.nexe((null)+0xf3e68ecd) [0xf3e68ecd]
main.nexe(EglContextImpl::Create(void*, void*, void*, int, int*)+0x1b1) [0xf3e68b91]
main.nexe(eglCreateContext+0x141) [0xf3e5fcc1]
libhwui.so(android::uirenderer::renderthread::EglManager::createContext()+0x53) [0xf22eca73]
libhwui.so(android::uirenderer::renderthread::EglManager::initialize()+0xe0) [0xf22ed008]
libhwui.so(android::uirenderer::renderthread::EglManager::createSurface(ANativeWindow*)+0x25) [0xf22ed085]
libhwui.so(android::uirenderer::renderthread::CanvasContext::setSurface(ANativeWindow*)+0x67) [0xf22ea1db]
libhwui.so(android::uirenderer::renderthread::CanvasContext::initialize(ANativeWindow*)+0x29) [0xf22ea29d]
libhwui.so((null)+0xf22ed651) [0xf22ed651]
libhwui.so(android::uirenderer::renderthread::MethodInvokeRenderTask::run()+0x16) [0xf22eeaee]
libhwui.so(android::uirenderer::renderthread::SignalingRenderTask::run()+0x24) [0xf22eeb74]
libhwui.so(android::uirenderer::renderthread::RenderThread::threadLoop()+0xb8) [0xf22efef0]
libutils.so(android::Thread::_threadLoop(void*)+0x1a2) [0xf3618eb2]
libandroid_runtime.so(android::AndroidRuntime::javaThreadShell(void*)+0x6f) [0xf375167f]
libutils.so(thread_data_t::trampoline(thread_data_t const*)+0x87) [0xf36185a7]
main.nexe((null)+0xf3e5bf00) [0xf3e5bf00]
libc.so((null)+0xf3c7b27c) [0xf3c7b27c]
libc.so((null)+0xf3c770ae) [0xf3c770ae]
libc.so((null)+0xf3c735b9) [0xf3c735b9]

The NOTREACHED corresponds to the following in gl_factory_ozone.cc. 

  if (!format.IsDefault()) {
    NOTREACHED() << "FATAL: Ozone only supports default-format surfaces.";
    return nullptr;
  }

The CL in question here does change some GL-related behaviors, but I haven't dug into exactly what just yet.

A bit more digging:

Our code is now having GpuCommandBufferStub::Initialize return false (rather than use the default surface) due to the change here:

https://codereview.chromium.org/2698573002/diff/290001/gpu/ipc/service/gpu_command_buffer_stub.cc

I did a quick experiment where having the code use the default surface (rather than return false) results in ARC apps working again.

  

I'm sorry about this, https://codereview.chromium.org/2761153002/ should fix it and is currently going through the submit queue.

I just patched https://codereview.chromium.org/2761153002/ on top of Chrome checked out to git has 89ec6233, and ARC apps are now launching fine, including Amazon Workspaces - thank you for the pointer!

I hope we can get this merged in to M58, once it's baked on canary/dev.

Marking blocked on crbug.com/699664 - really it's a duplicate of that bug (same root cause/same fix), but that one isn't publicly visible and I want the reporter to be able to track.

I also tested ToT Chrome (which includes https://codereview.chromium.org/2761153002/) on top of ToT ChromeOS, and was able to launch Amazon Workspaces.

ToT Chrome with https://codereview.chromium.org/2761153002/ locally reverted exhibits the original failure in this bug as well, as expected.

So I am confident this will be fixed on ToT ChromeOS upon the next Chrome roll (59.0.3048.0 or later - ChromeOS 9391.0.0 or later), and will be fixed in M58 now that the CL has been merged into Chrome 3029 (M58) branch. For M58, the 58.0.3029.31 doesn't yet have the CL, but I believe the next tagged version 58.0.3029.35 should.

 Issue 704481  has been merged into this issue.

58.0.3029.35 does indeed have the patch to fix this, as per https://chromium.googlesource.com/chromium/src/+log/58.0.3029.31..58.0.3029.35?pretty=fuller&n=10000. So it should be fixed on ChromeOS M58 as of 9334.19.0.

Verified on 58.0.3029.36/9334.20.0