[chromium-discuss] WebAPK upgrade on changing Web App Manifest params doesn't work

[Abhishek Ghosh]

Hello,

In Paul Kinlan's article on "Improved" Add-to-Homescreen
( https://developers.google.com/web/updates/2017/02/improved-add-to-home-screen
), it says that as an update to the icon/name of the web app as defined in

You now have the ability to update your Progressive Web App's icon and

name and have it reflected to the user. Changing your icon or name in the
manifest will update the icon on the home screen after the user has
subsequently opened the site.

As a web site developer, I've tried to understand and emulate this process
but with no success yet. No matter how much I keep changing my web app
manifest's parameters, open the website (that fetches this new manifest as
verified from Dev Tools) both from the installed WebAPK icon or the Chrome
browser, put it in background (it's understandable how a WebAPK upgrade may
not happen if the app is in foreground) and so on, I have never been able
to trigger a WebAPK upgrade - I've waited for days, tried both with same
and changing manifest urls.

As a website owner, this worries me a lot to enable A2HS behaviour on a
website I may own - How can I get my users move on to the new experience
(name, icon, theme and so on) of my installed web app? If WebAPKs do not
upgrade automatically, it's pretty much a dead end because we can't have
any other website/service with our web-app listings to go and upgrade from
(such as a play store or app store) as painful as that may be; as well as
the website from Chrome's context menu (3-dot menu) now just says "Open in
<WebAPK>" rather than something like "Add to Homescreen" which means a
force-upgrade trigger from the user's end is also a no-go. The only
possibility is a user explicitly uninstalling the app and re-installing
using "Add to Homescreen" manually, which is extremely painful and unlikely
to be done by most users.

From some documentation across the web (and from my really limited
understanding of browsing through parts of Chromium source code), looks
like there is supposed to be this WebAPK "auto-upgrade" path but due to
whatever reasons I'm not able to test or trigger it. As a developer, how do
I test out this WebAPK upgrade path? What am I missing?

I've tried reaching out through other channels (Comments on
developer.google.com or Medium, questions on StackOverflow etc. to see if
there's anyone else facing this as well, sadly to no avail.) Hoping someone
can help me out here!

Thank you,
Abhishek

[Glenn Hartmann]

Hi!

I work on the WebAPKs team, hopefully I can help you out a bit.

This auto-update feature is implemented and enabled, so as far as I'm
aware, based on the description you gave, you *should* be getting updates.
One thing to note is that in some cases it can take up to 3 days for the
update logic to trigger - I'm not sure how long you've tried waiting before.

If the 3-day waiting period is not the issue, then it is possible that we
have a bug. Although we do have tests that cover this logic, it could be
that you've run into some edge case that we're not aware of.

One thing I can do to try to help you is to check server logs to see if
your update request is making it to us, or if it's maybe a client-side
issue preventing it from being sent in the first place.

In order to do this, however, I'll need the manifest URL of the site you're
testing on (it helps if this is a rather unique URL - something like
"localhost:8080/index.html" might not help us much).

-Glenn

Post by Abhishek Ghosh
Hello,
In Paul Kinlan's article on "Improved" Add-to-Homescreen (
https://developers.google.com/web/updates/2017/02/improved-add-to-home-screen
), it says that as an update to the icon/name of the web app as defined in

You now have the ability to update your Progressive Web App's icon

