65

Basically, this is what I'm doing

1) Set AlarmManager to execute BroadcastReceiver (BCR)

Intent intent = new Intent(m_Context, BCR.class);  
intent.putExtras(extras);  
PendingIntent pendingIntent = PendingIntent.getBroadcast(m_Context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);  
AlarmManager am = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
am.set(AlarmManager.RTC_WAKEUP, StartTime, pendingIntent)  

2) Start MyActivity from BCR

@Override  
public void onReceive(Context context, Intent intent) {  
    Intent newIntent = new Intent(context, MyActivity.class);
    newIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP);  
    context.startActivity(newIntent);  
}

3) Have MyActivity turn on the screen if its not on

@Override  
public void onCreate(Bundle savedInstanceState) {  
    super.onCreate(savedInstanceState); 
    getWindow().addFlags(LayoutParams.FLAG_DISMISS_KEYGUARD);
    getWindow().addFlags(LayoutParams.FLAG_SHOW_WHEN_LOCKED);
    getWindow().addFlags(LayoutParams.FLAG_TURN_SCREEN_ON);
    setContentView(R.layout.myactivity);  
} 

@Overide  
protected void onNewIntent(Intent intent) {  
    super.onNewIntent(intent);  
}  

For some reason, I notice that right when MyActivity is opened, it's flow goes like:

onCreate/onNewIntent -> onResume -> onPause -> onResume

I'm not sure why it does an onPause right away. I notice this only happens when the screened is being turned on by the flags. Does anyone know why this happens? Is there any way this behavior can be prevented?

Huy T
  • 1,273
  • 1
  • 11
  • 21
  • Does your activity force a specific orientation like portrait or landscape? – twaddington Apr 16 '13 at 00:23
  • The screenOrientation is set to portrait for MyActivity in the manifest. – Huy T Apr 16 '13 at 00:34
  • 1
    If you are issuing **StartActivityForResult()** during _onCreate()_ then the resultant **onActivityResult()** triggers an _onRestart()-onStart()-onResume()_ sequence! – Bad Loser Nov 30 '19 at 01:05

19 Answers19

38

if you trying request permissions every time it can cause such problems, just check if you already granted them

requestPermissions can cause it:

onCreate
onStart
onResume
onPause
onResume

Use this method ContextCompat.checkSelfPermission(context, permission) to check if permission was granted or not before requesting it

This method returns int and you can check it with PackageManager.PERMISSION_GRANTED constant

user924
  • 8,146
  • 7
  • 57
  • 139
35

Just in case anyone else runs into this, I seem to notice this behaviour only when I inflate fragments inside of an activity via XML layout. I don't know if this behaviour also happens with the compatibility library version of Fragments (I'm using android.app.Fragment)

It seems the activity will call Activity#onResume once before calling Fragment#onResume to any added Fragments, and then will call Activity#onResume again.

  1. Activity:onCreate
  2. Fragment:onAttach
  3. Activity:onAttachFragments
  4. Fragment:onCreate
  5. Activity: onStart
  6. Activity: onResume
  7. Fragment: onResume
  8. Activity: onResume
Derek
  • 632
  • 2
  • 11
  • 29
ainesophaur
  • 774
  • 5
  • 12
18

If you have ES File Explorer then FORCE STOP it. Somehow, they interrupt your app's lifecycle (comments suggest some kind of overlay).

My issue with onResume being caused twice was because onPause was somehow being called after the activity was created.. something was interrupting my app.

And this only happens after being opened for the first time after installation or built from studio.

I got the clue from another post and found out it was because of ES File Explorer. Why does onResume() seem to be called twice?

As soon as I force stop ES File Explorer, this hiccup behavior no longer happens... it's frustrating to know after trying many other proposed solutions. So beware of any other interrupting apps like this one.

TWL
  • 6,228
  • 29
  • 65
  • 4
    Might be because ES Explorer creates an overlay to collect analytics data when any app is launched. This would essentially trigger a focus change, which might be causing the duplicate pause & resume triggers – anandbibek Dec 26 '16 at 13:34
  • i was facing the same issue can we guys sue es-file manager app because it is destroying other apps behaviors – Mateen Chaudhry Sep 09 '18 at 06:51
  • I tried but was not the ES File Explorer. Still searching the reason. – Boris Karloff Sep 23 '18 at 22:43
7

