RuntimeEnvironment structure of MRL

It would seem like the logical thing to do is wrap the RuntimeEnvironment data structure in a Service. The issue I am having is "something" needs to notify & publish events when the RuntimeEnvironment data structure changes. Sooooo, "a Service is a Service is a Service" .. This Service would be the first one to be created & started .. and could be repressed (if necessary) to unclutter user intefaces..  Yet the issues around notifiying different environments and issuing messages based on changes of Service states becomes simplified (even the heartbeat.. status)
 

Android "should" behave the same as GUIService ???  Or is should each activity be in a Map and be bound to the host Service directly ?

Should Runtime manage changes to RuntimeEnvironment events ???

Random Runtime name or startup parameter for unique instance id, accessURI is only in reference to a foriegn instance.

TODO - Compare environments - export appropriately (ie Proxies)
TODO - find all .service.class.getCan .. change to sw.getClass() ??? Override with Proxy.

Found out that an application CAN NOT OWN THE ACTIVITY !!!  Well this is probably one of the largest paradigm shifts from swing.   The person asking the question in the stackflow came about a solution of registering a context in the application.  Which I think I will try to implement. 

This means that no data can be owned by the Activity..  I think this was a "good" way to enforce the MVC pattern, where the View does not own data.  Leave it to Google :)  ..  Impressive.