Update WebAPKs even if the WebAPK start URL has no Web Manifest part 1/3

Update WebAPKs even if the WebAPK start URL has no Web Manifest part 1/3

WebAPKs are updated when either:
- The web developer changes the Web Manifest
OR
- The code in chrome/android/webapk/shell_apk/ is modified to provide new
  features (because of a new version of Chrome)

If a Web Developer removes the WebAPK's Web Manifest from their site, it is
still necessary for the WebAPK to update when the code in
chrome/android/webapk/shell_apk/ changes. Updating a WebAPK in this scenario is
desirable so that users can take advantage of new WebAPK-related features.

This CL:
1) Makes the WebAPK request an update from the WebAPK server with parameters
from the WebAPK's Android manifest if the Web Manifest cannot be fetched.

2)Adds WebApkUpdateManager#onFinishedFetchingWebManifestForInitialUrl() and
WebApkUpdateManager#onGotManifestData()
This CL adds the implementation for
#onFinishedFetchingWebManifestForInitialUrl() but does not add the code which
calls #onFinishedFetchingWebManifestForInitialUrl()

#onFinishedFetchingWebManifestForInitialUrl() will be called after the Web
Manifest is fetched (successfully or unsuccessfully) after the initial page
load. If an update is needed because the code in
chrome/android/webapk/shell_apk/ changed, an update is requested by
#onFinishedFetchingWebManifestForInitialUrl() regardless of whether fetching
the Web Manifest was successful. It is possible that an update is requested
with a stale Web Manifest (because the Web Manifest changed as well) but at
least an update is guaranteed to be requested.

#onGotManifestData() will be called once/if the Web Manifest is fetched
SUCCESSFULLY on a page load after the first page load. The page at the WebAPK's
start_url might not have a Web Manifest but a page linked from the start_url
might have a Web Manifest. For instance, the page at start_url might be a
simple JavaScript redirect. Having #onGotManifestData() enables updating the
WebAPK even if the page at the WebAPK's start_url does not have a Web Manifest.

BUG=639536
TEST=WebApkUpdateManagerTest.*

Committed: https://crrev.com/529d60f1e0addf28fe0a08a9643eb4d04688fb63
Cr-Commit-Position: refs/heads/master@{#428381}

[pkotwicz, 2016-10-21 21:04:29]

Description was changed from

==========
ABCD
==========

to

==========
Update WebAPKs even if the WebAPK start URL has no Web Manifest part 1/3

WebAPKs are updated when either:
- The web developer updates the Web Manifest
- The code in chrome/android/webapk/shell_apk/ is modified to provide new
  features

If a Web Developer removes the WebAPK's Web Manifest from their site, it is
still necessary for the WebAPK to update when the code in
chrome/android/webapk/shell_apk/ changes. So that the user can take advantage of
new WebAPK-related features.

This CL:
1) Makes the WebAPK request an update from the WebAPK server with parameters
from the WebAPK's Android manifest if the Web Manifest cannot be fetched.

2)Adds WebApkUpdateManager#onFinishedFetchingWebManifestForInitialUrl() and
WebApkUpdateManager#onGotManifestData()
This CL adds the implementation for
#onFinishedFetchingWebManifestForInitialUrl() but does not add the code which
calls #onFinishedFetchingWebManifestForInitialUrl()

#onFinishedFetchingWebManifestForInitialUrl() will be called after the Web
Manifest is fetched after the initial page load. If an update is needed because
the code in chrome/android/webapk/shell_apk/ changed, an update is requested by
#onFinishedFetchingWebManifestForInitialUrl() regardless of whether fetching the
Web Manifest was successful. It is possible that an update is requested with a
stale Web Manifest (because the Web Manifest changed as well) but at least an
update is guaranteed to be requested.

3)
==========

[pkotwicz, 2016-10-21 22:05:23]

Patchset #2 (id:20001) has been deleted

[pkotwicz, 2016-10-21 22:20:29]

Description was changed from

==========
Update WebAPKs even if the WebAPK start URL has no Web Manifest part 1/3

