[Epic 4G General] mkasick:
So I looked into this, and I think I have a pretty good idea of what the problem is. Or at least, for the specific instances in which I observed it.

When a "level 2" task killer is run, the process com.android.phone is killed and respawned by the ActivityManager. When this happens, it's quite often the case that the "iphonesubinfo", "isms", and "simphonebook" services don't get registered by the respawning process. That's the first problem.

The second problem is that, when SmsManager::sendTextMessage attempts to send an SMS via the "isms" service, if the service doesn't exist it silently fails, never notifying the client that the message failed to send. So the message remains pending in the client effectively forever. Now this second problem can be fixed relatively easily, but the only difference is that SMSes will always fail to send, instead of just pending forever.

As to why the "isms" service isn't reregistered: when com.android.phone starts up, it checks to see if the "isms" service already exists and only registers if it doesn't. I'm not sure exactly why it does this, but I would guess it's so that on dual radio (world phone) devices, only a single radio is used to send (and receive?) SMSes.

So basically, it's a race condition. When the task killer is run, com.android.phone restarts and attempts to register "isms" before the ServiceManager has a chance to clean the old instance of the service. It seems that Android is pretty good about preventing this. If you manually kill the process, it won't respawn until the SerivceManager cleans it up. I've even tried STOPing the servicemanager process and it still works, so I don't think the race condition exists in that situation.

I guess, if anything, there's a "bug" in the "kill package processes" logic whereby dependencies aren't completely cleaned up before respawning processes.

So, I think I could fix this by patching IccPhoneBookInterfaceManagerProxy, IccSmsInterfaceManagerProxy, and PhoneSubInfoProxy to avoid checking for existing services, although I don't know what happens when addService is called with an existing service name--it could either replace, error, or do nothing.

But to be honest, I don't think it's a good idea. There's no good reason to kill the com.android.phone process, let alone for a task killer to do so. The respawn logic is really meant to ensure that the process will come back in case of a bug-related crash, and it appears to do that much effectively. Even if this particular bug is fixed, I'm sure there's other race-related bugs lurking here, which make it just a bad idea to willy-nilly kill long-running, system critical process in the first place.

Long, story short: just don't do "level 2" task kills. Froyo is very good at managing memory and tasks on its own, I'm not aware of a situation in which it's a necessary thing to do. And frankly, I disagree with Samsung having made it available in the stock build in the first place.

Now, two useful notes: First, should you find that SMSes won't send, you can confirm this issue by running "dumpsys isms" at a shell. If there's no response, the service is running. If not, it will report "Can't find service: isms". Second, if the service isn't running, a "busybox killall com.android.phone" will force that process to respawn, and the service should register at that point. After which you can manually prod the pending SMSes to get them to go through (I think).