Add calls to the server to request WebAPK updates.

chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkActivity.java

Index: chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkActivity.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkActivity.java b/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkActivity.java
index 7c4a070defd51917c2f13376bbf5e96ed1f2895e..b89b1a53f86c35991c63551c574eda13789a7581 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkActivity.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkActivity.java
@@ -154,7 +154,7 @@ public class WebApkActivity extends WebappActivity {
             mManifestUpgradeDetector =
                     new ManifestUpgradeDetector(getActivityTab(), mWebappInfo);
         }
-        mManifestUpgradeDetector.start();
+        WebApkUpdateManager.checkUpdate(mWebappInfo.id(), mManifestUpgradeDetector);

[pkotwicz, 2016/08/03 19:09:34]

It is kind of weird that WebApkActivity owns an instance of
ManifestUpgradeDetector and that WebApkUpdateManager is static.
I think that it would make more sense if WebApkUpdateManager were not static and
owned the ManifestUpgradeDetector.

Currently, WebApkUpdateManager and ManifestUpgradeDetector are simple enough
that they can be merged (especially with
https://codereview.chromium.org/2161163004/). It is possible that
WebApkUpdateManager will become more complicated in the future. (I am ok if we
keep the WebApkUpdateManager and ManifestUpgradeDetector split. I am trying to
express my thought process)

[Xi Han, 2016/08/03 20:22:46]

As discussed offline, we keep the code as it is now, since static functions make
JNI calls easier.

     }
 
     @Override