I was researching about this for a while because on the internet there is no any mention about this weird behaviour. I don't have a solution how to overcome this dark-side-behavior but I have found an exact scenario when it certainly happens.

onPause-onResume-onPause-onResume just happens every time, when app is starting first time after installation. You can simply invoke this behavior by doing any change in code and rerunning (which includes recompiling) the app from your IDE.

No matter if you use AppCompat libs or not. I have tested both cases and behavior carries on.

Note: Tested on Android Marshmallow.

I have borrowed the code from this thread about fragment and activity lifecycle and here it is (just copy, paste, declare activity in manifest and run Forest run):

import android.app.Activity;
import android.app.Fragment;
import android.app.FragmentTransaction;
import android.content.Context;
import android.os.Bundle;
import android.util.Log;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.TextView;

public class TestActivity extends Activity {

    private static final String TAG = "ACTIVITY";

    public TestActivity() {
        super();
        Log.d(TAG, this + ": this()");
    }

    protected void finalize() throws Throwable {
        super.finalize();
        Log.d(TAG, this + ": finalize()");
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Log.d(TAG, this + ": onCreate()");


        TextView tv = new TextView(this);
        tv.setText("Hello world");
        setContentView(tv);

        if (getFragmentManager().findFragmentByTag("test_fragment") == null) {
            Log.d(TAG, this + ": Existing fragment not found.");
            FragmentTransaction ft = getFragmentManager().beginTransaction();
            ft.add(new TestFragment(), "test_fragment").commit();
        } else {
            Log.d(TAG, this + ": Existing fragment found.");
        }
    }

    @Override
    public void onStart() {
        super.onStart();
        Log.d(TAG, this + ": onStart()");
    }

    @Override
    public void onResume() {
        super.onResume();
        Log.d(TAG, this + ": onResume()");
    }

    @Override
    public void onPause() {
        super.onPause();
        Log.d(TAG, this + ": onPause()");
    }

    @Override
    public void onStop() {
        super.onStop();
        Log.d(TAG, this + ": onStop()");
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        Log.d(TAG, this + ": onDestroy()");
    }


    public static class TestFragment extends Fragment {

        private static final String TAG = "FRAGMENT";

        public TestFragment() {
            super();
            Log.d(TAG, this + ": this() " + this);
        }

        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            Log.d(TAG, this + ": onCreate()");
        }


        @Override
        public void onAttach(final Context context) {
            super.onAttach(context);
            Log.d(TAG, this + ": onAttach(" + context + ")");
        }

        @Override
        public void onActivityCreated(Bundle savedInstanceState) {
            super.onActivityCreated(savedInstanceState);
            Log.d(TAG, this + ": onActivityCreated()");
        }

        @Override
        public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
            Log.d(TAG, this + ": onCreateView()");
            return null;
        }

        @Override
        public void onViewCreated(View view, Bundle savedInstanceState) {
            super.onViewCreated(view, savedInstanceState);
            Log.d(TAG, this + ": onViewCreated()");
        }

        @Override
        public void onDestroyView() {
            super.onDestroyView();
            Log.d(TAG, this + ": onDestroyView()");
        }

        @Override
        public void onDetach() {
            super.onDetach();
            Log.d(TAG, this + ": onDetach()");
        }

        @Override
        public void onStart() {
            super.onStart();
            Log.d(TAG, this + ": onStart()");
        }

        @Override
        public void onResume() {
            super.onResume();
            Log.d(TAG, this + ": onResume()");
        }

        @Override
        public void onPause() {
            super.onPause();
            Log.d(TAG, this + ": onPause()");
        }

        @Override
        public void onStop() {
            super.onStop();
            Log.d(TAG, this + ": onStop()");
        }

        @Override
        public void onDestroy() {
            super.onDestroy();
            Log.d(TAG, this + ": onDestroy()");
        }
    }

}
Community
  • 1
  • 1
matusalem
  • 2,461
  • 2
  • 26
  • 35
  • i have exactly tha same problem using samsung galaxy note 4..have you found any work around? – tsiro Mar 21 '16 at 12:05
  • I still haven't found any workaround. I've stopped using vulnerable operations (e.g. starting threads etc.) in `onResume` and `onPause`. I've moved them into `onStart` and `onStop`. – matusalem Mar 23 '16 at 15:42
  • You don't have to move it to start and stop. But you do have to double gate them. So check if you should start the thread, and if you should start the thread. Then Inside the thread check again, and abort as needed. Especially synchronized. – Tatarize Jun 14 '17 at 15:02