and name and have it reflected to the user. Changing your icon or name in
the manifest will update the icon on the home screen after the user has
subsequently opened the site.
As a web site developer, I've tried to understand and emulate this process
but with no success yet. No matter how much I keep changing my web app
manifest's parameters, open the website (that fetches this new manifest as
verified from Dev Tools) both from the installed WebAPK icon or the Chrome
browser, put it in background (it's understandable how a WebAPK upgrade may
not happen if the app is in foreground) and so on, I have never been able
to trigger a WebAPK upgrade - I've waited for days, tried both with same
and changing manifest urls.
As a website owner, this worries me a lot to enable A2HS behaviour on a
website I may own - How can I get my users move on to the new experience
(name, icon, theme and so on) of my installed web app? If WebAPKs do not
upgrade automatically, it's pretty much a dead end because we can't have
any other website/service with our web-app listings to go and upgrade from
(such as a play store or app store) as painful as that may be; as well as
the website from Chrome's context menu (3-dot menu) now just says "Open in
<WebAPK>" rather than something like "Add to Homescreen" which means a
force-upgrade trigger from the user's end is also a no-go. The only
possibility is a user explicitly uninstalling the app and re-installing
using "Add to Homescreen" manually, which is extremely painful and unlikely
to be done by most users.
From some documentation across the web (and from my really limited
understanding of browsing through parts of Chromium source code), looks
like there is supposed to be this WebAPK "auto-upgrade" path but due to
whatever reasons I'm not able to test or trigger it. As a developer, how do
I test out this WebAPK upgrade path? What am I missing?
I've tried reaching out through other channels (Comments on
developer.google.com or Medium, questions on StackOverflow etc. to see if
there's anyone else facing this as well, sadly to no avail.) Hoping someone
can help me out here!
Thank you,
Abhishek
--
--
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Abhishek Ghosh]

Hello Glen,

Really appreciate you helping out!

Over time I've tried getting updates and waited which has been for more
than 3 days for multiple attempts I'd have made. I've been trying my
experiments on a https://inpwatest1.firebaseapp.com (manifest URL is https://inpwatest1.firebaseapp.com/manifest.webmanifest
) if that helps. It'd be really great if you can help me out from some
information (through logs on your side or otherwise) or any potential
reasons why I might not be ever getting updation triggered on my installed
WebAPK, or anything else I can do from my side to help.

Regarding the 3-day wait for triggering an update flow, for testing it
looks quite painful for web app builders... Is there any advice or
recommendation from your end in terms of how web app developers can test
such update flows out much more easily? I'd also imagine that as developers
of the Chromium platform a 3-day wouldn't be the testing mechanism... Is
there possibly some configuration I can set on the browser (or some build
variant of it we can get access to) to make things easier for testing
WebAPK updates?

Thanks,
Abhishek

Post by Glenn Hartmann
Hi!
I work on the WebAPKs team, hopefully I can help you out a bit.
This auto-update feature is implemented and enabled, so as far as I'm
aware, based on the description you gave, you *should* be getting
updates. One thing to note is that in some cases it can take up to 3 days
for the update logic to trigger - I'm not sure how long you've tried
waiting before.
If the 3-day waiting period is not the issue, then it is possible that we
have a bug. Although we do have tests that cover this logic, it could be
that you've run into some edge case that we're not aware of.
One thing I can do to try to help you is to check server logs to see if
your update request is making it to us, or if it's maybe a client-side
issue preventing it from being sent in the first place.
In order to do this, however, I'll need the manifest URL of the site
you're testing on (it helps if this is a rather unique URL - something like
"localhost:8080/index.html" might not help us much).
-Glenn

Post by Abhishek Ghosh
Hello,
In Paul Kinlan's article on "Improved" Add-to-Homescreen (
https://developers.google.com/web/updates/2017/02/improved-add-to-home-screen
), it says that as an update to the icon/name of the web app as defined in

You now have the ability to update your Progressive Web App's icon

and name and have it reflected to the user. Changing your icon or name in
the manifest will update the icon on the home screen after the user has
subsequently opened the site.
As a web site developer, I've tried to understand and emulate this
process but with no success yet. No matter how much I keep changing my web
app manifest's parameters, open the website (that fetches this new manifest
as verified from Dev Tools) both from the installed WebAPK icon or the
Chrome browser, put it in background (it's understandable how a WebAPK
upgrade may not happen if the app is in foreground) and so on, I have never
been able to trigger a WebAPK upgrade - I've waited for days, tried both
with same and changing manifest urls.
As a website owner, this worries me a lot to enable A2HS behaviour on a
website I may own - How can I get my users move on to the new experience
(name, icon, theme and so on) of my installed web app? If WebAPKs do not
upgrade automatically, it's pretty much a dead end because we can't have
any other website/service with our web-app listings to go and upgrade from
(such as a play store or app store) as painful as that may be; as well as
the website from Chrome's context menu (3-dot menu) now just says "Open in
<WebAPK>" rather than something like "Add to Homescreen" which means a
force-upgrade trigger from the user's end is also a no-go. The only
possibility is a user explicitly uninstalling the app and re-installing
using "Add to Homescreen" manually, which is extremely painful and unlikely
to be done by most users.
From some documentation across the web (and from my really limited
understanding of browsing through parts of Chromium source code), looks
like there is supposed to be this WebAPK "auto-upgrade" path but due to
whatever reasons I'm not able to test or trigger it. As a developer, how do
I test out this WebAPK upgrade path? What am I missing?
I've tried reaching out through other channels (Comments on
developer.google.com or Medium, questions on StackOverflow etc. to see
if there's anyone else facing this as well, sadly to no avail.) Hoping
someone can help me out here!
Thank you,
Abhishek
--
--
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Abhishek Ghosh]

