Migrate WebVR Cardboard implementation to GVR

build/config/features.gni

Index: build/config/features.gni
diff --git a/build/config/features.gni b/build/config/features.gni
index e1dbbcafaf2f87433a8cad2f7135117161c7399c..a7fd9454ab9b2471bee7d5022a035833b887486d 100644
--- a/build/config/features.gni
+++ b/build/config/features.gni
@@ -124,7 +124,9 @@ declare_args() {
 
   # Enable WebVR support by default on Android
   # Still requires command line flag to access API
-  enable_webvr = is_android
+  enable_webvr = is_android && is_component_build &&

[michaelbai, 2016/09/29 19:14:51]

It seems not correct to use is_component_build here, is_component_build  is for
native code, webvr has Java code,

If someone changes is_component_build, Java code are not expected to be changed.

Do you really mean 'is_debug' here?

[bshe, 2016/09/29 19:32:24]

bajones@ is OOO. I can try to answer your question.
The reason we use is_component_build here is because libgvr.so has linking issue
in
non component builds. Chrome's linker expecting only one single .so and doesn't
handle
two .so well. The solution is to get a libgvr.a and have it linked into
libchrome.so. We are
working on it and once it landed, is_component_build will be removed.

[michaelbai, 2016/09/29 19:42:14]

In this case, WebVR shouldn't be enabled by default, if you want the code be
covered by build bot, you can have a dedicated bot.

[bshe, 2016/09/29 19:50:22]

We are targetting to ship it for M55. So more coverage sounds better at this
stage. There were
some issues recently after we upgrade gvr library. We wouldn't be able to catch
them if we disable webvr. Could you elaborate the reason that you prefer us to
disable it by default?

[michaelbai, 2016/09/29 20:01:46]

First of all, the issue caused by enable_webvr depending on is_component_build
is confusing and not easy to be discovered, basically it is wrong.

Second, as you can see, if webvr only worked for component_build, it is not
ready for launch at all, and the current solution is very different than the one
you want to launch, it shouldn't be enabled by default.

Last, you can have separated bot which enables webvr to cover your code if you
really want to.

[bshe, 2016/09/29 21:03:30]

webvr actually gets a thumbs up to release in M55 if we can put everything
together before
M55 cut. The main issue for the specific code is a linking issue. It has little
to do with webvr
feature itself(And we are working on support non component build). We were able
to play with
webvr in component build.
We could have separate bots to test webvr. But there are a lot of different
combinations (cpu, release/debug, component/non component) that we want to test
for linking. It is not trivial to setup all the
combination to make sure that we could simply flip the webvr flag without
surprises near the end
of M55.
Given we only have a few days for M55, unless you still strongly disagree, it
would really simplify our work to leave it enable by default. And if we are not
able to ship webvr in M55, I will make sure that I turn it off before M55 cut.

+                 (current_cpu == "x86" || current_cpu == "x64" ||
+                  current_cpu == "arm" || current_cpu == "arm64")
 }
 
 # Additional dependent variables -----------------------------------------------