Joachim, et al.,
I have stumbled across some issues with starting up the BOINC daemon on Android and I needed to get some clarification on the various ways Android starts and stops activities and how that relates to the BOINC daemon. My original problem occurred after installing a new version of the BOINC APK via adb. I use the following command: $ adb install -r boinc_7.1.0_arm-android-linux-gnu.apk This in turn caused Android to end the edu.berkeley.boinc process, which was expected. Now when I started the BOINC UI, it was sending a SIGKILL to the daemon so it could update the daemon and re-launch it. At this point things started to go sideways in that the new BOINC was attempting to re-launch the science applications, while the old ones were still executing. While BOINC was trying to figure out what to do next, the UI had a connection failure event and would begin the cycle all over again. At one point there were 12 wrapper applications executing and four science applications. I committed 54df9353c689434b8bbb4d8b4f816a5f7733a095 which resolves that specific issue by sending the BOINC daemon a SIGQUIT signal which allows it to shutdown and clean itself up and it's child processes. It then waits for up to 15 seconds for /data/data/edu.berkeley.boinc/client/boinc to disappear off the process list. If the BOINC daemon hasn't gracefully shutdown by then, it sends a SIGKILL. Now I've run into an issue where the UI gets stuck in a similar cascade switching between portrait and landscape modes. So my question is, what is the desirable outcome for these startup situations: 1. Launching the UI from the apps screen, when the daemon is not running? 2. Launching the UI from the apps screen, when the daemon is running? (This seems to cover launching at boot, manual upgrades, automatic upgrades, and whenever Android decides to end various activities.) 3. Switching to the UI from the apps screen? 4. Switching between Landscape and Portrait modes? 5. Should removing the UI from the task list shutdown the daemon? 6. Can we detect if/when Android has killed the daemon or any of its children because of the OOM driver? Should we find a way to have the daemon reschedule for execution later? (http://www.lindusembedded.com/blog/2010/12/07/android-linux-kernel-addi tions/) Did I miss any other conditions? Thoughts? ----- Rom _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
