<div><div>Sometimes I saw things like below in the logcat:</div><div>I/ServiceManager(  128): Waiting for service SurfaceFlinger...</div></div><div><br></div><div><div>If the Android services are registed in  ServiceManager, maybe we can simply ask   ServiceManager  when specific Android services are ready.</div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From: </b> "James Hunt"<james.hunt@ubuntu.com>;</div><div><b>Date: </b> Thu, Jul 11, 2013 01:01 AM</div><div><b>To: </b> "ubuntu-devel"<ubuntu-devel@lists.ubuntu.com>; "ubuntu-phone@lists.launchpad.net"<ubuntu-phone@lists.launchpad.net>; <wbr></div><div></div><div><b>Subject: </b> [Ubuntu-phone] Making Android system properties available to Upstart</div></div><div><br></div>As already explained by Oli, the Ubuntu Touch "flipped" architecture runs the<br>Android services within an LXC container. This brings a number of advantages but<br>there is a problem: knowing when specific Android services are ready. This is<br>needed such that the Ubuntu Upstart jobs running on the host side can start as<br>soon as possible, but no sooner ;)<br><br>Currently, the approach is to use heuristics to determine the "readiness" of<br>the Android services, but this can be unreliable. A better solution would be to<br>have a way to create Upstart events on the host-side when services changes occur<br>in the Android environment.<br><br>The plan at this stage is to make use of Androids System Properties and create a<br>2-part solution:<br><br>1) Create an Upstart bridge that runs on the host.<br><br>This bridge will listen on a socket and read data in the form:<br><br>  <name>=<value>\n<br><br>This will be converted into an upstart event of the form:<br><br>  <event-name> <name>=<value><br><br>The <event-name> will be specified as an argument to the bridge for security<br>reasons and would be set to something like "android-property" for Touch.<br><br>The bridge would run at the system level (as root) on the host (since it has to<br>start *before* the Android container, but the events it generates would be<br>accessible to the Session (once that has been converted to use an Upstart<br>Session Init) as ":sys:<event-name>" allowing Upstart jobs to specify conditions<br>such as:<br><br>  # run job when ueventd has started in Androids LXC container<br>  start on :sys:android-property init.svc.ueventd=running<br><br>2) Create an Android service that runs early in the Android boot process.<br><br>This service would:<br><br>- connect to the well-known socket the bridge is already listening on.<br>- monitor Androids System Properties and write them to the socket in the form:<br><br>      <name>=<value>\n<br><br>----------<br><br>Ideally, we would just have a single Upstart bridge on the host side which is<br>able to monitor property changes (*) without the need for "helper" processes on<br>the Android side.<br><br>There are a number of solutions that involve modifying Androids init, but we're<br>attempting to avoid doing that.<br><br>If anyone knows of a better way to solve this problem, please jump in.<br><br>Kind regards,<br><br>James.<br>--<br>James Hunt<br><br>(*) - just like 'watchprop' does in the Android environment.<br>____________________________________<br>#upstart on freenode<br>http://upstart.ubuntu.com/cookbook<br>https://lists.ubuntu.com/mailman/listinfo/upstart-devel<br><br>-- <br>Mailing list: https://launchpad.net/~ubuntu-phone<br>Post to     : ubuntu-phone@lists.launchpad.net<br>Unsubscribe : https://launchpad.net/~ubuntu-phone<br>More help   : https://help.launchpad.net/ListHelp<br>.<br></div>