Hello Glenn,

Really appreciate you helping out!

Over time I've tried getting updates and waited which has been for more
than 3 days for multiple attempts I'd have made. I've been trying my
experiments on a https://inpwatest1.firebaseapp.com ( manifest URL is
https://inpwatest1.firebaseapp.com/manifest.webmanifest
<https://inpwatest1.firebaseapp.com/manifest.webmanifest>). It'd be really
great if you can help me out from some information (through logs on your
side or otherwise) or any potential reasons why I might not be ever getting
updation triggered on my installed WebAPK, or anything else I can do from
my side to help.

Regarding the 3-day wait for triggering an update flow, for testing it
looks quite painful for web app builders... Is there any advice or
recommendation from your end in terms of how web app developers can test
such update flows out much more easily? I'd also imagine that as developers
of the Chromium platform a 3-day wouldn't be the testing mechanism... Is
there possibly some configuration I can set on the browser (or some build
variant of it we can get access to) to make things easier for testing
WebAPK updates?

Thanks,
Abhishek

Post by Glenn Hartmann
Hi!
I work on the WebAPKs team, hopefully I can help you out a bit.
This auto-update feature is implemented and enabled, so as far as I'm
aware, based on the description you gave, you *should* be getting
updates. One thing to note is that in some cases it can take up to 3 days
for the update logic to trigger - I'm not sure how long you've tried
waiting before.
If the 3-day waiting period is not the issue, then it is possible that we
have a bug. Although we do have tests that cover this logic, it could be
that you've run into some edge case that we're not aware of.
One thing I can do to try to help you is to check server logs to see if
your update request is making it to us, or if it's maybe a client-side
issue preventing it from being sent in the first place.
In order to do this, however, I'll need the manifest URL of the site
you're testing on (it helps if this is a rather unique URL - something like
"localhost:8080/index.html" might not help us much).
-Glenn

Post by Abhishek Ghosh
Hello,
In Paul Kinlan's article on "Improved" Add-to-Homescreen (
https://developers.google.com/web/updates/2017/02/improved-add-to-home-screen
), it says that as an update to the icon/name of the web app as defined in

You now have the ability to update your Progressive Web App's icon

and name and have it reflected to the user. Changing your icon or name in
the manifest will update the icon on the home screen after the user has
subsequently opened the site.
As a web site developer, I've tried to understand and emulate this
process but with no success yet. No matter how much I keep changing my web
app manifest's parameters, open the website (that fetches this new manifest
as verified from Dev Tools) both from the installed WebAPK icon or the
Chrome browser, put it in background (it's understandable how a WebAPK
upgrade may not happen if the app is in foreground) and so on, I have never
been able to trigger a WebAPK upgrade - I've waited for days, tried both
with same and changing manifest urls.
As a website owner, this worries me a lot to enable A2HS behaviour on a
website I may own - How can I get my users move on to the new experience
(name, icon, theme and so on) of my installed web app? If WebAPKs do not
upgrade automatically, it's pretty much a dead end because we can't have
any other website/service with our web-app listings to go and upgrade from
(such as a play store or app store) as painful as that may be; as well as
the website from Chrome's context menu (3-dot menu) now just says "Open in
<WebAPK>" rather than something like "Add to Homescreen" which means a
force-upgrade trigger from the user's end is also a no-go. The only
possibility is a user explicitly uninstalling the app and re-installing
using "Add to Homescreen" manually, which is extremely painful and unlikely
to be done by most users.
From some documentation across the web (and from my really limited
understanding of browsing through parts of Chromium source code), looks
like there is supposed to be this WebAPK "auto-upgrade" path but due to
whatever reasons I'm not able to test or trigger it. As a developer, how do
I test out this WebAPK upgrade path? What am I missing?
I've tried reaching out through other channels (Comments on
developer.google.com or Medium, questions on StackOverflow etc. to see
if there's anyone else facing this as well, sadly to no avail.) Hoping
someone can help me out here!
Thank you,
Abhishek
--
--
http://groups.google.com/a/chromium.org/group/chromium-discuss

