Android: Allow duplicate calls to InitApplicationContext.

Android: Allow duplicate calls to InitApplicationContext.

Allow InitApplicationContext to be called more than once as long as the
same context is passed each time. This will make it possible for
AwCookieManager to make use of certain JNI functions before Chromium has
been initialised without needing to keep track of whether it's already
passed the application context to native or not.

BUG=304813
NOTRY=true

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

[Yaron, 2013-10-31 21:11:58]

lgtm

IIRC this is part of a larger arc. Can you file a tracking bug and update BUG=

[Torne, 2013-11-01 11:42:15]

On 2013/10/31 21:11:58, Yaron wrote:
> lgtm
> 
> IIRC this is part of a larger arc. Can you file a tracking bug and update BUG=

Updated the bug number to the existing CookieManager bug, which is what this is
for :)

[Torne, 2013-11-01 12:02:25]

+solb for remoting/client/jni/ OWNERS
+darin for mojo/ OWNERS

[Lambros, 2013-11-01 16:18:22]

remoting lgtm

[solb, 2013-11-02 04:32:19]

lgtm

[bulach, 2013-11-04 17:54:50]

lgtm, thanks!

[Torne, 2013-11-05 11:10:50]

darin: ping, need an OWNERS for mojo/

[Torne, 2013-11-07 15:21:06]

jamesr, can I get an OWNERS stamp for mojo/ ? darin seems busy :)

[jamesr, 2013-11-07 17:56:46]

mojo/ lgtm, although the overall change feels a little icky. why can't we keep
track of what's initialized when in a more structured way?

[jamesr, 2013-11-07 17:56:46]

mojo/ lgtm, although the overall change feels a little icky. why can't we keep
track of what's initialized when in a more structured way?

[Torne, 2013-11-07 18:10:19]

On 2013/11/07 17:56:46, jamesr wrote:
> mojo/ lgtm, although the overall change feels a little icky. why can't we keep
> track of what's initialized when in a more structured way?

There's a number of different places in upstream Chromium webview code and in
Android's downstream webview glue code that need to be able to potentially call
into the JNI code without being sure if there's already a context set. The only
other thing I can think of is just having a global boolean, but I don't think
that's actually any better..

If it's any consolation, right now this will never be called more than twice in
non-test configurations, and will typically only be called once. If we find more
places we need to do JNI from this number may increase, but each callsite is
only going to do it a single time.

I'm happy to take alternate suggestions :)

[commit-bot: I haz the power, 2013-11-11 11:09:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/torne@chromium.org/54923002/1

[commit-bot: I haz the power, 2013-11-11 12:00:57]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_clan...

[commit-bot: I haz the power, 2013-11-11 12:36:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/torne@chromium.org/54923002/1

[commit-bot: I haz the power, 2013-11-11 19:03:09]

Retried try job too often on win_rel for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-11-11 20:26:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/torne@chromium.org/54923002/1

[commit-bot: I haz the power, 2013-11-11 20:29:36]

Change committed as 234271