7

I have a simple activity without UI. I wanted to check the lifecycle methods of an activity during call.

When a notification for call arrives, nothing happens as expected. When I accept the call, then the activity for call is covering up on my activity. So, ideally onStop() should be called immediately. I have checked the logs and only onPause() is being called while accepting the call. But after 2-3 seconds onStop() is also being called.

Activity

public class MainActivity extends AppCompatActivity {

    private static final String TAG = "MainActivity";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

    @Override
    protected void onStart() {
        super.onStart();
        Log.e(TAG, "onStart: ");
    }

    @Override
    protected void onStop() {
        super.onStop();
        Log.e(TAG, "onStop: ");
    }

    @Override
    protected void onPause() {
        super.onPause();
        Log.e(TAG, "onPause: ");
    }

    @Override
    protected void onResume() {
        super.onResume();
        Log.e(TAG, "onResume: ");
    }
}

Manifest

   <activity android:name=".MainActivity">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />

            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>

Logs

05-17 22:10:25.025 E/MainActivity: onStart: 
05-17 22:10:25.054 E/MainActivity: onResume: 


When call has been accepted:
05-17 22:10:34.405 E/MainActivity: onPause: 

After 2-4 seconds:

05-17 22:10:38.144 E/MainActivity: onStop: 

As per the documentation of onStop() :

Called when you are no longer visible to the user. You will next receive either onRestart(), onDestroy(), or nothing, depending on later user activity.

Here, the other activity is covering my activity and hiding it. So, onStop() should be called instantly after onPause().

I have tested it on Moto G4 device and Nexus 5 emulator. Both are showing same behavior. What is the reason of delayed onStop() call?

Can anyone explain the internal details?

Screenshots call is running

Krupal Shah
  • 8,949
  • 11
  • 57
  • 93

5 Answers5

3

Based on the documentation:

After receiving onPause() call you will usually receive a following call to onStop() (after the next activity has been resumed and displayed), however in some cases there will be a direct call back to onResume() without going through the stopped state.

Although the documentation for onStop() is a bit perplexing, which claims to call it as soon as Activity is no more visible but there is a slight delay before it gets called (it depends on next activity being displayed).

In case where you receive a call, there is a trivial delay caused after call enters foreground. I have observed this delay on my personal phone too. This delay will cause the onStop() call to be delayed.

Sagar
  • 23,903
  • 4
  • 62
  • 62
  • I just wanted to know the internal details of that 'trivial delay'. Without a source, we should not simply assume the delay. – Krupal Shah May 24 '18 at 19:02
  • 1
    @KrupalShah this delay is caused by the Phone app. It might be trying to load the microphone and/or the output sound (connecting to bluetooh headphone if connected) which could take some time. Since its internal to the phone app, we cannot exactly pin point what causes the delay. – Sagar May 25 '18 at 02:31
0

When I accept the call, then the activity for the call is covering up on my activity. So, ideally onStop() should be called immediately.

Receiving a call does not remove the activity from the task's stack, and will be available when you re-enter the app => onPause() => onStop().

So that's why onStop is not immediately called after the call has been received.

Quoting from Official Documentation

If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations

nimi0112
  • 2,065
  • 1
  • 18
  • 32
0

If you are opening activity B on top of activity A, this is how the lifecycle would be

  1. onPause of activity A is called
  2. onCreate of activity B is called
  3. onStart of activity B is called
  4. onResume of activity B is called onStop of activity A is called(with exception of partially visible activity)
  5. In case of low memory onDestroy of activity A can also be called

As you can see there are a lot methods called in between onpause and onstop of the activity A, hence the delay

Suhaib Roomy
  • 2,501
  • 1
  • 16
  • 22
0

The sequence is predictable and documented in Starting one activity from another

Coordinating activities :

Here's the order of operations that occur when Activity A starts Activity B:

  1. Activity A's onPause() method executes.
  2. Activity B's onCreate(), onStart(), and onResume() methods execute in sequence. (Activity B now has user focus.)
  3. Then, if Activity A is no longer visible on screen, its onStop() method executes.

Basically the appearing activity is created and fully initialized between the onPause() and onStop() callbacks on the disappearing one. It may take some time, and the onStop() method may even not be called at all, for example if the new activity use a dialog style (and thus the old one is still partially visible)

bwt
  • 17,292
  • 1
  • 42
  • 60
0

I think this has more to do with the way the call display is implemented. onPause is invoked when your activity no longer has primary focus in the foreground, but is still technically "visible". onStop is invoked when your activity is no longer visible at all.

It is possible for two activities to have a visible state, which would result in only onPause being called for the activity without focus. By displaying the call view on top of your activity, it's possible for your activity to still be "visibile" without being completely gone. Hence why onPause is called, but not onStop.

Dan 0
  • 914
  • 7
  • 15