['Peter Kotwicz' via Chromium-discuss]

Hi I also work on the WebAPK team. I wrote most of the update logic so
hopefully I can help. Thank you very much for reaching out. It seems that
you have identified some things that we need to improve.

I am including as much information as possible for the sake of
completeness. I know that I am repeating some of what Glenn has said.

- We check for WebAPK updates when a WebAPK is launched. We don't check for
updates when Chrome is launched
- We check for updates either every 3 days or every 30 days. Checking for
updates every 3 days is the 99% case. We switch to the 30 day interval in
some unlikely cases where the update server cannot provide an update
(According to Glenn's logs you don't seem to be in the 30 day bucket)
- Clearing Chrome's data (via "CLEAR ALL DATA" in Android settings) resets
the update timer.
- We will only update a WebAPK if the Web Manifest URL does not change. If
you change the web page from referencing <link rel="manifest.json"> to
reference <link rel="manifest2.json"> the WebAPK will no longer update
- We will only update a WebAPK if the WebAPK is not running (moving the
WebAPK to the background is not good enough)
- We will only update WebAPKs if the WebAPK was created by an official
version of Chrome (Stable/Beta/Dev/Canary). It does not work with Chromium.
(org.chromium.chrome)

Example:
Jan 1 -> Install WebAPK
Jan 1 -> Launch WebAPK -> No update check
Jan 2 -> Launch WebAPK -> No update check
Jan 4 -> Launch Chrome -> No update check (Launching Chrome has no effect)
Jan 4 -> Launch WebAPK -> Check whether update is needed
Jan 6 -> Clear Chrome's data
Jan 9 -> Launch WebAPK -> No update check (From Chrome's perspective this
is the first WebAPK launch)
Jan 12 -> Launch WebAPK -> Check whether update is needed

How to test for WebAPK updates:
Testing updates is easiest on an Android M device (or newer)
1) Launch WebAPK
2) Close the WebAPK
3) Modify the Web Manifest
4) Advance Android's system time by 3 days.
On my device: Settings>System>Date & Time>Set date
5) Launch WebAPK, wait a few seconds
6) Run adb shell dumpsys jobscheduler |
JOB.*91.*org.chromium.components.background_task_scheduler.BackgroundTaskJobService
Check that the output is not empty
7) Close the WebAPK
8) Run adb shell cmd jobscheduler run -f com.android.chrome 91
to force an update
(If you don't force an update, the update will occur sometime in the next
24 hours when your device is idle)

Debugging WebAPK updates is easier if your phone is rooted. Your comments
have convinced me that we need to make debugging updates easier if your
phone is not rooted. I have filed http://crbug.com/815282 where you can
follow along if you wish. I am hoping that these improvements will make be
in Chrome 66 which is targetted for release at the end of April.

Please let me know if you have any luck,
- Peter

[Pedro Almeida]

I'm having a similar issue where the WebAPK installed, after changing the
manifest, uninstalled, always install the version 4. With Chrome Canary it
installs an updated version 11. I could only make it install a new apk on
Chrome stable when changing the app name, which is not desirable.
Do we also have to wait some time for an updated apk to be generated when
installing, instead of using an already generated version from google
servers?
I was trying to get a new apk where the launch screen uses the high res
icon of 512px, but I am getting stuck with a version that is using the
192px, so I removed all the lower res icons so it forcefully uses the large
layout for the splash. Also to make sure something wasn't wrong with my
manifest, I installed the airhorner pwa, and for my surprise it used the
small layout with the lower res icon, even if the 256 and 512 were
specified. My device is a Moto G5 Plus 1080p, so it should always use the
high res icon for the splash.

Any insight into this is appreciated, thanks.
Pedro

