Pie Launcher: an Android home screen built around a pie menu

The design replaces the icon grid rather than extending it

Pie Launcher is an Android home screen launcher that uses a dynamic pie menu instead of tables of icons, and the README is clear that this is a replacement rather than an addition.

The pitch is muscle memory. Once you get used to it, you can launch your most frequently used apps using muscle memory without even looking at the screen. The pie menu appears on a long press, and you swipe to choose the app, so the gesture itself carries the selection and the radial layout means the target is always in the same place relative to your thumb.

The secondary path handles everything else. Apps you do not use regularly are quickly available with just one tap and by typing the first one or two letters of the app name. So the design splits the task in two, with a small set of frequently used apps on a fast spatial path and a search path for the long tail.

That is the whole concept, and it is a narrow one. There is no icon grid to scan, no folders, and the README does not mention widgets. The primary language is Java, the licence is MIT, the app is on F-Droid and Google Play, and the release history shows steady work: version 1.28.0 on 2026-07-15, 1.27.0 on 2026-07-10 and 1.26.5 on 2026-06-25, with the last push on 2026-10-05.

Four gestures cover everything the launcher does

The usage guide in the README is four short sections, and each one is a single gesture.

To use the pie menu, you tap and hold to open it, then swipe to choose an app to start. The guide has an SVG diagram for it, which is a reminder that the visual metaphor is doing real work here, since the pie menu is not a standard Android interaction.

To open the app list, you tap once, and then type the name of an app you want to start. Usually one or two letters are enough, even if you mistyped a letter, and if the app in the top left is the one you want, you can hit the Search key on your keyboard to start it. That last detail is a nice touch, because a launcher that can be driven entirely from the keyboard is usable with a screen reader or a switch device in a way that a swipe-only gesture is not.

To close the app list quickly, you swipe down.

To edit the pie menu, you long press an app in the listing of apps to enter the editor for the pie menu, and the guide tells you to use 4, 6, or 8 icons in the pie menu to make the most out of it. The fixed set of sizes is a design decision: the radial layout has a natural number of slots for a given radius, and 4, 6 and 8 divide the circle evenly.

There is one more entry point, which is a recent Android feature rather than a gesture. Private space is a new feature in Android 15, and if you have enabled it on your device, you use a dot in the app search to open and access it.

The troubleshooting section is a list of Android bugs it works around

The most honest part of this README is the troubleshooting section, and it is essentially a list of platform problems that every third party launcher inherits.

There is a short delay after doing the home gesture, and the README states plainly that this is an Android bug that Google needs to fix, and that all third party launchers suffer from it. It links the discussion on Reddit, the homescreen interaction delay with gesture navigation thread, the follow-up thread about home gesture animations with third party launchers, and a Nova Launcher tweet from 2019. The suggested workaround is to use the back gesture instead of the home gesture wherever possible, with the caveat that this may not be desirable in a browser app since it also closes the open tab. The back gesture works immediately and without any delay.

The launcher is unresponsive right after the device is unlocked. On some devices the home screen appears frozen, with taps producing haptic feedback but the pie menu not opening. The README calls this a known Android bug affecting all third party launchers, linking an issue tracker entry. It occurs when another app, for example Assistant, Tasker, or an incoming call, controls the display while the screen is off, causing Android to skip the initial draw of the launcher's window at that point.

The workaround here is in the launcher's own code. Pie Launcher works around this by forcing a redraw when the window regains focus, and if that does not help on your device you can enable Force relaunch in the settings, which fully recreates the home screen on each restart. That setting is the nuclear option, and it exists because the redraw fix is not sufficient everywhere.

Two more issues that are not the launcher's fault

The remaining troubleshooting entries are brief and are about other applications.

The soft keyboard takes too long to appear. The README attributes this to an issue with the keyboard app that may do too much work, and says that GBoard is not the best choice for all devices, with a recommendation to check for a lighter alternative keyboard. That is a fair assessment of a launcher that opens a search field on every single tap, because on a slow keyboard the whole app list flow feels broken.

