Notification of render process library initialization on android

[Mathias Hällman]

For render processes on android, how do you know when the library is initialized? Afaict only the ChildProcessService is aware, but is there a way to receive a notification elsewhere in Java land of when it's safe to use functionality exposed by chromium? In particular I'd like to use the PathService from Java in a render process when it's safe to do so.

[Anton Vayvod]

I don't think Chromium uses/can use Java in the renderer process. Java only runs in the browser process (except for WebView when the browser and renderer processes are the same).

In the browser process one can use LibraryLoader.isInitialized().

What are you trying to do in the renderer process that requires Java?

On Wed, Feb 25, 2015 at 12:00 PM, Mathias Hällman <math...@opera.com> wrote:

For render processes on android, how do you know when the library is initialized? Afaict only the ChildProcessService is aware, but is there a way to receive a notification elsewhere in Java land of when it's safe to use functionality exposed by chromium? In particular I'd like to use the PathService from Java in a render process when it's safe to do so.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Anton Vayvod]

[Robert Sesek]

Renderers can and do use Java today already, since the are Android services. (However I'd recommend minimizing the use Java in the renderer.) The entrypoint for Android renderers is as you point out the ChildProcessService. This is responsible for loading libchrome.so, and the Java runtime automatically calls JNI_OnLoad when the library is loaded. This function is in chrome_jni_onload.cc and it runs all the generated JNI registration functions and sets up the ContentMain delegate. After this, all JNI is registered and ContentMain.start() is called from ChildProcessService. So I'm not sure I understand your question. It is always safe to use pure Java in the renderers, and you can use any JNI after ContentMain starts running, which is what runs all the renderer startup routines.

rsesek / @chromium.org

[Mathias Hällman]

Right, change some names, that's the process I'm dealing with. But to clarify my question, what I was wondering was how do I know that ContentMain has started running? Say for arguments sake that Service.onTrimMemory is called, how do I know in my subclassed service that it's ok to use Java interfaces from chromium which require native libraries to have been loaded and initialized.

At first glance it seems only ChildProcessService can ever know when this is safe, but now I realize I may have missed an obvious answer: I'll have our content client or some such call up to Java and flag somewhere when it's ok to use chromium.

Is there a better way though? I don't have a chromium checkout here as I've left work long ago, but I recall chromecast on android using PathService in their content client. Paths they've presumably set from Java, but I wasn't able to see that as the code was missing from our internal repositories. Hopefully it is at least publicly accessible upstream. Either way, this is just what we want to do, so if the chromecast people have solved the problem better on android, I'd be happy to hear about it!

[Robert Sesek]

Sorry, your reply somehow got filtered.

Service.onTrimMemory is going to be delivered to the same thread as Service.onCreate. Since onCreate must be called first, it should not be possible to get other messages before that. I.e., ContentMain will always be running after onCreate. But to reiterate, I'd avoid adding any Java to the renderer process if possible.

rsesek / @chromium.org

[Mathias Hällman]

"ContentMain will always be running after onCreate"

This is essentially what my entire problem boils down to, I don't think you can make that assertion. ChildProcessService.onCreate will spawn a thread which will probably start ContentMain "some time", and there's no way of knowing when it's done other than via some client class that will be instantiated as a result of ContentMain actually starting up.

However, I managed to work around the problem without having to rely on ContentMain being up and running.