WebAPKs are updated when either:
- The web developer updates the Web Manifest
- The code in chrome/android/webapk/shell_apk/ is modified to provide new
  features

If a Web Developer removes the WebAPK's Web Manifest from their site, it is
still necessary for the WebAPK to update when the code in
chrome/android/webapk/shell_apk/ changes. So that the user can take advantage of
new WebAPK-related features.

This CL:
1) Makes the WebAPK request an update from the WebAPK server with parameters
from the WebAPK's Android manifest if the Web Manifest cannot be fetched.

2)Adds WebApkUpdateManager#onFinishedFetchingWebManifestForInitialUrl() and
WebApkUpdateManager#onGotManifestData()
This CL adds the implementation for
#onFinishedFetchingWebManifestForInitialUrl() but does not add the code which
calls #onFinishedFetchingWebManifestForInitialUrl()

#onFinishedFetchingWebManifestForInitialUrl() will be called after the Web
Manifest is fetched after the initial page load. If an update is needed because
the code in chrome/android/webapk/shell_apk/ changed, an update is requested by
#onFinishedFetchingWebManifestForInitialUrl() regardless of whether fetching the
Web Manifest was successful. It is possible that an update is requested with a
stale Web Manifest (because the Web Manifest changed as well) but at least an
update is guaranteed to be requested.

3)
==========

to

==========
Update WebAPKs even if the WebAPK start URL has no Web Manifest part 1/3

WebAPKs are updated when either:
- The web developer changes the Web Manifest
OR
- The code in chrome/android/webapk/shell_apk/ is modified to provide new
  features (because of a new version of Chrome)

If a Web Developer removes the WebAPK's Web Manifest from their site, it is
still necessary for the WebAPK to update when the code in
chrome/android/webapk/shell_apk/ changes. Updating a WebAPK in this scenario is
desirable so that users can take advantage of new WebAPK-related features.

This CL:
1) Makes the WebAPK request an update from the WebAPK server with parameters
from the WebAPK's Android manifest if the Web Manifest cannot be fetched.

2)Adds WebApkUpdateManager#onFinishedFetchingWebManifestForInitialUrl() and
WebApkUpdateManager#onGotManifestData()
This CL adds the implementation for
#onFinishedFetchingWebManifestForInitialUrl() but does not add the code which
calls #onFinishedFetchingWebManifestForInitialUrl()

#onFinishedFetchingWebManifestForInitialUrl() will be called after the Web
Manifest is fetched (successfully or unsuccessfully) after the initial page
load. If an update is needed because the code in
chrome/android/webapk/shell_apk/ changed, an update is requested by
#onFinishedFetchingWebManifestForInitialUrl() regardless of whether fetching
the Web Manifest was successful. It is possible that an update is requested
with a stale Web Manifest (because the Web Manifest changed as well) but at
least an update is guaranteed to be requested.

#onGotManifestData() will be called once/if the Web Manifest is fetched
SUCCESSFULLY on a page load after the first page load. The page at the WebAPK's
start_url might not have a Web Manifest but a page linked from the start_url
might have a Web Manifest. For instance, the page at start_url might be a
simple JavaScript redirect. Having #onGotManifestData() enables updating the
WebAPK even if the page at the WebAPK's start_url does not have a Web Manifest.

BUG=639536
TEST=WebApkUpdateManagerTest.*
==========

[pkotwicz, 2016-10-21 22:20:30]

pkotwicz@chromium.org changed reviewers:
+ dominickn@chromium.org

[pkotwicz, 2016-10-21 22:20:48]

Dominick, can you please take a look?

[pkotwicz, 2016-10-21 22:20:48]

Dominick, can you please take a look?

[pkotwicz, 2016-10-21 22:28:00]

Patchset #2 (id:40001) has been deleted

[pkotwicz, 2016-10-21 22:28:20]

Patchset #1 (id:1) has been deleted

