Add Android implementation of navigator.getInstalledRelatedApps.

content/public/android/java/src/org/chromium/content/browser/installedapp/InstalledAppProviderFactory.java

+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package org.chromium.content.browser.installedapp;
+
+import org.chromium.content.browser.ContentViewCore;
+import org.chromium.content_public.browser.RenderFrameHost;
+import org.chromium.content_public.browser.WebContentsStatics;
+import org.chromium.installedapp.mojom.InstalledAppProvider;
+import org.chromium.services.service_manager.InterfaceFactory;
+
+/** Factory to create instances of the InstalledAppProvider Mojo service. */
+public class InstalledAppProviderFactory implements InterfaceFactory<InstalledAppProvider> {
+    private final RenderFrameHost mRenderFrameHost;
+
+    public InstalledAppProviderFactory(RenderFrameHost renderFrameHost) {
+        mRenderFrameHost = renderFrameHost;
+    }
+
+    @Override
+    public InstalledAppProvider createImpl() {
+        // Get Android application context from web contents.
+        ContentViewCore contentViewCore = ContentViewCore.fromWebContents(
+                WebContentsStatics.fromRenderFrameHost(mRenderFrameHost));
+        if (contentViewCore == null) {
+            return null;
+        }
+
+        String pageUrl = mRenderFrameHost.getLastCommittedURL();

[boliu, 2017/03/17 18:02:55]

hmm, can the RFH navigate? in which case, caching the url is probably no a good
idea?

[Matt Giuca, 2017/03/20 06:31:56]

I don't think so; I logged this code path and it gets called every time I
navigate (even when simply clicking a link on the same domain), and the
filterInstalledApps call seems to always have the correct URL even after a
navigation.

[boliu, 2017/03/20 16:56:20]

I don't think that testing is good enough here.

nasko@ can probably answer this question definitively. But I think RenderFrames
only gets re-used if we run out of renderer processes; but even then they can
just be different RenderFrames in the same process, so not sure. otoh, methods
like GetLastCommittedURL kinda suggest RFH can navigate.

[Matt Giuca, 2017/03/21 04:16:13]

Ah, you're right.

https://cs.chromium.org/chromium/src/content/browser/frame_host/navigator_imp...
suggests that navigation of both the URL and origin is possible (though it's not
clear whether changing the origin ever happens in practice; sammc@ suggested
that it will never navigate the origin but I don't think we should rely on
that).

I've rewritten the interface so it takes a RenderFrameHost, and calls
getLastCommittedURL on each request.

However, I wrapped it in an interface so that it can be faked for testing, and
added a test of dynamically changing the URL while the service is open. Note: I
could've just implemented a fake RenderFrameHost subclass (instead of making my
own wrapper interface) but I figure that people will want to add new methods to
RenderFrameHost and I don't want to have to keep updating this fake with null
stubs, so this works best.

Thanks for spotting this.

[dcheng, 2017/03/21 07:19:42]

A RenderFrameHost is tied to a specific process ID + frame routing ID. If either
of those changes, you'll get a new RFH. Otherwise, you get the original RFH.

It is quite common for a RFH's last committed origin and URL to change:
renderer-initiated navigations generally do not result in a process swap today,
which means both the last committed origin and the URL will change.

(You can test this by navigating to your favorite aggregator site and then
clicking an outbound cross-origin link. Generally, the tab will still remain in
the same process)

+nasko, do we have any documentation for this somewhere? It's pretty subtle,
hard to understand, and will likely change as we continue with the site
isolation work =)

+        return new InstalledAppProviderImpl(pageUrl, contentViewCore.getContext());

[boliu, 2017/03/17 18:02:55]

this is the application context in chrome iirc, is that the expected one here?
if yes, can just get it from ContextUtils?

[Matt Giuca, 2017/03/20 06:31:56]

Done. Cool idea, that simplifies the code (I am pretty sure it's all the same
context, because it's just used to get the global Android packagemanager).

Note that I can't just delete this parameter and call
ContextUtils.getApplicationContext() from inside InstalledAppProviderImpl,
because for testing we need to be able to pass a fake application context in
there.

+    }
+}