Introduction

Yes, you can disable user-driven swiping on a ViewPager. The usual solution for the original ViewPager is to subclass it and stop it from intercepting or handling touch events, while ViewPager2 has a built-in isUserInputEnabled switch.

Disable Swiping in the Original ViewPager

The classic ViewPager handles horizontal paging by intercepting touch gestures. If you want to keep programmatic page changes but block user swipes, override the touch methods.

1import android.content.Context;
2import android.util.AttributeSet;
3import android.view.MotionEvent;
4
5import androidx.viewpager.widget.ViewPager;
6
7public class NonSwipeableViewPager extends ViewPager {
8
9    public NonSwipeableViewPager(Context context) {
10        super(context);
11    }
12
13    public NonSwipeableViewPager(Context context, AttributeSet attrs) {
14        super(context, attrs);
15    }
16
17    @Override
18    public boolean onInterceptTouchEvent(MotionEvent ev) {
19        return false;
20    }
21
22    @Override
23    public boolean onTouchEvent(MotionEvent ev) {
24        return false;
25    }
26}

Then use NonSwipeableViewPager in your layout instead of the regular widget.

The pages can still be changed in code:

viewPager.setCurrentItem(2, true);

That is useful for wizard-style flows where you want the app to control navigation with buttons rather than with gestures.

If your pager hosts fragments, this approach still works because the fragment adapter and page lifecycle remain unchanged. You are only blocking gesture-driven page changes, not disabling the pager's content management.

Why Both Methods Matter

onInterceptTouchEvent controls whether the ViewPager takes over the gesture from its children. onTouchEvent controls whether the ViewPager handles the gesture itself.

Returning false from both methods blocks paging behavior while still allowing the rest of the layout to function normally.

If child views need to receive touches, this approach is usually what you want. If you only disable one method, the interaction can become inconsistent.

ViewPager2 Makes This Easier

If your project uses ViewPager2, the API is simpler because there is a built-in property:

viewPager2.isUserInputEnabled = false

That disables swipe gestures while still allowing:

viewPager2.setCurrentItem(1, true)

So if you are starting a new screen, ViewPager2 is generally the easier component to control.

When Disabling Scrolling Is a Good Idea

This pattern is common in:

• onboarding flows with required steps
• forms that should advance only after validation
• pages controlled by tabs or buttons
• temporary states where paging must be locked during loading

The important design question is whether gesture disabling improves the flow or just hides navigation from the user unexpectedly.

If the screen still needs manual navigation, pair the disabled pager with explicit controls such as Next, Back, or a tab strip. That keeps the flow predictable and prevents users from feeling trapped on a page after swipe gestures disappear.

Common Pitfalls

• Overriding only one touch method and getting inconsistent gesture behavior.
• Disabling swiping but forgetting that users still need some other way to move between pages.
• Using the old ViewPager subclass approach in a ViewPager2 project where isUserInputEnabled already exists.
• Blocking gestures globally when the real problem is that one child view has a touch conflict.
• Forgetting to preserve programmatic navigation when the UI still needs to advance pages in code.

Summary

• You can disable scrolling on the original ViewPager by subclassing it and returning false from the relevant touch methods.
• Programmatic navigation with setCurrentItem(...) still works after swiping is disabled.
• 'ViewPager2 provides a simpler built-in solution through isUserInputEnabled = false.'
• Use this pattern when navigation should be controlled explicitly rather than by swipe gestures.
• Always provide an alternative navigation path if you disable user scrolling.