[dominickn, 2016-10-24 11:34:59]

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/ManifestUpgradeDetector.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/ManifestUpgradeDetector.java:26:
* @param data The fetched Web Manifest data. Null if the initial URL does not
point to a
Nit: align "Whether" and "The" on the param lines to make reading this easier.

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java:11:
public int shellApkVersion;
There are now a lot of very similar classes flying around - WebappInfo,
WebappDataStorage, the FetchedManifestData - as well as the field properties in
a bunch of classes and the Android Manifest and now this class. I'm starting to
get concerned about all of the duplication, particularly since all of these
classes carry some sub/super-set of the other classes' information. It's getting
difficult to keep up with them all.

Lots of classes with very similar pieces of information is a bit of an
anti-pattern. At the very least, can we make the FetchedManifestData use the
same class as this?

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java:64:
if (mMetaData == null) {
Nit: inline the return.

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java:85:
public void destroy() {
Can you just override this method in tests, and call destroy() everywhere rather
than having the separate destroyUpgradeDetector() method? Just looking at it,
destroy() is only called in WebApkActivity, and that shouldn't happen in
WebApkUpdateManagerTest so it would be safe just to merge it with
destroyUpgradeDetector(). Let me know if I'm being blind though.

[pkotwicz, 2016-10-24 16:03:43]

Dominick, can you please take another look?

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java:11:
public int shellApkVersion;
In a follow up CL, I can merge this class with FetchedManifestData.

We would need to find a good name for this "shared class". WebApkMetaData is a
bad name because ManifestUpgradeDetectorFetcher does not fetch the <meta-data>
from the Android Manifest.

WebApkData perhaps?

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java:85:
public void destroy() {
I made destroyUpgradeDetector() its own function to make the code more
intuitive.

When destroyUpgradeDetector() is called from
onFinishedFetchingWebManifestForInitialUrl() the entire class is not being
destroyed. updateAsync() and onBuiltWebApk() can be called after
destroyUpgradeDetector() is invoked.

Although destroy() and destroyUpgradeDetector() do the same thing, their
semantic meaning is different:
destroy() destroys the entire class
destroyUpgradeDetector() destroys {@link mUpgradeDetector}

[dominickn, 2016-10-25 07:39:16]

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java:11:
public int shellApkVersion;
On 2016/10/24 16:03:43, pkotwicz wrote:
> In a follow up CL, I can merge this class with FetchedManifestData.
> 
> We would need to find a good name for this "shared class". WebApkMetaData is a
> bad name because ManifestUpgradeDetectorFetcher does not fetch the <meta-data>
> from the Android Manifest.
> 
> WebApkData perhaps?

What about WebApkInfo? That means it mirrors WebappInfo. We could even go to the
point of having a common subclass which contains the information which is shared
between WebappInfo and WebApkInfo. Then WebappInfo/WebApkInfo extend that class
and add whatever custom fields they need (many more in WebApkInfo!). Thoughts?

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java:85:
public void destroy() {
On 2016/10/24 16:03:43, pkotwicz wrote:
> I made destroyUpgradeDetector() its own function to make the code more
> intuitive.
> 
> When destroyUpgradeDetector() is called from
> onFinishedFetchingWebManifestForInitialUrl() the entire class is not being
> destroyed. updateAsync() and onBuiltWebApk() can be called after
> destroyUpgradeDetector() is invoked.
> 
> Although destroy() and destroyUpgradeDetector() do the same thing, their
> semantic meaning is different:
> destroy() destroys the entire class
> destroyUpgradeDetector() destroys {@link mUpgradeDetector}

The semantic difference doesn't really make sense to me (WebApkActivity never
sets mUpdateManager to null, so it holds a reference to the WebApkUpdateManager
for the whole time, and destroy() is only called when the activity is stopping).
I don't really want to stop the CL on this though.

https://codereview.chromium.org/2435383002/diff/100001/chrome/android/java/sr...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
(right):

https://codereview.chromium.org/2435383002/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java:11:
public int shellApkVersion;
Having all the fields public and no constructor forces this class to be default
constructed and then all the fields are filled in. That's how
FetchedManifestData works. But if you take up my suggestion of having a common
base class between WebappInfo and WebApkInfo, maybe this should be a standard
Java class with private members, a constructor, and getters? It could even have
static Create methods, e.g. createWebappInfoFromWebApk could move its
implementation into here in your follow up. What are your thoughts on the common
base class?

https://codereview.chromium.org/2435383002/diff/100001/chrome/android/java/sr...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaDataUtils.java
(right):

https://codereview.chromium.org/2435383002/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaDataUtils.java:55:
* Populates {@link WebApkMetaData} with meta data extracted from WebAPK.
Nit: specify it's from the WebAPK package app info.

https://codereview.chromium.org/2435383002/diff/100001/chrome/android/junit/s...
File
chrome/android/junit/src/org/chromium/chrome/browser/webapps/ManifestUpgradeDetectorTest.java
(right):

https://codereview.chromium.org/2435383002/diff/100001/chrome/android/junit/s...
chrome/android/junit/src/org/chromium/chrome/browser/webapps/ManifestUpgradeDetectorTest.java:183:
WebappInfo webappInfo = WebappInfo.create("", oldData.startUrl,
oldData.scopeUrl, null,
Are you using this WebappInfo?

[pkotwicz, 2016-10-26 01:48:29]

Patchset #4 (id:120001) has been deleted

[pkotwicz, 2016-10-26 01:53:29]

Dominick, can you please take another look?

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java:11:
public int shellApkVersion;
WebApkInfo sounds good.

I am hesitant to make WebApkInfo extend WebappInfo. I don't foresee a WebApkInfo
implementation for WebApkInfo#setWebappIntentExtras().

Making WebApkInfo extend WebappInfo would be an easier decision if WebappInfo
were not used in WebappLauncherActivity

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java:85:
public void destroy() {
I think that the semantic difference makes sense if you think of the user of
WebApkUpdateManager as a black box and treat WebApkUpdateManager#destroy() as a
public API

https://codereview.chromium.org/2435383002/diff/100001/chrome/android/java/sr...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaDataUtils.java
(right):

https://codereview.chromium.org/2435383002/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaDataUtils.java:55:
* Populates {@link WebApkMetaData} with meta data extracted from WebAPK.
I specified that the meta data is extracted from the WebAPK's Android Manifest.
I think that makes things clearer.

https://codereview.chromium.org/2435383002/diff/100001/chrome/android/junit/s...
File
chrome/android/junit/src/org/chromium/chrome/browser/webapps/ManifestUpgradeDetectorTest.java
(right):

https://codereview.chromium.org/2435383002/diff/100001/chrome/android/junit/s...
chrome/android/junit/src/org/chromium/chrome/browser/webapps/ManifestUpgradeDetectorTest.java:183:
WebappInfo webappInfo = WebappInfo.create("", oldData.startUrl,
oldData.scopeUrl, null,
I am not using it. Removed it

[dominickn, 2016-10-26 02:04:56]

Can you please do a CQ dry run before I lg?

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java:11:
public int shellApkVersion;
On 2016/10/26 01:53:29, pkotwicz wrote:
> WebApkInfo sounds good.
> 
> I am hesitant to make WebApkInfo extend WebappInfo. I don't foresee a
WebApkInfo
> implementation for WebApkInfo#setWebappIntentExtras().
> 
> Making WebApkInfo extend WebappInfo would be an easier decision if WebappInfo
> were not used in WebappLauncherActivity

You misunderstood me. I suggested having:

class WebappCommonInfo

class WebappInfo extends WebappCommonInfo

class WebApkInfo extends WebappCommonInfo

I agree that it doesn't make sense for WebApkInfo to extend WebappInfo. But both
can extend a common base class because so many of the fields are the same.
That's why I suggested making the fields private in this class and using
getters, because that's probably what you should have if you implement a common
base class (the base class will have protected fields).

https://codereview.chromium.org/2435383002/diff/140001/chrome/android/junit/s...
File
chrome/android/junit/src/org/chromium/chrome/browser/webapps/ManifestUpgradeDetectorTest.java
(right):

https://codereview.chromium.org/2435383002/diff/140001/chrome/android/junit/s...
chrome/android/junit/src/org/chromium/chrome/browser/webapps/ManifestUpgradeDetectorTest.java:227:
oldData.scopeUrl = ShortcutHelper.getScopeFromUrl(oldData.startUrl);
Was this meant to be reverted back to the original? ps1 , ps2, and ps3 all set
this to the empty string so webapk_installer.cc would use the default scope? Or
is startUrl guaranteed to be empty here?

[pkotwicz, 2016-10-26 03:57:01]

Dominick, can you please take another look?

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java:11:
public int shellApkVersion;
That proposal sounds reasonable. I will do it in a follow up CL though

https://codereview.chromium.org/2435383002/diff/140001/chrome/android/junit/s...
File
chrome/android/junit/src/org/chromium/chrome/browser/webapps/ManifestUpgradeDetectorTest.java
(right):

https://codereview.chromium.org/2435383002/diff/140001/chrome/android/junit/s...
chrome/android/junit/src/org/chromium/chrome/browser/webapps/ManifestUpgradeDetectorTest.java:227:
oldData.scopeUrl = ShortcutHelper.getScopeFromUrl(oldData.startUrl);
Yes, I reverted this intentionally. webapk_installer.cc uses the default scope

[dominickn, 2016-10-26 06:04:34]

The CQ bit was checked by dominickn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 06:05:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-26 06:07:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-26 06:07:23]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[dominickn, 2016-10-27 00:42:48]

lgtm - you should look into setting up dependent CLs in your branch structure
like I suggested in crrev.com/2441203002, that will make running tryjobs much
easier.

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
(right):

https://codereview.chromium.org/2435383002/diff/80001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java:11:
public int shellApkVersion;
On 2016/10/26 03:57:01, pkotwicz wrote:
> That proposal sounds reasonable. I will do it in a follow up CL though

Great, thanks! It will help clean up a bunch of things.

[pkotwicz, 2016-10-27 17:33:50]

pkotwicz@chromium.org changed reviewers:
+ dfalcantara@chromium.org

[pkotwicz, 2016-10-27 17:33:51]

dfalcantara@ for change to WebApkMetaDataUtils.java

[gone, 2016-10-27 17:40:12]

That file OWNERS lgtm

[pkotwicz, 2016-10-28 00:45:13]

The CQ bit was checked by pkotwicz@chromium.org

[pkotwicz, 2016-10-28 00:45:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
dominickn@chromium.org, dfalcantara@chromium.org
Link to the patchset: https://codereview.chromium.org/2435383002/#ps180001
(title: "Merge branch 'master' into update_fail0")

[commit-bot: I haz the power, 2016-10-28 00:45:34]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-28 00:54:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 00:54:11]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[pkotwicz, 2016-10-28 01:45:29]

The CQ bit was checked by pkotwicz@chromium.org

[pkotwicz, 2016-10-28 01:45:29]

The patchset sent to the CQ was uploaded after l-g-t-m from
dominickn@chromium.org, dfalcantara@chromium.org
Link to the patchset: https://codereview.chromium.org/2435383002/#ps200001
(title: "Merge branch 'master' into update_fail0")

[commit-bot: I haz the power, 2016-10-28 01:45:50]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-28 03:01:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 03:01:15]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[pkotwicz, 2016-10-28 14:17:42]

The CQ bit was checked by pkotwicz@chromium.org

[commit-bot: I haz the power, 2016-10-28 14:18:07]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-28 15:37:16]

Description was changed from

==========
Update WebAPKs even if the WebAPK start URL has no Web Manifest part 1/3

WebAPKs are updated when either:
- The web developer changes the Web Manifest
OR
- The code in chrome/android/webapk/shell_apk/ is modified to provide new
  features (because of a new version of Chrome)

If a Web Developer removes the WebAPK's Web Manifest from their site, it is
still necessary for the WebAPK to update when the code in
chrome/android/webapk/shell_apk/ changes. Updating a WebAPK in this scenario is
desirable so that users can take advantage of new WebAPK-related features.

This CL:
1) Makes the WebAPK request an update from the WebAPK server with parameters
from the WebAPK's Android manifest if the Web Manifest cannot be fetched.

2)Adds WebApkUpdateManager#onFinishedFetchingWebManifestForInitialUrl() and
WebApkUpdateManager#onGotManifestData()
This CL adds the implementation for
#onFinishedFetchingWebManifestForInitialUrl() but does not add the code which
calls #onFinishedFetchingWebManifestForInitialUrl()

#onFinishedFetchingWebManifestForInitialUrl() will be called after the Web
Manifest is fetched (successfully or unsuccessfully) after the initial page
load. If an update is needed because the code in
chrome/android/webapk/shell_apk/ changed, an update is requested by
#onFinishedFetchingWebManifestForInitialUrl() regardless of whether fetching
the Web Manifest was successful. It is possible that an update is requested
with a stale Web Manifest (because the Web Manifest changed as well) but at
least an update is guaranteed to be requested.

#onGotManifestData() will be called once/if the Web Manifest is fetched
SUCCESSFULLY on a page load after the first page load. The page at the WebAPK's
start_url might not have a Web Manifest but a page linked from the start_url
might have a Web Manifest. For instance, the page at start_url might be a
simple JavaScript redirect. Having #onGotManifestData() enables updating the
WebAPK even if the page at the WebAPK's start_url does not have a Web Manifest.

BUG=639536
TEST=WebApkUpdateManagerTest.*
==========

to

==========
Update WebAPKs even if the WebAPK start URL has no Web Manifest part 1/3

WebAPKs are updated when either:
- The web developer changes the Web Manifest
OR
- The code in chrome/android/webapk/shell_apk/ is modified to provide new
  features (because of a new version of Chrome)

If a Web Developer removes the WebAPK's Web Manifest from their site, it is
still necessary for the WebAPK to update when the code in
chrome/android/webapk/shell_apk/ changes. Updating a WebAPK in this scenario is
desirable so that users can take advantage of new WebAPK-related features.

This CL:
1) Makes the WebAPK request an update from the WebAPK server with parameters
from the WebAPK's Android manifest if the Web Manifest cannot be fetched.