5

I don't know for sure what's going on, but I suspect that your activity is being restarted because setting the screen on is treated by the system as a configuration change. You might try logging the configuration on each call to onResume to see if that's what's happening and, if so, what is actually changing. You can then modify the manifest to tell the system that your activity will handle the change on its own.

protected void onResume() [
    super.onResume();
    Configuration config = new Configuration();
    config.setToDefaults();
    Log.d("Config", config.toString());
    . . .
}
Ted Hopp
  • 232,168
  • 48
  • 399
  • 521
  • It doesn't look like there are any configuration changes between the two onResumes. – Huy T Apr 16 '13 at 00:48
  • @HuyT - Is the system putting anything into the log file that might point to what's happening? – Ted Hopp Apr 16 '13 at 00:59
  • The only thing I can see is that the ActivityManager only attempts to display the Activity and the PowerManagerService wakes up from sleep only after the onPause. Is there a way I can force this to happen before the onPause? – Huy T Apr 16 '13 at 01:11
  • @HuyT - Weird. I still suspect a configuration change is triggering this. Temporarily, how about telling Android in the manifest that your activity will handle all configuration changes? If the problem goes away, then play around with the list until the culprit is isolated. I'll think some more about what else might be going on. – Ted Hopp Apr 16 '13 at 01:33
  • Just tried this, and its still happening. Strange. I might just have to go with my workaround, although I was hoping to actually fix this. Thanks anyways Ted Hopp. If you come up with anything else, it would be appreciated. – Huy T Apr 16 '13 at 01:56
  • Share my observation.When I change from Activity A to Activity B,if operate a bit fast then A will call `onResume` and B will also call `onResume` ,that's weird. – zionpi Feb 16 '16 at 09:07
3

I have similar problem. My situation was next CurrentActivity extends MainActivity CurrentFragment extends MainFragment

I was opening CurrentActivity with intent as usually. In onCreate CurrentAcitivity I was replacing CurrentFragment.

Life Cycle was: 1. onResume MainActivity 2. onResume CurrentActivity 3. onResume MainFragment 4. onResume CurrentFragment

called onPause Automatically, and after that again

  1. onResume MainActivity
  2. onResume CurrentActivity
  3. onResume MainFragment
  4. onResume CurrentFragment

I decide to retest everything and after few hours spend trying and playing I found root issue. In MainFragment onStart I was calling startActivityForResult every time (in my case android popup for turning on Wifi) which was call onPause on MainFragment. And all of us know that after onPause next is onResume.

So its not Android bug, it's only mine :-)

Happy lifecycle debuging!

msamardzic
  • 1,060
  • 9
  • 12
2

Have you tried calling your getWindow().addFlags(...) before calling super.onCreate(savedInstanceState) in onCreate method?

I had a similar problem. onResume was called twice when my onCreate looked like this:

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_YES);
    setContentView(R.layout.main);
    ...
}

Changing it to:

@Override
public void onCreate(Bundle savedInstanceState) {

    AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_YES);

    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    ...
}

... fixed the problem.

Viktor Brešan
  • 5,293
  • 5
  • 33
  • 36
  • For what it’s worth, I gave this a shot and it didn’t help, but this change did result in slightly improved app Cold start times on older devices! – Bink Jun 08 '22 at 23:12
  • This somehow fixed the problem for me. But Didn't understand why this happened. Thanks a lot! – Yus Jul 24 '23 at 11:51
1

I also ran into this onresume-onpause-onresume sequence (on 4.1.2 and above, but I did not experience this on 2.3). My problem was related to wakelock handling: I accidentally forgot to release a wakelock and reacquiring it caused an error with a message "WakeLock finalized while still held". This problem resulted in onPause being called immediately after onResume and resulted in faulty behavior.

My suggestion is: check for errors in the log, those might be related to this issue.

Another hint: turning on the screen might be a bit more tricky than simply using window flags. You might want to check this answer here - it suggests you set up a receiver to check if the screen has already been turned on and launch the desired activity only after: https://stackoverflow.com/a/16346369/875442

Community
  • 1
  • 1
Levente Dobson
  • 773
  • 8
  • 10
1

