Re: [android-developers] Re: Where is the UI state information (used in super.onCreate(Bundle savedInstanceState)) stored ?
On Mon, Nov 8, 2010 at 1:37 AM, Mathias Lin m...@mathiaslin.com wrote: That's what I thought. But why is the UI state then not entirely cleared? AFAIK, applications do not hold the saved instance state -- the operating system does, in its own process. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Where is the UI state information (used in super.onCreate(Bundle savedInstanceState)) stored ?
Hi Mark, thanks for your reply. Yes, it's probably managed by the system, yet I'm still wondering: Below you can see that the browser activity runs in different processes (#2307, #5536) before and after I killed/restarted it, and yet it's displaying / restoring the same UI input values entered by the user, regardless of being in an entire new process. So, are the two activities in these two processes actually the same instance? If so, why? (I was thinking of something like 'task parenting' to be eventually happening here, but it cannot be, since there's no android:allowTaskReparenting attribute in the application's manifest and the default value for an activity for such is false. And it would also mean that the activity wouldn't really be gone even after kill has been executed.) [*** some user input on UI in the browser app ***] # ps | grep -i browser ps | grep -i browser app_27 2307 75131944 25960 afe0da04 S com.android.browser # killall -9 com.android.browser killall -9 com.android.browser [*** browser is killed, then I press home long, select browser app from recent apps ***] # ps | grep -i browser ps | grep -i browser app_27 5536 75121868 24316 afe0da04 S com.android.browser [*** ... and the UI still shows values from the activity in the previous #2307 process *** ] On Nov 8, 8:19 pm, Mark Murphy mmur...@commonsware.com wrote: On Mon, Nov 8, 2010 at 1:37 AM, Mathias Lin m...@mathiaslin.com wrote: That's what I thought. But why is the UI state then not entirely cleared? AFAIK, applications do not hold the saved instance state -- the operating system does, in its own process. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Where is the UI state information (used in super.onCreate(Bundle savedInstanceState)) stored ?
On Mon, Nov 8, 2010 at 11:38 AM, Mathias Lin m...@mathiaslin.com wrote: thanks for your reply. Yes, it's probably managed by the system, yet I'm still wondering: Below you can see that the browser activity runs in different processes (#2307, #5536) before and after I killed/restarted it, and yet it's displaying / restoring the same UI input values entered by the user, regardless of being in an entire new process. That make sense. So, are the two activities in these two processes actually the same instance? That's not possible. Each process has its own VM. However, they might have the same *instance state* (i.e., Bundle). I have no real idea what you're trying to accomplish here -- what you originally posted sounds scary. However, the answer for dealing with all this in-flight instance state stuff is to reboot the phone. Since you're running a rooted phone, I would think there's a way to reboot it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Where is the UI state information (used in super.onCreate(Bundle savedInstanceState)) stored ?
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. On Mon, Nov 8, 2010 at 9:14 AM, Mark Murphy mmur...@commonsware.com wrote: On Mon, Nov 8, 2010 at 11:38 AM, Mathias Lin m...@mathiaslin.com wrote: thanks for your reply. Yes, it's probably managed by the system, yet I'm still wondering: Below you can see that the browser activity runs in different processes (#2307, #5536) before and after I killed/restarted it, and yet it's displaying / restoring the same UI input values entered by the user, regardless of being in an entire new process. That make sense. So, are the two activities in these two processes actually the same instance? That's not possible. Each process has its own VM. However, they might have the same *instance state* (i.e., Bundle). I have no real idea what you're trying to accomplish here -- what you originally posted sounds scary. However, the answer for dealing with all this in-flight instance state stuff is to reboot the phone. Since you're running a rooted phone, I would think there's a way to reboot it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Where is the UI state information (used in super.onCreate(Bundle savedInstanceState)) stored ?
Not too scary if you look at my scenario ;-) I have devices that I rent out to end-users through a hotel/concierge. These devices hold 1) my app, 2) browser, 3) facebook app. End-users (hotel guests) can rent the devices and return it to the hotel. The non-technical hotel concierge needs to be able to clear all user data with one click from 1) my app before handing it to another guest, without needing to go through the application settings of each application, clear data there. For a non-technical person, those would be too many steps. In fact, the concierge doesn't even have access to the device settings (he can only move around the mentioned three apps). Therefore I need a way to clear the data programmatically via script (one button click in my app). But I don't want to need a force a device reboot if that's not really necessary. I'd like to understand what's happening here, i.e. how can the two have the same instance state / bundle? Just because the two activities have the same package / class name? And also, why is there a difference whether the activity was last in the foreground or not. Ok..., I'm probably repeating what I already mentioned above. I know it's kind of a special use-case I'm having here... still trying to find a good solution hopefully without needing to force a reboot. I appreciate your input or any other ideas for such scenario. Thanks. On Nov 9, 1:14 am, Mark Murphy mmur...@commonsware.com wrote: On Mon, Nov 8, 2010 at 11:38 AM, Mathias Lin m...@mathiaslin.com wrote: thanks for your reply. Yes, it's probably managed by the system, yet I'm still wondering: Below you can see that the browser activity runs in different processes (#2307, #5536) before and after I killed/restarted it, and yet it's displaying / restoring the same UI input values entered by the user, regardless of being in an entire new process. That make sense. So, are the two activities in these two processes actually the same instance? That's not possible. Each process has its own VM. However, they might have the same *instance state* (i.e., Bundle). I have no real idea what you're trying to accomplish here -- what you originally posted sounds scary. However, the answer for dealing with all this in-flight instance state stuff is to reboot the phone. Since you're running a rooted phone, I would think there's a way to reboot it. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Where is the UI state information (used in super.onCreate(Bundle savedInstanceState)) stored ?
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. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Where is the UI state information (used in super.onCreate(Bundle savedInstanceState)) stored ?
Ok. In my case, I cannot call finish() myself since it's a third party app (Facebook) and the native browser. Therefore I do a kill. Wouldn't that also end the lifecycle as well, with same effect as a finish() ? On Nov 8, 12:55 pm, Dianne Hackborn hack...@android.com wrote: It isn't stored anywhere persistent. It is only kept in RAM, and only for as long as that particular activity instance may need to be launched again. (That is, if you call finish(), that activity instance is gone, and any saved state no longer needs to be kept.) On Sun, Nov 7, 2010 at 8:52 PM, Mathias Lin m...@mathiaslin.com wrote: Where is the UI state information (used in super.onCreate(Bundle savedInstanceState)) stored and how can it be deleted from another app or command line on a 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) or elsewhere 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 the running processesand 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. 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? 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. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Where is the UI state information (used in super.onCreate(Bundle savedInstanceState)) stored ?
On a rooted phone, you ought to be able to kill the Linux process. Just finish or force close may not be secure since the Android OS lazily reclaims processes that are no longer in use. Although on a non-rooted phone this is not an issue, since the Android OS relies on Linux process security. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Where is the UI state information (used in super.onCreate(Bundle savedInstanceState)) stored ?
That's what I thought. But why is the UI state then not entirely cleared? But I found the following difference though doing some more testing - I found there's a difference whether the activity is in the foreground or not when I do the kill: Case 1) I start the facebook app, I am on the login page, enter a username (but don't submit), then I switch to the Terminal app on my device (thus, the FB activity is not in the foreground anymore), then I kill all facebook processes (which I see via 'ps'), and restart the app (via home long-press, selected recent). The username is still there! Case 2) I start the facebook app, I am on the login page, enter a username (but don't submit). Then I kill the process via PC (adb shell), while the facebook login screen is still in the foreground when I do the kill). When I execute the kill command, I can see the FB activity getting closed on the device. When I then restart the app (via home long-press, selected recent), the username on the login screen is gone - as expected. Why is there a difference whether the application is in the foreground? How to clear the UI state of activities that are not in the foreground anymore? On Nov 8, 1:47 pm, Frank Weiss fewe...@gmail.com wrote: On a rooted phone, you ought to be able to kill the Linux process. Just finish or force close may not be secure since the Android OS lazily reclaims processes that are no longer in use. Although on a non-rooted phone this is not an issue, since the Android OS relies on Linux process security. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