2)Adds WebApkUpdateManager#onFinishedFetchingWebManifestForInitialUrl() and
WebApkUpdateManager#onGotManifestData()
This CL adds the implementation for
#onFinishedFetchingWebManifestForInitialUrl() but does not add the code which
calls #onFinishedFetchingWebManifestForInitialUrl()

#onFinishedFetchingWebManifestForInitialUrl() will be called after the Web
Manifest is fetched (successfully or unsuccessfully) after the initial page
load. If an update is needed because the code in
chrome/android/webapk/shell_apk/ changed, an update is requested by
#onFinishedFetchingWebManifestForInitialUrl() regardless of whether fetching
the Web Manifest was successful. It is possible that an update is requested
with a stale Web Manifest (because the Web Manifest changed as well) but at
least an update is guaranteed to be requested.

#onGotManifestData() will be called once/if the Web Manifest is fetched
SUCCESSFULLY on a page load after the first page load. The page at the WebAPK's
start_url might not have a Web Manifest but a page linked from the start_url
might have a Web Manifest. For instance, the page at start_url might be a
simple JavaScript redirect. Having #onGotManifestData() enables updating the
WebAPK even if the page at the WebAPK's start_url does not have a Web Manifest.

BUG=639536
TEST=WebApkUpdateManagerTest.*
==========

