For some features, platform APIs necessitate that the feature implementation pass in a piece of in-memory context that is associated with the client of the feature (e.g., NFC platform APIs on Android require passing in an Activity, which in Chrome is obtained from the WebContents associated with the renderer process that is the client of the NFC impl).

The challenge here is that the feature impl cannot maintain this association itself (e.g., the NFC impl needs to live in the Device Service, but the Device Service cannot be aware of or tied to WebContents). Moreover, this context is not serializable (e.g., the Activity is a Java object).

The solution that we will develop for this problem is to (taking Activity as a concrete example):

A. Ensure that services have an Identity that is mappable to no more than one Activity.
B. Expose a way for an in-process service to resolve an Identity to its associated Activity.
C. Expose a way for an in-process service to be notified when the Activity that is associated with a given Identity changes.

The tentative plan is for steps B and C to be executed via a client library (either in the Service Manager or some other service) that would be shared between the service impl that knows about associations between Identities and Activities (e.g., //content/browser in this case), and the service impl that *needs* to know about such associations (Device Service in this case).

More details (in the concrete context of NFC) are given here: https://docs.google.com/document/d/1AzEZ9unVnbs7mMCEKcqH3xOzHi6hQm7UXqxA_McHQqw/edit#heading=h.wzwqzm6vph4p