Post by 'Peter Kotwicz' via Chromium-discuss
Hi I also work on the WebAPK team. I wrote most of the update logic so
hopefully I can help. Thank you very much for reaching out. It seems that
you have identified some things that we need to improve.
I am including as much information as possible for the sake of
completeness. I know that I am repeating some of what Glenn has said.
- We check for WebAPK updates when a WebAPK is launched. We don't check
for updates when Chrome is launched
- We check for updates either every 3 days or every 30 days. Checking for
updates every 3 days is the 99% case. We switch to the 30 day interval in
some unlikely cases where the update server cannot provide an update
(According to Glenn's logs you don't seem to be in the 30 day bucket)
- Clearing Chrome's data (via "CLEAR ALL DATA" in Android settings) resets
the update timer.
- We will only update a WebAPK if the Web Manifest URL does not change. If
you change the web page from referencing <link rel="manifest.json"> to
reference <link rel="manifest2.json"> the WebAPK will no longer update
- We will only update a WebAPK if the WebAPK is not running (moving the
WebAPK to the background is not good enough)
- We will only update WebAPKs if the WebAPK was created by an official
version of Chrome (Stable/Beta/Dev/Canary). It does not work with Chromium.
(org.chromium.chrome)
Jan 1 -> Install WebAPK
Jan 1 -> Launch WebAPK -> No update check
Jan 2 -> Launch WebAPK -> No update check
Jan 4 -> Launch Chrome -> No update check (Launching Chrome has no effect)
Jan 4 -> Launch WebAPK -> Check whether update is needed
Jan 6 -> Clear Chrome's data
Jan 9 -> Launch WebAPK -> No update check (From Chrome's perspective this
is the first WebAPK launch)
Jan 12 -> Launch WebAPK -> Check whether update is needed
Testing updates is easiest on an Android M device (or newer)
1) Launch WebAPK
2) Close the WebAPK
3) Modify the Web Manifest
4) Advance Android's system time by 3 days.
On my device: Settings>System>Date & Time>Set date
5) Launch WebAPK, wait a few seconds
6) Run adb shell dumpsys jobscheduler |
JOB.*91.*org.chromium.components.background_task_scheduler.BackgroundTaskJobService
Check that the output is not empty
7) Close the WebAPK
8) Run adb shell cmd jobscheduler run -f com.android.chrome 91
to force an update
(If you don't force an update, the update will occur sometime in the next
24 hours when your device is idle)
Debugging WebAPK updates is easier if your phone is rooted. Your comments
have convinced me that we need to make debugging updates easier if your
phone is not rooted. I have filed http://crbug.com/815282 where you can
follow along if you wish. I am hoping that these improvements will make be
in Chrome 66 which is targetted for release at the end of April.
Please let me know if you have any luck,
- Peter

[Abhishek Ghosh]

Thank you Peter for the detailed response - it did help me a lot of figure
out some of the nuances of WebAPK upgrades. Using your suggestions around
force upgrades on the job scheduler, I was able to force and replicate a
webAPK update scenario, so definitely some luck there, but the same
commands didn't work for me older than Android M (also something you
mentioned around... not yet sure how to test out there) - none of these
were rooted devices and I was using a Chrome release build of v64.

I'm really glad that you guys are working to make things such as testing
webAPK upgrades easier for us. Excited to see some of these improvements
come in future versions of Chrome!

Thanks,
Abhishek