[commit-bot: I haz the power, 2016-10-28 15:37:17]

Committed patchset #7 (id:200001)

[commit-bot: I haz the power, 2016-10-28 15:49:08]

Description was changed from

==========
Update WebAPKs even if the WebAPK start URL has no Web Manifest part 1/3

WebAPKs are updated when either:
- The web developer changes the Web Manifest
OR
- The code in chrome/android/webapk/shell_apk/ is modified to provide new
  features (because of a new version of Chrome)

If a Web Developer removes the WebAPK's Web Manifest from their site, it is
still necessary for the WebAPK to update when the code in
chrome/android/webapk/shell_apk/ changes. Updating a WebAPK in this scenario is
desirable so that users can take advantage of new WebAPK-related features.

This CL:
1) Makes the WebAPK request an update from the WebAPK server with parameters
from the WebAPK's Android manifest if the Web Manifest cannot be fetched.

2)Adds WebApkUpdateManager#onFinishedFetchingWebManifestForInitialUrl() and
WebApkUpdateManager#onGotManifestData()
This CL adds the implementation for
#onFinishedFetchingWebManifestForInitialUrl() but does not add the code which
calls #onFinishedFetchingWebManifestForInitialUrl()

#onFinishedFetchingWebManifestForInitialUrl() will be called after the Web
Manifest is fetched (successfully or unsuccessfully) after the initial page
load. If an update is needed because the code in
chrome/android/webapk/shell_apk/ changed, an update is requested by
#onFinishedFetchingWebManifestForInitialUrl() regardless of whether fetching
the Web Manifest was successful. It is possible that an update is requested
with a stale Web Manifest (because the Web Manifest changed as well) but at
least an update is guaranteed to be requested.

