This is something that I thought of due to the confusion with the share target roll out.

There's some sense to limiting this to not be on every load in the event that we screw up between client<->server. If for example client always thinks there's an update, every launch for each user is a lot more traffic than at most once every 3 days. I'm certainly agreeable to lowering to 1 day though.

Per our offline discussion, we could also add a developer optoin to about:webapks - that helps the conversation with web devs. I recognize that it doesn't impact users but it provides confidence that "when chrome updates, it will pick up the change you want". Unfortunately, this is probably a bit involved as we have to load the webapk in a hidden tab or actualy launch the webapk and then provide a toast/logcat/ui on whether it succeeded

I agree that we should limit "how often we request an update"
I think that we can safely check "whether an update is needed" each time that a WebAPK is launched

This would decrease the update latency to 24 hours after the user launches a WebAPK following a Chrome update.

I agree that every launch is too often. 1 day is probably fine though. I also love the idea for an option to force an update in chrome://webapks.

Sure, #3 would be fine with me. The simplest thing would be to change the 3-day constant to 1-day but I suspect you want to fix it the whole way. ;)

Also, I'm not actually sure I was write that we'd need to load the webapk in background tab like I was saying in #2. Does the manifest provide enough information that we could just fetch it and check? I guess we still wouldn't want to request/parse the manifest from the browser process so it's not that simple?

I filed a bug for adding "update" functionality to chrome://webapks in Issue 918898