Add a chrome://webapks page.

chrome/browser/android/webapps/webapp_registry.cc

 // Copyright 2015 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.
 
 #include "chrome/browser/android/webapps/webapp_registry.h"
 
 #include "base/android/jni_android.h"
 #include "chrome/browser/android/browsing_data/url_filter_bridge.h"
+#include "chrome/browser/ui/webui/webapk_info_callback.h"
 #include "jni/WebappRegistry_jni.h"
 
 using base::android::JavaParamRef;
 
 void WebappRegistry::UnregisterWebappsForUrls(
     const base::Callback<bool(const GURL&)>& url_filter) {
   // |filter_bridge| is destroyed from its Java counterpart.
   UrlFilterBridge* filter_bridge = new UrlFilterBridge(url_filter);
 
   Java_WebappRegistry_unregisterWebappsForUrls(
       base::android::AttachCurrentThread(), filter_bridge->j_bridge());
 }
 
 void WebappRegistry::ClearWebappHistoryForUrls(
     const base::Callback<bool(const GURL&)>& url_filter) {
   // |filter_bridge| is destroyed from its Java counterpart.
   UrlFilterBridge* filter_bridge = new UrlFilterBridge(url_filter);
 
   Java_WebappRegistry_clearWebappHistoryForUrls(
       base::android::AttachCurrentThread(), filter_bridge->j_bridge());
 }
+
+void WebappRegistry::ListWebAPKs(
+    const base::RepeatingCallback<void(std::string, std::string, int, int)>&
+        callback) {

[pkotwicz, 2017/01/13 17:00:58]

I think that it would be clearer if this function returned an array.
We do something similar in WebApkUpdateManager#updateAsync()

Yes converting to an array is suboptimal, but:
- There is likely going to be 1 or 2 installed WebAPKs
- PackageManager#getInstalledPackages() is slow.
- The chrome://webapk page should be rarely shown.

[gonzalon, 2017/01/13 20:24:39]

Returning an array was my first approach too, it would make the whole thing much
clearer, but I don't know how to do that here. I looked at
WebApkUpdateManager#updateAsync() but that method only returns one WebAPK, not
many. I'd have to return a list of objects that have several fields, but when I
asked I was told that's not possible with JNI as we use it here, maybe I'm
mistaken. Could you clarify how to do this?

[pkotwicz, 2017/01/17 03:20:16]

I recommend doing this by making WebappRegistry::ListWebApks() call
WebappRegistry::ListWebAPKsInternal(const
base::Callback<void(std::vector<std::string>,
                                                             
std::vector<std::string>,
                                                              std::vector<int>,
                                                             
std::vector<int>)>& callback)

To get an array of objects from C++ to Java you can use the technique used by
BookmarkBridge::GetBookmarksForFolder(). I don't recommend using this technique
to get an array of objects from Java to C++ because it would require way too
many JNI calls

[gonzalon, 2017/01/17 16:45:17]

I did something very similar to what you recommended, only instead of returning
separate lists for each field I just created a wrapper struct with all of them.
I think this makes it less error prone, but let me know what you think.

+  WebapkInfoCallback* webapk_info_callback = new WebapkInfoCallback(callback);

[Xi Han, 2017/01/13 15:50:15]

Please add a comment that the WebApkInfoCallback will delete itself after it is
done.

"WebapkInfoCallback" -> "WebApkInfoCallback" with capital A.

We have naming conventions discussions for WebAPK when we began to checkin code
to Chromium, and now we all follow the following pattern:
1) in comments (c++/Java/documentation): use WebAPK
2) in code like function/parameter name, use WebApk
3) in c++ file name: webapk_installer.h (.cc)

My apology that I didn't mention it before:(

[gonzalon, 2017/01/13 20:24:39]

Good to know! Thanks for explaining.

+
+  Java_WebappRegistry_listWebAPKs(
+      base::android::AttachCurrentThread(),
+      webapk_info_callback->j_webapk_info_callback());

[Xi Han, 2017/01/13 15:50:15]

It is better to move this JNI call into WebApkInfoCallback, so we don't need to
expose the Java pointer to the caller.

+}