#onGotManifestData() will be called once/if the Web Manifest is fetched
SUCCESSFULLY on a page load after the first page load. The page at the WebAPK's
start_url might not have a Web Manifest but a page linked from the start_url
might have a Web Manifest. For instance, the page at start_url might be a
simple JavaScript redirect. Having #onGotManifestData() enables updating the
WebAPK even if the page at the WebAPK's start_url does not have a Web Manifest.

BUG=639536
TEST=WebApkUpdateManagerTest.*
==========

to

==========
Update WebAPKs even if the WebAPK start URL has no Web Manifest part 1/3

WebAPKs are updated when either:
- The web developer changes the Web Manifest
OR
- The code in chrome/android/webapk/shell_apk/ is modified to provide new
  features (because of a new version of Chrome)

If a Web Developer removes the WebAPK's Web Manifest from their site, it is
still necessary for the WebAPK to update when the code in
chrome/android/webapk/shell_apk/ changes. Updating a WebAPK in this scenario is
desirable so that users can take advantage of new WebAPK-related features.

This CL:
1) Makes the WebAPK request an update from the WebAPK server with parameters
from the WebAPK's Android manifest if the Web Manifest cannot be fetched.

2)Adds WebApkUpdateManager#onFinishedFetchingWebManifestForInitialUrl() and
WebApkUpdateManager#onGotManifestData()
This CL adds the implementation for
#onFinishedFetchingWebManifestForInitialUrl() but does not add the code which
calls #onFinishedFetchingWebManifestForInitialUrl()

