# BGASwipeBackLayout-Android: edge swipe back from a patched SlidingPaneLayout

> BGASwipeBackLayout-Android gives Android activities an edge swipe back gesture, including a WeChat style variant, by shipping a modified copy of the support-v4 SlidingPaneLayout and driving it from a base activity. The setup is small, and the two failure modes the project documents are both worth reading before you adopt it.

**bingoogolapple/BGASwipeBackLayout-Android** — Android Activity 滑动返回。支持微信滑动返回样式、横屏滑动返回、全屏滑动返回

- Repository: https://github.com/bingoogolapple/BGASwipeBackLayout-Android
- Stars: 2,302 · Forks: 308
- Language: Java
- License: not declared
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/bingoogolapple-bgaswipebacklayout-android

## A patched SlidingPaneLayout rather than a touch interceptor

The repository describes itself as an Android activity swipe back library supporting the WeChat style, horizontal orientation and full screen swipes, and the feature list names the mechanism in a single clause: the swipe back layout is implemented by modifying the source of SlidingPaneLayout from the support-v4 package. The rest of the API follows from that decision. SlidingPaneLayout is the container that ships inside the support library and later inside androidx, built to slide one pane aside to reveal another. This project takes a modified copy of that class and lets an activity's own content play the role of the sliding pane, so the drag is resolved by a layout that already knows how to track a finger, decide whether to settle, and animate the result, rather than by code that intercepts raw touch events and repaints the window. That is why the delegate is shaped the way it is: a slideOffset from 0 to 1 while dragging, a cancel callback when the drag falls short, and an executed callback when it completes. It is also why the tuning surface talks about pane behaviour, a release threshold, a shadow resource id and a shadow alpha gradient, since those are the knobs this class of layout already exposes.

## Adding the jitpack coordinate and calling init in Application.onCreate

Installation runs through jitpack, so two edits happen before any of your own code changes. Add the repository to the root build.gradle, then add the dependency in the app module. The block below is the README's own snippet, placeholder included, and two details in it need attention. The trailing latestVersion is not a coordinate. The README says it stands for the version named in the badge it links beside that line, and that you substitute it yourself. The second line is the support-v4 artifact, carrying a comment that asks you to replace it with the version your own project already depends on, which is a sensible instruction given that the library ships a modified copy of a class that artifact also contains. If your build resolves a different support-v4 version from the one the library was built against, the patched class and the one your app compiles can end up being different code, and the README does not document which versions it has been checked against. After the dependency resolves, the one piece of setup code the README calls mandatory is the init call, and it has to sit in Application.onCreate:

```java
public class App extends Application {

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

        /**
         * 必须在 Application 的 onCreate 方法中执行 BGASwipeBackHelper.init 来初始化滑动返回
         * 第一个参数：应用程序上下文
         * 第二个参数：如果发现滑动返回后立即触摸界面时应用崩溃，请把该界面里比较特殊的 View 的 class 添加到该集合中，目前在库中已经添加了 WebView 和 SurfaceView
         */
        BGASwipeBackHelper.init(this, null);
    }
}
```

The first argument is the application context. The second is a collection of View classes, passed as null in the README's own example, that matters for the crash described further down. If you would rather see the behaviour first, the README links a prebuilt demo apk at fir.im/BGASwipeBackLayout.

## What a BaseActivity has to supply and which defaults it inherits

Everything else happens in your own base activity. The helper must be constructed before super.onCreate, and the activity has to implement BGASwipeBackHelper.Delegate. The block below is the initialisation method as the README writes it. The setters in it are a tour of the interface rather than configuration you need, since each one documents the default it would have had anyway: enabled, left edge tracking only, WeChat style, and a release threshold of 0.3f. Because the helper is constructed per activity, those values are per activity as well, and one screen can opt out entirely by overriding isSupportSwipeBack. What the base class has to get right is the ending. When the drag passes the threshold, the executed callback calls swipeBackward, and when the back button is pressed, the overridden onBackPressed returns early if a slide is in progress and otherwise calls backward. The activity is therefore finished through the helper rather than through the default transition, which is the behaviour the feature list summarises as working with a non-transparent theme without affecting the activity lifecycle.

```java
    private void initSwipeBackFinish() {
        mSwipeBackHelper = new BGASwipeBackHelper(this, this);

        // 「必须在 Application 的 onCreate 方法中执行 BGASwipeBackHelper.init 来初始化滑动返回」
        // 下面几项可以不配置，这里只是为了讲述接口用法。

        // 设置滑动返回是否可用。默认值为 true
        mSwipeBackHelper.setSwipeBackEnable(true);
        // 设置是否仅仅跟踪左侧边缘的滑动返回。默认值为 true
        mSwipeBackHelper.setIsOnlyTrackingLeftEdge(true);
        // 设置是否是微信滑动返回样式。默认值为 true
        mSwipeBackHelper.setIsWeChatStyle(true);
        // 设置是否显示滑动返回的阴影效果。默认值为 true
        mSwipeBackHelper.setIsNeedShowShadow(true);
```

```java
    @Override
    public void onSwipeBackLayoutExecuted() {
        mSwipeBackHelper.swipeBackward();
    }

    @Override
    public void onBackPressed() {
        // 正在滑动返回的时候取消返回按钮事件
        if (mSwipeBackHelper.isSliding()) {
            return;
        }
        mSwipeBackHelper.backward();
    }
```

## Why a transparent theme shows the Launcher during the swipe