I had a similar issue, and my problem was that at the onCreate() method, I was doing:

@Override
protected void onCreate(Bundle savedInstanceState)
{
    super.onCreate(savedInstanceState);
    super.setContentView(R.layout.friends);  <-- problem
}

My call to "super." was triggering the onResume() twice. It worked as intended after I changed it to just:

@Override
protected void onCreate(Bundle savedInstanceState)
{
    super.onCreate(savedInstanceState);
    setContentView(R.layout.friends);  <-- 'super.' removed
}

Hope it helps.

Victor Lee
  • 388
  • 2
  • 14
1

I just ran into this, and it seems that getWindow().addFlags() and tweaking Window properties in general might be a culprit.

When my code is like this

@Override
protected void onCreate(Bundle savedInstanceState) {
    requestWindowFeature(Window.FEATURE_NO_TITLE);
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_generic_fragment_host);
    // performing fragment transaction when instance state is null...

onResume() is triggered twice, but when I remove requestWindowFeature(), it's only called once.

Actine
  • 2,867
  • 2
  • 25
  • 38
0

It seems that using Activity from the support library saves and restores instance automatically. Therefore, only do your work if savedInstanceState is null.

yazjisuhail
  • 357
  • 3
  • 6
0

I think you should have a look at that question: Nexus 5 going to sleep mode makes activity life cycle buggy You should find leads

Community
  • 1
  • 1
0

Basically a lot of stuff can trigger this. Some resume processes that loses focus can do it. A few apps will cause it to happen too. The only way to cope is to block the double running. Note, this will also have an errant pause thrown in for good measure.

    boolean resumeblock = false;

    @Override
    protected void onResume() {
        super.onResume();
        sceneView.getViewTreeObserver().addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
            @Override
            public boolean onPreDraw() {
                sceneView.getViewTreeObserver().removeOnPreDrawListener(this);
                if (resumeblock) return false;
                resumeblock = true;

                //Some code.

                return false;
            }
        });
    }

This is a solid way to prevent such things. It will block double resumes. But, it will also block two resumes that preserve the memory. So if you just lost focus and it doesn't need to rebuild your stuff. It will block that too. Which might be a benefit clearly, since if you're using the resume to control some changes over focus, you only actually care if you need to rebuild that stuff because of focus. Since the pre-draw listeners can only be called by the one thread and they must be called in sequence, the code here will only run once. Until something properly destroys the entire activity and sets resumeblock back to false.

Tatarize
  • 10,238
  • 4
  • 58
  • 64
0

as @TWL said ES File Explorer was the issue for me ! Uninstalling the app solved the problem. When this ES File Explorer was installed, onStart() -> onResume() -> onPause() -> onResume() .. was the problem. onResume() was called 2'ce.

Pramod P K
  • 41
  • 3
0

I had the same problem. Mine was for this code in runtime

setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);

I just put it in manifest

android:screenOrientation="landscape"

no more problem about twice call to onCreate and onResume.

Boris Karloff
  • 1,190
  • 12
  • 20
0

I didn't see an adequate answer to the question, so I decided this.

From My Notes: "It seems that the activity runs onResume() onPause() then onResume again. The very last method that runs is the onSizeChanged(). So a good practice would be to start threads only after the onSizeChanged() method has been executed."

So you could: Make a log of each method that runs. Determine the last method that runs. Ensure that you have a Boolean that initializes false, and only changes to true after your last method runs. Then you can start all threading operations, once you check that the Boolean is true.

-For anyone wondering: I am using a surfaceview that has a onSizeChanged() method that executes very last.

0

I had the same problem because of setting the UiMode in the onCreate() of MainActivity. Changing the theme triggered activity recreation and made two calls to onPause() and onStart().

AndrejH
  • 2,028
  • 1
  • 11
  • 23
0

I was sure this was happening in my app until I realized I had planted two of Jake Wharton's Timber trees, and onResume() was just being logged twice, not called twice.

John Gorenfeld
  • 2,015
  • 1
  • 18
  • 27
-1

i also faced this issue this is because of fragments.. the number of fragments you have in activity onResume() will call that number of times. to overcome i used flag variables in SharedPrefrences

Sanju Baghla
  • 170
  • 1
  • 13
  • Activitie OnResume will be called once anyway, don't confuse with Fragment onResume and Activity OnResume – user924 Nov 24 '20 at 14:30