#onFinishedFetchingWebManifestForInitialUrl() will be called after the Web
Manifest is fetched (successfully or unsuccessfully) after the initial page
load. If an update is needed because the code in
chrome/android/webapk/shell_apk/ changed, an update is requested by
#onFinishedFetchingWebManifestForInitialUrl() regardless of whether fetching
the Web Manifest was successful. It is possible that an update is requested
with a stale Web Manifest (because the Web Manifest changed as well) but at
least an update is guaranteed to be requested.

#onGotManifestData() will be called once/if the Web Manifest is fetched
SUCCESSFULLY on a page load after the first page load. The page at the WebAPK's
start_url might not have a Web Manifest but a page linked from the start_url
might have a Web Manifest. For instance, the page at start_url might be a
simple JavaScript redirect. Having #onGotManifestData() enables updating the
WebAPK even if the page at the WebAPK's start_url does not have a Web Manifest.

BUG=639536
TEST=WebApkUpdateManagerTest.*

Committed: https://crrev.com/529d60f1e0addf28fe0a08a9643eb4d04688fb63
Cr-Commit-Position: refs/heads/master@{#428381}
==========

[commit-bot: I haz the power, 2016-10-28 15:49:10]

Patchset 7 (id:??) landed as
https://crrev.com/529d60f1e0addf28fe0a08a9643eb4d04688fb63
Cr-Commit-Position: refs/heads/master@{#428381}