UI state of activity not cleared when killing the activity while in background (on rooted phone)

I need to delete the user data (username, password) of both the native Facebook app (com.facebook.katana) and the stock browser on Android (com.android.browser) on a rooted phone via command line (which I call from my own app).

This is what I'm calling:

rm /data/data/com.android.browser/cache/webviewCache/*
rm /data/data/com.android.browser/databases/*
killall -9 com.android.browser

rm /data/data/com.facebook.katana/cache/webviewCache/*
rm /data/data/com.facebook.katana/databases/*
killall -9 com.facebook.katana

After I kill the facebook process, I check with ps and there is no FB process running anymore. I then restart FB via long-press on home and choosing the FB app. Previous username/password still show on the login screen (= same screen as I left it before I killed the app). When I then press 'back' on the device, and then start the app again via home long-press / select FB, the login screen is empty as it should. Where do the values for username/password come when I start FB again in the first place?

I assume that the login activity still retrieves the savedInstanceState, but how could that be avoided - or else, where are those UI states actually stored, in order to delete them? But also, shouldn't the restarted app, after all it's processes are killed, already be in a new lifecycle?

Same problem is with the stock browser: if i leave the browser and I'm on the login page of for example gmail.com where the username/password is entered (but form not submitted yet), then killing the browser process, the values (username) entered into the form will 开发者_如何学运维still be there after restarting the app again after it's been killed.

---

From http://groups.google.com/group/android-developers/browse_thread/thread/990feed121f0ea39:

reply from Dianne Hackborn:

They don't have the same instance state. You can use "adb shell dumpsys activity" to see the system's activity stack; each of those entries is an "instance" of an activity as far as the system is concerned. Killing a process while its UI is in the background is a normal situation on the system -- it is what happens when memory is low. It is expected, and doesn't impact the instance that the system has on the stack. (It will just have to ask the app to re-create it the next time the user visits it.) Killing a process while it is in the foreground is not normal. In that case the system didn't have time to ask it to save its instance state, so it can not re-start the activity in its last state, so it throws that instance away.

Please leave the lifecycle documentation. Processes are just transient entities used to hold running processes; killing a process is not the same as "stopping" an application. You are treating this like a Unix system, when it is not. Resetting an application back to its initial state is done with the "clear data" button in manage applications, which asks the package manager to erase all of its data, and does a full force stop which in addition to killing processes also stops services and tells all system services to release any state they have about the app (such as configured app widgets etc). You should use the same API that manage apps does for this, which is not part of the SDK, but you clearly aren't trying to do something in the SDK. Which brings up -- your question should be posted to a group like android-porting since you are doing platform-level stuff. Posting questions like this here is not going to get a good response because when people see questions on this group they are thinking in terms of the SDK, which is not at all relevant for you.which is not at all relevant for you.