> My preferred approach is source-based. I could: > 1) periodically manually commit code MozStumbler's github code to m-c, > tagging in github as an m-c release, or > 2) have a script in m-c that pulls from the MozStumbler github branch (or > pull from github master for this, and make the dev trunk a branch)
For Sync we do it manually whenever we merge a pull request. https://github.com/mozilla-services/android-sync/blob/develop/fennec-copy-code.sh This is handy because it generates a patch for attachment to a bug and review, which is how we do things in m-c. >> Paging ibarlow/alam/yuan. We already show a Data Reporting notification, and >> probably location stumbling shouldn't be on by default. Adding a second >> notification is likely a step too far, so I'd suggest a call to action from >> a snippet, or a non-first-run nudge. Provide both incentive and opportunity. > > On first run, there is a notification prompt to ask if the user wants to > contribute to MLS By notification prompt, do you mean an Android notification? If so, we'll need to address that somehow. [uxwanted]! > If the stumbler service was not a separate process, the cases I was > considering are: > 1) Fennec has not been run yet, and the stumbling service starts, the > resource usage is only the stumbler, this is ok, and > 2) Fennec has been run, and now backgrounded. As a heavy resource using > process, it will be likely killed, and the stumbler service along with it. > This is problematic (potentially***). Fennec reclaims memory when prompted by the system, so we're only talking about very low memory situations here. But those are definitely an issue. > This is based on the presumption that Android looks at separate processes > within an application as separate items for killing. They are not > parent-child related, so I assumed that was the case. Assuming is bad, and > the Android docs are not clear on this, but I am sure the facts are out there > for me :). It does kill processes separately. And service processes are slightly higher priority than backgrounded app processes; this scenario ("keep running if the app is killed") is why. On the other hand, Android will restart the main app process to host content providers and run syncs, as well as to launch services to handle intents. That is: it's quite possible that even if it did kill the foreground process, it would start it again to host your service next time it caught the right intent. Lots of options here, and switching between them is as simple as changing one line in a manifest. > *** There is a 3rd point to made in this regard, which is, this all depends > on what intents the stumbler service uses for startup. If it listens for > sparse events to start (like the BOOT intent), then getting killed is > problematic. If it listens for common events, then it will likely get > restarted in a reasonable period of time. Solvable (and needs to be solved for things like SD card ejection): hook into more events. It gets messy, but that's Android! :D _______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
