Question

I’m trying to develop an app that would normally be considered to be malware, but the customer’s demands are very specific and logical. We have around 50-100 cheapset Android phones that are bolted down, plugged in, and the app is supposed to send some of the sensor data via tcp to a remote server. It sounds simple enough, but there are two features that I struggle with (since I’m not an experienced Android developer, and have never rooted a phone):

#1 The app should be always on. If it crashes, server should get the error report (stack trace), and the app should be restarted after 10 minutes one more time before giving up. Also, the OS could theoretically kill the app (although I did my best to minimize the memory usage). I’d like to somehow handle that as well.

#2 It would be great if the app could be remotely updated, or auto-updated, with no user interaction whatsoever (since there is no conventional user).

To implement #1, I see no other solution than to root the phone (AlarmsManager doesn’t seem to work as I expected, and adding another application to take care of the first one just feels wrong). Is there anything I’m missing?

I don’t know how to approach implementing feature #2 at all. If I put the app on the market and check the “keep this application always up to date” checkbox while installing it, will that work? I fear that the auto-update would not occur while the service is running, and even if it did, that the OS would not restart the service after installing the update (unless feature #1 is implemented). If I programatically download the latest .apk and open it, I still need the user to click the “Install” button. I’m even considering implementing the updateable part in some scripting language.

Is there a solution to these problems within the limits of Android API?

EDIT: Thank you all for your answers, you’ve been very helpful. It seems that the only way to make Android behave as a non-user piece of hardware is to root it. That’s the only way to do silent auto-updates. Always on can then be implemented by enabling cron (AlarmManager apparently doesn’t fire the event in case of service termination via crash, but it could be used by another trivial, non-crashable service to keep the first one running).

Answer 1

For #1 you can use an foreground service. I don’t know how often you need to get sensor data, but what’s the problem with AlarmManager? I don’t see how rooting could help with #1 though. You can’t really do #2 without rooting or building your firmware. If you install your app as a system app (in /system/app) you can use a hidden PackageManager to silently install the new version. Using Market/Play autoupdate should work as well, but you have no way to control the update schedule. And, yes, it won’t restart your service, but if you use AlaramManager, this shouldn’t be a issue.

All in all, stock Android is not exactly an embedded system that gives you full control, so depending on how much time/effort you are willing to spend, you might want to customize it somewhat (or find a custom ROM that gets close to your requirements).