Post by 'Peter Kotwicz' via Chromium-discuss
Hi I also work on the WebAPK team. I wrote most of the update logic so
hopefully I can help. Thank you very much for reaching out. It seems that
you have identified some things that we need to improve.
I am including as much information as possible for the sake of
completeness. I know that I am repeating some of what Glenn has said.
- We check for WebAPK updates when a WebAPK is launched. We don't check
for updates when Chrome is launched
- We check for updates either every 3 days or every 30 days. Checking for
updates every 3 days is the 99% case. We switch to the 30 day interval in
some unlikely cases where the update server cannot provide an update
(According to Glenn's logs you don't seem to be in the 30 day bucket)
- Clearing Chrome's data (via "CLEAR ALL DATA" in Android settings) resets
the update timer.
- We will only update a WebAPK if the Web Manifest URL does not change. If
you change the web page from referencing <link rel="manifest.json"> to
reference <link rel="manifest2.json"> the WebAPK will no longer update
- We will only update a WebAPK if the WebAPK is not running (moving the
WebAPK to the background is not good enough)
- We will only update WebAPKs if the WebAPK was created by an official
version of Chrome (Stable/Beta/Dev/Canary). It does not work with Chromium.
(org.chromium.chrome)
Jan 1 -> Install WebAPK
Jan 1 -> Launch WebAPK -> No update check
Jan 2 -> Launch WebAPK -> No update check
Jan 4 -> Launch Chrome -> No update check (Launching Chrome has no effect)
Jan 4 -> Launch WebAPK -> Check whether update is needed
Jan 6 -> Clear Chrome's data
Jan 9 -> Launch WebAPK -> No update check (From Chrome's perspective this
is the first WebAPK launch)
Jan 12 -> Launch WebAPK -> Check whether update is needed
Testing updates is easiest on an Android M device (or newer)
1) Launch WebAPK
2) Close the WebAPK
3) Modify the Web Manifest
4) Advance Android's system time by 3 days.
On my device: Settings>System>Date & Time>Set date
5) Launch WebAPK, wait a few seconds
6) Run adb shell dumpsys jobscheduler |
JOB.*91.*org.chromium.components.background_task_scheduler.BackgroundTaskJobService
Check that the output is not empty
7) Close the WebAPK
8) Run adb shell cmd jobscheduler run -f com.android.chrome 91
to force an update
(If you don't force an update, the update will occur sometime in the next
24 hours when your device is idle)
Debugging WebAPK updates is easier if your phone is rooted. Your comments
have convinced me that we need to make debugging updates easier if your
phone is not rooted. I have filed http://crbug.com/815282 where you can
follow along if you wish. I am hoping that these improvements will make be
in Chrome 66 which is targetted for release at the end of April.
Please let me know if you have any luck,
- Peter

['Peter Kotwicz' via Chromium-discuss]

Pedro, I think that you also filed https://crbug.com/819755 ? I have
responded to the bug

Before Android M, we use GCMNetworkManager to schedule updates. There is
unfortunately no way that I know of forcing tasks scheduled via
GCMNetworkManager to run. These steps work for me on a Nexus 7 device.
1) Launch WebAPK
2) Close the WebAPK
3) Modify the Web Manifest
4) Advance Android's system time by 3 days.
On my device: Settings>System>Date & Time>Set date
5) Launch WebAPK, wait a few seconds
6) Run adb shell dumpsys activity service GcmService | grep chrom | grep
"tag=[\"']*91"
Check that the output is not empty
7) Close the WebAPK
8) Advance Android's system time by 1 day
9) Restart the device
10) Toggle WiFi on and off. Wait a few seconds.
11) Run adb shell dumpsys activity service GcmService | grep chrom | grep
"tag=[\"']*91"
Check that the output is empty
12) The WebAPK should hopefully now been updated

[Tai phung]

Does this solution work currently. I tried through steps, but at 6 i got
output empty instead and app still not updated when manifest.json was
changed.
My develop environment: sam sung j7 pro, chrome stable 69. Hope to get your
answer, thank.

Post by 'Peter Kotwicz' via Chromium-discuss
Pedro, I think that you also filed https://crbug.com/819755 ? I have
responded to the bug
Before Android M, we use GCMNetworkManager to schedule updates. There is
unfortunately no way that I know of forcing tasks scheduled via
GCMNetworkManager to run. These steps work for me on a Nexus 7 device.
1) Launch WebAPK
2) Close the WebAPK
3) Modify the Web Manifest
4) Advance Android's system time by 3 days.
On my device: Settings>System>Date & Time>Set date
5) Launch WebAPK, wait a few seconds
6) Run adb shell dumpsys activity service GcmService | grep chrom | grep
"tag=[\"']*91"
Check that the output is not empty
7) Close the WebAPK
8) Advance Android's system time by 1 day
9) Restart the device
10) Toggle WiFi on and off. Wait a few seconds.
11) Run adb shell dumpsys activity service GcmService | grep chrom | grep
"tag=[\"']*91"
Check that the output is empty
12) The WebAPK should hopefully now been updated