The first entry in the README's FAQ describes a symptom most adopters will meet early: with a transparent theme, the swipe back reveals the Launcher. The cause is not in the gesture. A translucent activity has nothing opaque behind it, so as the current view slides away the system draws whatever sits behind the task, and behind the task is the home screen. The fix the README gives is on the theme side rather than inside the library: make sure the activity at the bottom of the stack is opaque. The demo shows exactly how that situation arises. It opens in a SplashActivity, that activity is destroyed once the main interface appears, and MainActivity becomes the bottom of the stack, which is why the README singles that one out as needing an opaque theme. The cost of the design is now visible. A swipe back that works without a translucent theme obliges you to audit whatever sits at the base of every task in the app, and any screen whose design depends on translucency has to opt out by overriding isSupportSwipeBack rather than by adjusting its theme.

## Why the first touch after a non-transparent swipe can crash

The second FAQ entry covers the opposite theme case. With a non-transparent theme, the application can crash when the screen is touched immediately after the swipe back ends. The remedy is to add the class of the unusual View on that screen to the collection passed as the second argument of BGASwipeBackHelper.init, and the README offers a map control as the sort of view that needs it. WebView and SurfaceView are already registered inside the library, so adding them again is explicitly unnecessary. The shape of that fix has two consequences. The registry is keyed by class type and lives in one global call in Application.onCreate, so it can only be complete if you know every third party view your app puts on screen, and it cannot be narrowed to the single activity that has the problem. The failure also arrives as a crash on a touch rather than at build time, which means the screens that break are the ones holding such a view, not the ones you exercised. The README's own instruction is to read the comments on every method of BGASwipeBackHelper, comments only, before relying on any of this.

## StatusBarUtil, setIsNavigationBarOverlap and the gesture conflicts in the demo

The opening line of the README recommends pairing the library with StatusBarUtil, a separate utility for setting the status bar style, and repeats that recommendation three times for emphasis. The reason is visible in the settings rather than stated outright: the feature list claims full screen and horizontal orientation support, and the helper exposes a shadow resource, a shadow alpha gradient and setIsNavigationBarOverlap, whose default of false keeps the bottom navigation bar out of the sliding area. The demo adds a small set of sibling libraries, BGABaseAdapter-Android, BGAProgressBar-Android, BGARefreshLayout-Android and BGASwipeItemLayout-Android, which places the gesture inside an ordinary list driven app rather than as a standalone effect. Two of the README's recordings pair the back gesture with a swipe to delete list and with a RecyclerView, which are exactly the layouts where a horizontal drag belongs to the row rather than to the screen edge. The library exposes no switch for that conflict beyond setIsOnlyTrackingLeftEdge, so a screen that needs horizontal item gestures has to resolve it by keeping the back gesture on the edge.

## Last push on 2026-07-11, distributed through jitpack, with no declared licence

The repository is not archived and the last push was on 2026-07-11, so the code is recent rather than frozen, though that is the only maintenance signal on offer, since the project publishes no GitHub releases and CHANGELOG.md is the sole historical document at the top level. Distribution runs entirely through the jitpack coordinate described earlier, which means choosing a version means reading a badge rather than consulting a release list. Licensing is the open question. No licence is identified for the repository, and the top-level file list holds no LICENSE entry alongside .gitignore, CHANGELOG.md, build.gradle, gradle.properties, gradlew and the library and demo modules. For an app taking this as a binary dependency there is no grant text inside the repository to point at, and what the patch to the copied SlidingPaneLayout actually changes is not described in the README, only hinted at by a link to BGASwipeBackHelper. The build itself is a two module Gradle project with the wrapper checked in, so the library is also available as ordinary source if you decide to read the helper line by line.

## Conclusion

Adopt BGASwipeBackLayout-Android if every screen in your app already passes through a BaseActivity, because the work is one helper construction plus a single call in Application.onCreate, and the drag is resolved by a patched SlidingPaneLayout rather than by a new gesture stack. Skip it if you cannot guarantee an opaque theme on whatever sits at the base of each task, since the Launcher showing through is a theme problem the library will not solve for you, or if your app carries custom views whose class types the library knows nothing about, since the crash fix is a hand maintained class list in one global call. Verify three things before committing: the version named in the jitpack badge, the legacy-support-v4 version your build already resolves, and one manual swipe on the screen that holds your map or video view.

## FAQ

### Why does the Launcher appear during the swipe back when my theme is transparent?

A translucent activity has nothing opaque behind it, so the system shows the home screen as the view slides away. The fix the README gives is on the theme side: keep the activity at the bottom of the stack opaque. In the demo, SplashActivity is destroyed before MainActivity runs, so MainActivity is the one that must be opaque.

### What do I pass as the second argument of BGASwipeBackHelper.init?

Pass a collection holding the classes of unusual View types, such as a map control, on screens where touching the interface right after a non-transparent swipe back causes a crash. WebView and SurfaceView are already inside the library and must not be added again. The README's own Application example passes null.

### Which versions do I need for the jitpack dependency and legacy-support-v4?

Add the jitpack repository to the root build.gradle, then replace the trailing latestVersion in the coordinate with the version named in the linked badge. The README also asks you to use the support-v4 version your project already depends on instead of copying 1.0.0, and it does not state which versions the library has been checked against.

### Does BGASwipeBackLayout-Android publish releases, and is it still being changed?

There are no GitHub releases, so versions come from the jitpack badge rather than from a release page. The repository is not archived, and the last push was on 2026-07-11. CHANGELOG.md is the only change history the top-level file list contains.

## Sources

- [bingoogolapple/BGASwipeBackLayout-Android on GitHub](https://github.com/bingoogolapple/BGASwipeBackLayout-Android)
- [Issues](https://github.com/bingoogolapple/BGASwipeBackLayout-Android/issues)
- [README](https://github.com/bingoogolapple/BGASwipeBackLayout-Android/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bingoogolapple-bgaswipebacklayout-android