Home returns to the default launcher. The instruction is to set Pie Launcher as your default home screen launcher, and there are two routes. You can do it manually from the phone's Settings, then Apps, then Default apps, or from the settings within Pie Launcher, where you enter the editor and tap the settings icon, and there should be an item called Make default launcher.

That second route is the more useful one, because it is a one tap fix from inside the app, and it tells you the launcher is aware that a user who has just installed a home screen replacement will hit this within a minute of the first home press.

The pattern across the section is consistent: three of the four entries are platform or keyboard problems, and the launcher either works around them or tells you plainly that it cannot.

Building it is a Gradle project with adb targets in the Makefile

The Makefile in the repository root wraps the Gradle build with a set of adb-driven targets, and the naming tells you how the project expects to be worked on.

The default target is all, which chains debug, install and start. The debug target runs the Gradle assembleDebug, and there is a lint target running lintDebug, a release target that depends on lint and runs assembleRelease, and a bundle target for assembleRelease. There is also an infer target that cleans and runs the infer static analyser over the Gradle build.

The install and start targets are where the Makefile becomes an Android workflow rather than a build wrapper. The install target pushes the debug APK with adb install -r, and the start target launches it with am start against the debug package and its HomeActivity. There are matching uninstall and meminfo targets, the latter running dumpsys meminfo, plus a clean target that runs the Gradle clean.

One target is a curiosity. The avocado target runs avocado over the files under app/src/main/res that contain a vector element, which suggests a project convention of checking that vector drawables meet some rule, enforced by a tool named after a fruit.

The repository layout is a standard Gradle Android project with an app/ module, build.gradle and settings.gradle at the root, a gradle/ directory and the gradlew wrapper with its batch counterpart. There is a fastlane/ directory for store metadata, given the screenshot paths under fastlane/metadata/android/en-US/images/phoneScreenshots, an svg/ directory holding the guide diagrams, and standalone files for CHANGELOG.md, CONTRIBUTING.md, LICENSE, PRIVACY.md and SECURITY.md.

How a pie menu compares to the standard launcher

The alternative is the stock Android launcher, or one of the established third party ones, and the difference in approach is a bet about where the time goes.

A grid launcher optimises for discovery. The icons are all visible, the layout is stable, and finding an app you use once a week is a scan of a known position. It also spends a lot of screen space on apps you almost never open, and the cost of that is the swipe and the small target, and the mental question of where a given app was.

A pie menu optimises for the frequent case. If you open four apps a hundred times a day, a fixed radial arrangement where each target is always in the same place removes the visual search entirely. The argument in the README is that you can do it without looking at the screen at all, which is a real benefit on a phone you pick up hundreds of times.

The cost is the long tail. Everything not on the pie goes through the tap-then-type path, which is fast for a name you can type but slower than a glance for a name you cannot. It also means the pie needs to be curated: the guide tells you to use 4, 6, or 8 icons, so the set of promoted apps is small and deliberate.

And the platform tax is real, as the troubleshooting section documents. A launcher that is not the stock one inherits every Android home gesture bug, and the maintainer is documenting three of them as known issues. For a daily driver that is an acceptable trade for some people and a dealbreaker for others.

Editorial conclusion

Adopt Pie Launcher if you launch a small set of apps dozens of times a day and want them reachable without looking at the screen, and you are on a device where the home gesture delay does not bother you. Do not adopt it if you rely on home screen widgets, folders, or a dense icon grid, since the design replaces the grid rather than extending it. Before you install, read the troubleshooting section, because the launcher works around two known Android bugs, and set it as the default home app from the settings inside the launcher or the home button will keep returning to the stock one.

Frequently asked questions

Official sources

1. License: MIT
2. markusfisch/PieLauncher on GitHub
3. Project website
4. README
5. Releases