Currently, the WebAPK server creates WebAPKs with the newest ShellAPK version
This is an issue because if a user installs a WebAPK for an old version of Chrome, the WebAPK might be too new and hence incompatible.

I think we need to revisit our decision of requiring Chrome to be forward compatible with all future WebAPKs.

We have thought about compatibility of Chrome with old WebAPKs a lot and I don't think there is anything we still have to do for that. It is easy to break backwards compatibility and to have WebAPKs behave OK
Our discussion is recorded here: https://docs.google.com/document/d/12f8Pw2fvFgYm9KiWYsZZYJQibtV_sYR0U3MJXux6VpU/edit#heading=h.x3edsv8k77j8

Chrome needs to provide a *stable* API for webapk to use. Android already does this with its sdk so we should follow android:
* Annotate everything that's in the API. For chrome, they probably should live in a single source directory to have the right owners.
* Have API reviewers to make sure that changes do not break backward compatibility, and that new APIs are things we are willing to maintain more or less forever
* Have tools to check binary compatibility is maintained, although admittedly I don't know how this part works in android.

Things that boliu@ said we should do to make ChildProcessServiceImpl API an actual API

- Documentation
- Make ChildProcessServiceImpl interface
- Tools to guard against API breakages. Ensure that current version of ChildProcessServiceImpl is backwards compatible with old WebAPKs
- ChildProcessServiceImpl code should be in special directory with set_noparent in OWNERS file
- Format discussion and agreement to maintain API forever

> Make ChildProcessServiceImpl interface

we probably want to have one level of indirection, like a wrapper class or something. we don't want to commit any part of ChildProcessServiceImpl (or probably anything in content) to the API

I believe this is actually why we originally introduced ChildProcessServiceImpl so that there's a shared class which we can have a layer of indirection too. However we missed the step of actually introducing a concrete WebApk wrapper. This all sounds very reasonable - sorry for the omission.

As a starting point - it's probably idiomatic to have  WebApkSandboxedProcessService depend on a new WebApkSandboxedProcessServiceHost with restricted OWNERS etc but we should give some thought to the actual API here. I think we're largely safe since process dispatching in WebApks intentionally relies on browser process and still uses the same ChildProcessLauncher lgoic and everythign is done via command-line flags set there, but it's worth thinking through this a little more concretely.

command line flags in a stable API sounds really wrong

I'm saying that is the existing API between browser/renderer

Sure. And I'm saying webapk should definitely *not* rely on that interface to be stable.

We don't.

Ok, sorry, misunderstood your comment.

So WebApkSandboxedProcessService reflects into ChildProcessServiceImpl. After looking around, that appears to be it?

And after digging around.. browser appears to be backwards compared to renderer, the webapk sends chrome the intent to start the webapk activity, passing it the things like package name so chrome knows where to look to start child services and other services to launch notifications and whatnot. Is that correct?

Yes this is correct

I am not sure by what you mean by "browser appears to be backwards compared to renderer" though

Note: Yesterday, we decided not to use the WebApkSandboxedProcessService in the initial version of WebAPKs that we ship (see  Issue 692627 ) so resolving this issue is less pressing

> I am not sure by what you mean by "browser appears to be backwards compared to renderer" though

In renderer, it's chrome providing an API for webapk. In the browser, it looks like it's mostly webapk providing an API for chrome. Browser is easier I think; just keep that binder interface stable.

#14: Thanks for the clarification boliu@. Yes that is correct

(Removing from release block list, since we're no longer using the WebApkSandboxedProcessService.)

can you elaborate? are we giving up on resource accounting to ship? do we still want accounting then?

We aren't using "WebApkSandboxedProcessService" yet. We've held back renderer accounting until it's fixed but the rest is going out

We're going to rip this out