Introduction

If your Android screen is an Activity styled as a dialog, the method that matters is different from the one used for a plain Dialog or AlertDialog. To stop a dialog-themed activity from closing when the user taps outside it, call setFinishOnTouchOutside(false) in the activity.

This distinction matters because many answers show setCanceledOnTouchOutside(false), which applies to Dialog objects, not to an activity window using a dialog theme. If the thing on screen is actually an activity, use the activity API.

Dialog-Themed Activity Versus Dialog

Android has two related but different patterns:

• a real Dialog or AlertDialog
• an Activity with a dialog-style theme

For a real dialog, you usually write:

dialog.setCanceledOnTouchOutside(false);

For a dialog-themed activity, the corresponding control is:

setFinishOnTouchOutside(false);

Using the wrong API is one of the main reasons this behavior seems inconsistent.

The Correct Activity Solution

Call setFinishOnTouchOutside(false) in onCreate.

1import android.app.Activity;
2import android.os.Bundle;
3
4public class ConfirmActivity extends Activity {
5    @Override
6    protected void onCreate(Bundle savedInstanceState) {
7        super.onCreate(savedInstanceState);
8        setContentView(R.layout.activity_confirm);
9        setFinishOnTouchOutside(false);
10    }
11}

With a dialog-style theme applied in the manifest or style resources, the activity still looks like a dialog window, but outside touches no longer finish it.

What About the Back Button

Outside touch dismissal and back-button dismissal are separate behaviors. Preventing one does not automatically prevent the other.

If the screen must also ignore the back button, handle that deliberately instead of assuming outside-touch settings are enough.

On modern Android, a clean approach is to handle back navigation explicitly in the activity or fragment and decide whether dismissal should be allowed.

For a Real AlertDialog, Use the Dialog API

If you are showing an actual dialog object, the dialog API is still correct.

1AlertDialog dialog = new AlertDialog.Builder(this)
2        .setTitle("Confirm")
3        .setMessage("Do you want to continue?")
4        .setPositiveButton("Yes", (d, which) -> { })
5        .setNegativeButton("No", (d, which) -> d.dismiss())
6        .create();
7
8dialog.setCanceledOnTouchOutside(false);
9dialog.show();

That is the right solution for dialogs, just not for dialog-themed activities.

Choose the Right UI Pattern First

A dialog-themed activity is an older pattern that still exists, but many flows are cleaner with:

• a DialogFragment
• a bottom sheet
• a regular activity or screen with clear navigation

If you are maintaining legacy code, fixing outside-touch dismissal is fine. If you are designing new UI, it is worth checking whether an activity that behaves like a dialog is still the best structure.

User Experience Still Matters

Preventing dismissal can be correct for:

• destructive confirmations
• mandatory decisions
• critical data entry
• authentication or permission gates

But it can also make the app feel rigid if overused. If the user cannot dismiss a window accidentally, make sure there is still an obvious deliberate way to proceed or cancel.

Common Pitfalls

The biggest mistake is using setCanceledOnTouchOutside(false) on an activity and expecting it to work. Another is stopping outside-touch dismissal but forgetting that the back button is a separate path. Developers also sometimes use dialog-themed activities when a DialogFragment or standard screen would be easier to maintain. Finally, a non-dismissible window without a clear cancel or continue action creates a UX problem even if the technical behavior is correct.

Summary

• For a dialog-themed activity, call setFinishOnTouchOutside(false).
• For a real dialog object, use setCanceledOnTouchOutside(false) instead.
• Outside-touch behavior and back-button behavior are separate concerns.
• Make sure the chosen UI pattern still fits the problem.
• Prevent dismissal only when the interaction truly requires it.