Allow the mojo shell to run on android.

Allow the mojo shell to run on android.

This CL does the 3 following things to allow the mojo shell to run:

- Updates java_apk.gypi to allow bundling additional libs.
- Bundle the network service with the mojo shell.
- Updates the shell to look for .so and .cr.so file in the local file
  system for android component build.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=282015

[qsr, 2014-06-26 12:31:00]

viettrungluu@ -> changes in mojo/
cjhopman@ -> changes in build/
tim@ -> FYI

[qsr, 2014-06-26 12:31:47]

https://chromiumcodereview.appspot.com/334783006/diff/1/mojo/shell/mojo_url_r...
File mojo/shell/mojo_url_resolver.cc (right):

https://chromiumcodereview.appspot.com/334783006/diff/1/mojo/shell/mojo_url_r...
mojo/shell/mojo_url_resolver.cc:26: names->push_back("lib" + host_name +
".cr.so");
The component build on android names its library .cr.so, See build/common.gypi

[tim (not reviewing), 2014-06-26 16:33:02]

Thanks for the fyi!

https://chromiumcodereview.appspot.com/334783006/diff/1/mojo/mojo.gyp
File mojo/mojo.gyp (right):

https://chromiumcodereview.appspot.com/334783006/diff/1/mojo/mojo.gyp#newcode870
mojo/mojo.gyp:870:
'<(SHARED_LIB_DIR)/libmojo_network_service.>(android_product_extension)',
q's mostly for my own education:
- What's "android_product_extension"?
- How come the native_viewport service and network_service dependencies are so
different?

[qsr, 2014-06-26 16:41:17]

https://chromiumcodereview.appspot.com/334783006/diff/1/mojo/mojo.gyp
File mojo/mojo.gyp (right):

https://chromiumcodereview.appspot.com/334783006/diff/1/mojo/mojo.gyp#newcode870
mojo/mojo.gyp:870:
'<(SHARED_LIB_DIR)/libmojo_network_service.>(android_product_extension)',
On 2014/06/26 16:33:02, timsteele wrote:
> q's mostly for my own education:
> - What's "android_product_extension"?
> - How come the native_viewport service and network_service dependencies are so
> different?

android_product_extension is .so for normal build, .cr.so for component build,
see: build/common.gypi for explanations.

The native_viewport_service is run by the shell itself (see
mojo/shell/context.cc), which the network service is a normal application
(loaded from a .so, in another process if the shell is multi-process), but that
is special in the sense that this it is hardcoded has being a local application
that you load from disk, and that will then receive network request allowing you
to download other applications.

[viettrungluu, 2014-06-26 16:59:57]

https://codereview.chromium.org/334783006/diff/1/mojo/shell/mojo_url_resolver.cc
File mojo/shell/mojo_url_resolver.cc (right):

https://codereview.chromium.org/334783006/diff/1/mojo/shell/mojo_url_resolver...
mojo/shell/mojo_url_resolver.cc:26: names->push_back("lib" + host_name +
".cr.so");
On 2014/06/26 12:31:47, qsr wrote:
> The component build on android names its library .cr.so, See build/common.gypi

So I learned that we're probably doing it wrong, and our apps should probably be
built with (gyp) target type "loadable_module" instead of "shared_library". This
allows an app (or whatever) to depend on another app without linking with it.

I don't think common.gypi names loadable_modules with the extension .cr.so (but
who can tell anything from .gyp(i) files?), in which case this change might be
unneeded (assuming we correct all our apps to be built as loadable_modules
instead).

(On the other hand, perhaps it's common.gypi that should be corrected to also
name loadable_modules .cr.so....)

[cjhopman, 2014-06-26 17:18:04]

This might have issues in the component build on older Android versions (but I
don't know if you care about that or not). In older Android versions (not sure
when this was fixed, 4.2 or 4.3 I think), the linker could not find shared
library dependencies and you have to explicitly load your shared libraries in
dependency order.

In normal Android component builds, we write a java file when building the apk
that contains those libraries in the right order to load.

https://codereview.chromium.org/334783006/diff/1/build/java_apk.gypi
File build/java_apk.gypi (right):

https://codereview.chromium.org/334783006/diff/1/build/java_apk.gypi#newcode347
build/java_apk.gypi:347: 'stripped_libraries_dir': '<(libraries_source_dir)',
There could be some issues here if one of the additional libraries depends on
base (or some other component) that one of the main libraries also depends on.
You could have two strip calls both writing to the same file at the same time. I
don't know what happens in that case.

I think it would be best if we stripped everything in one step (could just make
ordered_libraries_file a list). Another option would be to force an ordering
between the two actions by adding the stamp of one to inputs of the other.

[qsr, 2014-06-27 11:18:18]

https://codereview.chromium.org/334783006/diff/1/build/java_apk.gypi
File build/java_apk.gypi (right):

https://codereview.chromium.org/334783006/diff/1/build/java_apk.gypi#newcode347
build/java_apk.gypi:347: 'stripped_libraries_dir': '<(libraries_source_dir)',
 Good point.

 Making it in a single path is unfortunately no that easy. The python script is
using named parameters for the json file, which makes it hard to get a random
number of parameters. Moreover, it would mean some target that use
ordered_libraries_file now take a single one, while other takes multiple.

 I added the stamp as a dependency for the additional one.

 Is that fine with you?

https://codereview.chromium.org/334783006/diff/1/mojo/shell/mojo_url_resolver.cc
File mojo/shell/mojo_url_resolver.cc (right):

https://codereview.chromium.org/334783006/diff/1/mojo/shell/mojo_url_resolver...
mojo/shell/mojo_url_resolver.cc:26: names->push_back("lib" + host_name +
".cr.so");
On 2014/06/26 16:59:57, viettrungluu wrote:
> On 2014/06/26 12:31:47, qsr wrote:
> > The component build on android names its library .cr.so, See
build/common.gypi
> 
> So I learned that we're probably doing it wrong, and our apps should probably
be
> built with (gyp) target type "loadable_module" instead of "shared_library".
This
> allows an app (or whatever) to depend on another app without linking with it.
> 
> I don't think common.gypi names loadable_modules with the extension .cr.so
(but
> who can tell anything from .gyp(i) files?), in which case this change might be
> unneeded (assuming we correct all our apps to be built as loadable_modules
> instead).
> 
> (On the other hand, perhaps it's common.gypi that should be corrected to also
> name loadable_modules .cr.so....)

 Hum... Very nice. That also probably explain my issues with the non component
build. I'll took another stab at it.

 For this, we then do not need this hack, nor .cr.so. The change of name is to
prevent conflict with some system libraries. There is no reason for loadable
module to conflict with system library, so we should name those .so.

[qsr, 2014-06-30 07:55:30]

gentle ping?

[cjhopman, 2014-06-30 21:49:02]

lgtm

[viettrungluu, 2014-06-30 21:58:15]

Rubberstamp LGTM, though since I added you to mojo/OWNERS, maybe this is
unnecessary. :)

[qsr, 2014-07-09 08:43:07]

The CQ bit was checked by qsr@chromium.org

[commit-bot: I haz the power, 2014-07-09 08:44:21]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/qsr@chromium.org/334783006/40001

[commit-bot: I haz the power, 2014-07-09 13:06:50]

Change committed as 282015