I just noticed a weird issue I've been having in my app. When I'm running my app, if I minimize it, then go the settings and change the language, then resume my app(note: this is minimize/resume, not exit/start), it calls the Activity's onCreate() instead of calling onResume().
This is causing a lot of issues, especially in areas where I'm using fragments in the view. The fragments being displayed are the old fragments, but the activity reference they are holding is null. So getActivity() doesn't work immediately after resuming, causing NullPointerException in many places.
My app is being built for Android 4.0.4 and above and I've noticed this issue on different devices and emulators, so it's not a platform issue.
Ideally, I'd like to call onResume() as it's supposed to. If not, I'd prefer to have the application relaunch itself silently and land the user on the home screen instead of having to face an App crash.
The app itself supports just one language: English(USA).
Has anyone faced this issue before? If yes, could you manage to resolve it?
EDIT: Based on Class Stacker's answer, It seems I need to handle the configuration change myself. Which should be fine, except that an exception is thrown in the onCreate() itself. I am calling getWindow().setRequestFeature(Window.FEATURE_INDETERMINATE_PROGRESS) in the onCreate(). When the locate changes, this line is throwing a RuntimeException saying that this must be called before setContentView().
Does this mean my Activity is not getting destroyed properly?
It's not an issue, it's by design.
If the language changes, that's a configuration change, just like screen rotation.
That means that quite a lot of things have to be re-created. Hence, this is handled via onCreate().
Sorry for the bad news but you'll have to correct the location where you create objects and how onCreate amnd onResume interoperate.
See here.
Edit: Regarding the RuntimeException, to be on the safe side, call getWindow().setRequestFeature(Window.FEATURE_INDETERMINATE_PROGRESS) before super.onCreate(savedInstanceState), as you found out during our chat.