activity-lifecycle

I have an app which is one activity. Everything works as I would expect except when I put the phone (a Samsung Galaxy Ace running Gingerbread) to sleep with the button on the side. When I do this, the following are called (in this order): onPause, onStop, onDestroy, onCreate, onStart, onResume, onPause . This is without waking the phone up , it is still asleep - screen is off. Why is the activity killed completely and re-recreated? Even more bizarre, if the phone is then switched back on the following happens: onResume, onPause, onStop, onDestroyed, onCreate, onStart, onResume Even though it's

On low memory device I've got a problem after calling camera intent. When activity result should be received Android restart the whole app. Have anybody faced same problem? Is there any solution? timoschloesser I faced the same issue a while ago: Android system stops application when launching Media Intent Apparently there is no solution, so you have to make sure that you save and restore the application state. Well i think, the problem could be: Image byte array is too big such that it touches the limit and android restarts the application so following is what will i do: Calling the intent

I am using the following snippet to check whether applications that I finish() ed are indeed no longer running: ActivityManager am = (ActivityManager)this.getSystemService(ACTIVITY_SERVICE); List<ActivityManager.RunningAppProcessInfo> procList = am.getRunningAppProcesses(); for (ActivityManager.RunningAppProcessInfo proc : procList) Log.d(TAG, proc.processName); } To my dismay, some applications that I finish() ed (in their Activity.onCreate(), even before they had a chance to launch anything), are still listed there. Why? LogCat shows that these applications' onDestroy() was definitely called

My app is composed of a single Activity . In this activity, I'm creating multiple HandlerThread s which run in a loop to do socket blocking operations. Currently I post a quit message to everyone of these HandlerThread s during my Activity.onDestroy() . Sometimes, when I open my app, close it and relaunch it, it crashes (many time due to posting a message to a handler thread which is not running). My question is: What is the right way to close HandlerThread when I close my app? (Note that those threads might be blocking on a socket operation). EDIT: More information: I have a pool of Handler

I found my activities onStop() method will be called with a less than 10 seconds delay. I've never seen before this behavior. Note :- The activity is singleTop and it starts with Intent.FLAG_ACTIVITY_REORDER_TO_FRONT flag. Note :- I'm using Build Tools v23.0.2. The delay wasn't before and the method would be called immediately. I am guessing that you are starting another activity and you expect the current activity to receive an onStop() callback. According to the activity lifecycle , the onPause() method is called before the onStop(). In some cases onSaveInstance() is also called before the

I have a problem with my android app, I'm developing with Android STUDIO IDE. Pretty much when I leave the app in the background for a few minutes, or is killed by the system or I mix the different layouts of the fragment. I have put a picture below: I've already tried a variety of methods, if you have others write as well. Thank you in advance. super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); final ViewPager pager = (ViewPager) findViewById(R.id.pager); pager.setAdapter(new MyPagerAdapter(getSupportFragmentManager())); actionBar = getActionBar(); actionBar

This is what I read from a book: The activity can be destroyed silently after onPause(). We should never assume that either onStop() or onDestroy() is called. But according to the documentation, Pause refers to partly visible, can an activity partly visible be killed without calling onStop or onDestory? There is no guarantee that onStop or onDestroy will be called. In situations when memory is severely lacking, the partially visible and out-of-focus Activity may be destroyed to reclaim resources. However, there is no guarantee that either of the two mentioned lifecycle methods will be called