Typically, when a user interface view does not retain its state, the first thing to check is that the user interface view has an assigned identifier. Without this, id views cannot restore their state.
<EditText android:id="@+id/text" ... />
If this does not help, you need to save and restore the state yourself. See Processing Runtime Changes . This pretty much explains what you should do:
In order to properly handle the reboot, it is important that your activity restores to its previous state through the normal Activity life cycle in which Android calls onSaveInstanceState() before it destroys your activity so that you can save application state data. You can then restore the state during onCreate() or onRestoreInstanceState() . To verify that your application has rebooted with the application status unchanged, you must invoke configuration changes (for example, changing the screen orientation) when performing various tasks in your application.
You must override onSaveInstanceState() and keep your Acitivity state when it is called:
@Override protected void onSaveInstanceState(Bundle outState) { super.onSaveInstanceState(outState); outState.putString("textKey", mEditText.getText().toString()); }
And then restore the state to onCreate() or onRestoreInstanceState() :
public void onCreate(Bundle savedInstanceState) { if(savedInstanceState != null) { mEditText.setText(savedInstanceState.getString("textKey")); } }
If this is not enough, you can override onRetainNonConfigurationInstance() and return any custom object that will be passed to the new activity object when it is recreated. For more information on how to use it, see Processing Runtime Changes . But this feature is deprecated in Android 3.0+ (especially for FragmentActivity , where its final). Thus, this cannot be used together with fragments (this is normal, they have a mechanism for saving objects when changing the configuration).
And the last - never use android:configChanges . You must have very good reasons for using it, and usually these are performance considerations. It was not intended to be abused the way it is now: just to prevent the user interface from resetting. If this attribute is used, then yes, the activity interface will not be reinstalled when the configuration is changed, but the activity state will still be reset when it is destroyed and recreated later.
The documentation describes this parameter well enough:
Note. Handling the configuration change itself can make it much more difficult to use alternative resources because the system does not automatically apply them for you. This method should be considered as a last resort and is not recommended for most applications.