LeviLauncher: an Android launcher for Minecraft Bedrock Edition

A launcher that runs the APK you already have

LeviLauncher is described as a lightweight, open source Android launcher built for legitimate players of Minecraft Bedrock Edition, and it positions itself as a flexible and user friendly alternative to the standard Google Play installation.

The core mechanism is the first feature in the list: APK import and installation free launching. You import the official Minecraft APK and the launcher runs it directly, without a system installation. So the game is not installed as an app on the device in the usual sense; it lives inside the launcher's own storage, and the launcher starts it.

That is what makes the rest of the design possible. Because the game is not installed system wide, the launcher can hold more than one copy of it, and the second feature is multi-version management with version isolation: several Minecraft versions are managed independently, with separated configurations and data.

The third feature is native module loading. The launcher can load external native shared object modules to extend or enhance Minecraft features and performance, which is the mechanism that mods use on the Java edition, brought to the Bedrock side.

The fourth and fifth are the account and content management. Multiple Xbox accounts can be held inside the launcher and switched between seamlessly, and there is a built-in manager for resource packs and worlds with import, export, and backup.

The project is Apache 2.0 licensed, the documentation site is at a separate domain from the repository, the last push was on 2026-10-18, and the release history is in the 1.5 line with three releases in the second half of October 2026 alone, so this is a project under active development rather than one that has been left alone.

What the requirements say, and the one about the licence

The system requirements section is short and worth reading closely, because two of the entries decide whether the launcher will run at all.

The operating system has to be Android 9.0, which is API level 28, or higher. The device architecture has to be ARM64, the 64 bit variant. The memory minimum is 1 GB of available RAM, with 2 GB or more recommended. And the storage minimum is 2 GB for the game and its data.

Then there is the recommendation, which is higher than the minimum in both directions: Android 9.0 or higher with at least 3 GB of available RAM and 5 GB of free storage, for optimal performance and stability. The gap between the two is a sign of how demanding a Bedrock instance is, and it is the kind of detail that decides whether a device is a good candidate.

And then the requirement that is not a specification but a condition of use: you must own a licensed copy of Minecraft Bedrock Edition purchased from Google Play.

The installation section repeats it as a prerequisite, and adds the part that matters in practice, which is that the licence has to be valid and properly linked to your Microsoft account. The launcher is a way of running the game you bought, in a configuration you control, and it is not a way of obtaining one.

That distinction is repeated in the installation notes, which say not to use the launcher with pirated or unauthorised versions of the game. For a project that loads native modules into the game process, the distinction is more than legal formality: the launcher has no way to verify what it is being asked to run, so the responsibility sits with the person running it.

Installing it on a phone, step by step

The installation is the standard route for any application distributed outside a store, and the readme walks through it in six steps.

You visit the releases page and download the latest APK build. Then you open the device settings and go to security, or to applications, depending on how the manufacturer has arranged it. There you enable unknown sources, or the option to allow installation from unknown sources, which is what permits an APK to be installed outside the store. Then you locate the downloaded file with the file manager and tap it to install. You grant the permissions that are requested while the installer runs. And then you open LeviLauncher from the application drawer.

Two details are worth noting. The settings path varies by manufacturer, so the readme gives two possibilities rather than one, and the permission step is a decision the user makes rather than something the installer does silently.

The permission grant is worth a second look for a different reason. A launcher that starts the game from inside its own storage, and that can load native modules into that process, is an application with a lot of authority. The permissions it asks for are the ones a launcher of this kind needs, and the readme does not enumerate them, so the actual list is something a user sees on their device rather than something documented here.

For anyone who wants to read ahead, the readme's own advice is that the launcher is for legitimate players and that the official app must already be installed on the device from Google Play, which is what the import step later reads.

Building it from source

The development setup is the part of the readme that tells you what the project is made of, and it is short.

You need Git, Android Studio with the latest version recommended, a Java Development Kit at version 21 or higher, and the Android SDK with API level 28 or higher. The readme also lists the build step, which is to use the Make Project option rather than a full rebuild, and says that for faster builds during development you should compile incrementally instead of doing full rebuilds.

The workflow is the standard Android Studio one. Clone the repository, open the project directory in the studio, allow it to download and install the required dependencies and build tools, wait for the initial Gradle sync to complete, connect a device or start an emulator at API 28 or higher, and press run. The app launches when the build succeeds.

git clone https://github.com/LiteLDev/LeviLaunchroid.git

The repository layout gives the same picture. There is an app directory, which is the launcher application itself, a minecraft directory, a controls directory named after the PojavLauncher project, a resources directory, a scripts directory, a docs directory, and an examples directory with two entries, one of them a full native module written in C++ and the other a mod menu example. There is also a submodules configuration, which means parts of the tree come from elsewhere.

That examples directory is the most useful thing in the repository for a new contributor, because it shows the two shapes that the native module feature has to support. A full native module is the complete form, with its own build and its own entry point, and the mod menu example is the smaller integration that a module uses to present itself inside the game.

The contribution guidelines, and what they assume

The contribution section is written for a community project and says what kind of contributions are wanted, in five parts.

On code quality, the expectation is clean, modular code with descriptive variable names and consistent formatting, following the Kotlin and Java style guidelines established in the project, and the reason given is readability and structure for future maintainers.

On commit structure, small and focused commits with clear messages, each addressing a single feature or bug fix, and the two examples given are a memory leak fix in the version manager and the addition of ARM32 architecture support.

On documentation, comments for complex logic, and an update to the readme and the related documentation files when a feature is added.

On performance, the instruction is to optimise additions to maintain low latency and smooth performance, and to test changes so they do not introduce lag or performance regressions. For a launcher that is starting a game process, that is the right emphasis, because a launcher that adds half a second to the start is a launcher people stop using.

On testing, changes should be tested on multiple devices and Android versions, for compatibility and stability, which is a reminder that the launcher sits between an Android version and a game version, and both move.

And on pull requests, a detailed description of the changes, including the problem solved or the feature added, referencing any related issues.

The licence is Apache 2.0, which is the permissive one and a deliberate contrast with the ecosystem it comes from, where the neighbouring launchers tend to be closed.

Editorial conclusion

LeviLauncher fits a Bedrock player who wants several game versions side by side, who wants to test a modification and then undo it, or who wants the resource packs and worlds under one manager rather than scattered through the system storage. It does not fit a device that is not on Android 9 or a 64 bit ARM build, and it does not fit anyone without a licensed copy of the game, because the launcher exists to run the official app you bought rather than to obtain one. Verify first that your device meets the memory and storage minimums, which the project recommends be higher than the stated minimum, that the Minecraft account is linked and valid, and that the modules you load come from a source you trust, because native code runs with the full rights of the app it is loaded into.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. LiteLDev/LeviLaunchroid on GitHub
3. Project website
4. README
5. Releases