Why is runnable callbacks destroying activity automatically?

Question

I wanted to know if there is a possibility that we could handle/detect runnable callbacks with delay (postDelayed method) on android?

For example, I have one or several splashscreen (which runs with handler.postDelayed(new Runnable()...) on my application (application for testing purpose). In this application I have also a library (that I am creating and using it in the application) and some classes that are available there which runs on an IntentService class.

Sometimes, when the application is running those splashscreen Activities (for Testing purpose), the library that I am creating, might popup some activities automatically in the UI. But it appears that if those activities comes on a splashscreen activity and that the splashscreen is being destroyed, those activities (that popup automatically) will also be destroyed and logging a "leaked window" message in the logcat.

The problem is that :

• those activities that appears automatically in the UI should not be closed automatically, this is prohibited. It needs an interaction from the user for closing that activity and returns to the normal behaviour of the application.
• Also, the library doesn't know anything about the UI of the application.

So my questions are (relatively to the library side that I am creating without having informations to the flow of the UI application):

• Is there a way to detect if some postDelayed method was created in the application relatively to the Library side ? If yes, how could I handle the problem ?

P.S.: Notice that normally, I am using a Dialog for the suppose Activity who is appearing automatically.

UPDATE

Explanation of the diagram :

Right now I have a case that a Splashscreen is being executed.

The class which extends the IntentService class, has received a Request from internet which will start an Activity.

Meanwhile the splashscreen is on postdelayed, the other Activity has been created and is showing in the UI. When X seconds has passed and the other Activity hasn't been destroyed, the Next Activity is created and destroy the other Activity automatically. In doing that, Android throws a "leaked window" message relatively to the Activity.

Answer 1

Is there a way to detect if some postDelayed method was created in the application relatively to the library side?

You can make use of MessageQueue.IdleHandler API. See LooperIdlingResource how espresso finds out whether it is appropriate time to fire in assertion.

    @Override
    public boolean queueIdle() {

      QueueState queueState = myInterrogator.determineQueueState();
      if (queueState == QueueState.EMPTY || queueState == QueueState.TASK_DUE_LONG) {
        ...
      } else if (queueState == QueueState.BARRIER) {
        ...
      }

      return true;
    }

This will help you to understand whether there is a message in the MessageQueue, but it won't tell you what exact message is there.

The solution I'd go with would be to unschedule the Runnable that you have postDelayed within onStop of the activity, because if Activity (the one from library) has been launched, than onStop of SplashScreen is being called:

public class SplashActivity extends AppCompatActivity {

  private final Runnable myRunnable = () -> {
    // launch `NextActivity`
  };
  private final Handler handler = new Handler();

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

    handler.postDelayed(myRunnable, 3000);
  }

  @Override
  protected void onStop() {
    super.onStop();
    handler.removeCallbacks(myRunnable);
  }

}

Answer 2

You need to explain the problem better. I'm confused between the relation of the splash screen and the other activities, and if the problem is related to postDelayed() or to the activities lifecycle. I'd suggest a tiny graphic diagram explaining which activities launch other ones.

Regarding postDelayed(), In general, if you do

 mHandler.postDelayed(new Runnable() { ... });

You are posting an anonymous, fresh runnable everytime, so you won't be able to remove it. I'd suggest the following approach, declaring the Runnables as class members inside your library:

Runnable mLaunchSplashRunnable = new Runnable() { ... };
Runnable mLaunchContactsRunnable = new Runnable() { ... };

.
.

mHandler.postDelayed (mLaunchSplashRunnable, DELAY);
mHandler.postDelayed (mLaunchContactsRunnable, DELAY);

.
.

As runnables are now not anonymous, you can remove them from the queue anytime:

void removeLibraryDelayedRunnables() {
   mHandler.removeCallbacks(mLaunchSplashRunnable);
   mHandler.removeCallbacks(mLaunchContactsRunnable);
}

Note the previous method won't fail if there aren't any posted runnables, so it is safe to call it anytime.

A method to query the Handler if a specific Runnable is queued, afaik, does not exist, but you can maybe use a boolean flag, set it when the runnable is queued, and reset it when the Runnable is run, to indicate a runnable is pending.

If I understand your problem better I'd be able to help more.

Answer 3

The problem is that once you start firing activities one after another, after some time when your application has consumed lot of memory, so android assumes that previous activities can be destroyed to optimize system and avoid slow down of device, this is how mobile devices works, so your main activity which is consuming API is destroyed by system: please understand activity life cycle:

https://developer.android.com/guide/components/activities/activity-lifecycle.html

see after onStop()...this is the case with your app.

Hope this will help you...

Answer 4

Why don't you use static boolean variable to determine whether your Splash Screen is running or not when you are about to call it.

Answer 5

I think you should rather invert logic in the program. The activity should be started from your activities, not from the service.

To achieve that you can register BroadcastReceiver on creation of each activity https://developer.android.com/reference/android/content/BroadcastReceiver.html and use sendBroadcast from the service https://developer.android.com/guide/components/broadcasts.html when starting an activity is needed, to command the broadcast receiver to start needed activity.

Answer 6

Using a callback with a temporally coupled activity may not be a very good design for your SDK. Consider using observables to get data from the network layer to an activity that needs the data.

By adding an observer to the activity that needs the data, which watches to see if the network call is done, you only expose the data to an observer that is active. This way, if the activity is closed before the call is complete, there is no "pushing" of the data to the closed activity.

This also allows you to create weak references to your library in a way where you do not need to worry about leaking windows

Answer 7

Since we didn't see your code yet. My answer is going to be too generic, so sorry for that.

I think you should first check out logcat to see if there is any exception going on that closing those activities. If there is nothing about it. Just check for all the try catch blocks to be sure about it. So after you are sure that it is not about any exceptions of any kind, check for the AndroidManifest file to see 'Launch Modes' of activities. It could lead automatic closing as well.

If all your activities are in a standard mode then try to change at least one activities launch mode to disable it from closing and try again. If this doesn't make any sense as well, check the code for finish() calls.

Still no luck? Then i guess this could be a case of ANR you should check for memory leaks that freezes your application and probably closing down activities. Probably those runnables are somehow ruining your application.

I think you should have a mechanism like eventbus or broadcast receiver for internal communication in between your screens. They will run on the lifecycle of your activities and would not lead to any kind of exception or anr.

Answer 8

Activities can get destroyed any time, so when this happens you need to take care of the dialogs that are being destroyed too. In the lifecycle of the Activity you will need to destroy the "Dialogs" too else you will get the "Leaked Window".

Also the Dialogs that reference the Activities would benefit from using a weakReference to the Activities, you would then use the weak reference to report the users actions to the activity.

@Override
public void onAttach(Activity activity) {
    super.onAttach(activity);
    listener = new WeakReference<>((MyActionListener) activity);
    activityWeakReference = new WeakReference<>(activity);
}

Before showing a Dialog I would also make sure the Activity is not in the process of finishing:

if (myActivityWeakReference.get() != null && !myActivityWeakReference.get().isFinishing()) {
  // show dialog
}

Then when you want to control rotation of the device, where the Activities get re-created you can use the following together with your dialogs:

    @Override
public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setRetainInstance(true);
}

/**
 * Prevent the dialog being dismissed when rotated, when using setRetainInstance
 */
@Override
public void onDestroyView() {
    if (getDialog() != null && getRetainInstance()) {
        getDialog().setDismissMessage(null);
    }
    super.onDestroyView();
}