Open-source project
openandroidinstaller-dev/openandroidinstaller avatar
openandroidinstaller-dev/openandroidinstaller

OpenAndroidInstaller: a guided installer for alternative Android builds

Makes installing alternative Android distributions nice and easy.

527 stars36 forksPythonGPL-3.0

At a glance

What is it?
OpenAndroidInstaller is a Python and Flet desktop application that walks a user through installing LineageOS and other free Android builds on a supported device, handling the ADB steps, the recovery image and the flashing sequence. It is GPLv3 licensed, shipped as binaries and a Flatpak, and the README states plainly that the project is not actively maintained.
Who is it for?
OpenAndroidInstaller suits a user who wants to install a free Android build without following scattered command line instructions, since it turns the ADB and flashing sequence into a step-by-step tutorial tied to a specific device and ships as a binary or a Flatpak.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 46 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What the project is for

OpenAndroidInstaller makes installing alternative Android distributions nice and easy, and the README expands on the intent: it helps Android users keep their smartphone's operating system up to date with free software, and to continue using the device even though the manufacturer no longer offers updates.

That framing places it in a specific niche. Flashing a custom Android build is not hard for someone who knows the procedure, but the procedure is long, device-specific and unforgiving. You need the right bootloader unlocking command for your model, the right recovery image, the right image filename convention, and a set of ADB invocations in a specific order. Every device has its own quirks, and the knowledge is scattered across wiki pages and forum threads.

This application is a front end for that procedure. After starting it you are prompted to plug your device in, and you are given a step-by-step tutorial for installing the new OS on your specific device. So the value is not a new capability, it is the removal of the lookup work and the error handling.

The project is GPL-3.0 licensed, the primary language is Python, the homepage is openandroidinstaller.org, and the topic list names the platforms and the domain: android, customrom, rom, twrp, twrp-recovery, lineage-os, lineageos, linux, windows, macos and hacktoberfest.

Two warnings sit at the top of the README and both should shape your expectations. The first says the application is currently not actively maintained, everything is provided as is, and nobody should expect bugfixes or new features for now. The second says it is in beta state, use at your own risk, and while many people have tested it and no bricked devices have been heard of, things might still go wrong.

The DRM warning, which is the part to read first

The README has an IMPORTANT block about bootloader unlocking, and it is more specific than the usual warnings about wiping data.

Unlocking the bootloader will erase all data on your device. That also includes your DRM keys, which are stored in the Trim Area partition, also called TA, in case your device is fairly recent and supports DRM L1. Those devices will be downgraded to DRM L3. Devices on DRM L3 by default will not be affected.

The consequence for the user is concrete and unpleasant: a phone that played HD streaming before flashing may stop playing it afterwards. On Sony Xperia 1 and 5 series phones, DRM L1 will return once the bootloader is relocked, which is a narrow escape hatch.

The README also notes that depending on your device you might be able to back up the TA partition using exploits and gaining temporary root access, which is a description of how hard the workaround is.

Before proceeding, ensure the data you would like to retain is backed up to your PC or your Google account, or equivalent. And there is a warning that OEM backup solutions like Samsung and Motorola backup may not be accessible from LineageOS once installed, so backing up to the vendor's own cloud before flashing can lock you out of that route afterwards.

This is the kind of irreversible consequence that a guided installer should be honest about, and the README is.

Platform support and how to get it

Linux is currently the best supported platform, tested with Ubuntu 20.04 and 22.04 LTS. Windows and macOS are also supported, but you might experience more issues. ARM-based systems are not supported at all.

The download route is the GitHub releases page. The executables are compressed inside .zip files, so you have to extract them first, and you may be prompted to adjust the permission of the executable to ensure it works. On Windows you might also need to install the Universal USB Drivers and other drivers your device needs.

For Linux there is a Flatpak, org.openandroidinstaller.OpenAndroidInstaller, published on Flathub. The repository also carries the Flatpak manifest at the top level, named org.openandroidinstaller.OpenAndroidInstaller.json, so the packaging is in-tree rather than in a separate repository.

The two later steps in the usage section are not the application's job. You download the custom ROM yourself, and the README links official sources for BlissRoms, CalyxOS, /e/OS, GrapheneOS, LineageOS and LineageOS for MicroG, plus TWRP recovery and the optional add-ons, which are different Google Apps packages such as MindTheGapps and NikGApps, MicroG with a note that the recommended way to install MicroG is from the .zip file in the MinMicroG-abuse-CI releases, and the F-Droid privileged package. It also notes that you can just search the web or the XDA Developers forum to find a version for your device.

So the application is the procedure engine and the tutorial, and the ROM and recovery images come from wherever you trust.

The device list and what best effort means

The officially supported devices section says the project supports 88 devices by various vendors and is working on adding more. Support for these devices is provided as best effort, but things might still go wrong, and the project asks for help by reporting issues.

The list is organised by vendor in collapsible sections with a table of vendor, device name, codename, models and status. Fairphone 2, 3 and 4 appear under Fairphone with a link to the LineageOS device wiki for each codename. Google devices follow, with Pixel 2 through Pixel 4 and beyond, each row carrying the codename and a link to the LineageOS wiki entry.

The status column is the interesting part and it is honest about being a work in progress. The Fairphone and Pixel entries visible in the README are marked tested rather than supported, and the wording of the surrounding text qualifies the whole list as best effort.

That is a meaningful distinction for anyone deciding whether to install. A device listed as tested means someone has run the procedure and it worked for them, not that the procedure is guaranteed on every unit of that model, because battery state, firmware revision and carrier variant can all change the outcome.

For a device that is not on the list, the tools still exist. You would be running the ADB and flashing steps by hand, and the application will not have the device-specific instructions for it, which is exactly the value the tool adds.

How the tool is built

The dependency list in pyproject.toml describes the stack, and the choice of flet is the headline. The dependencies are click for the command line, flet for the graphical interface, pyinstaller for packaging the application, Pillow and PyYAML for images and configuration, loguru for logging, requests for network access, regex and schema for validation, py7zr for archive extraction, requirements-parser for parsing requirements files, flet-desktop-light for the desktop build, and certifi for certificate authorities.

The Python constraint is narrow and worth noting: python = ">=3.11,<=3.12.3". That is a two-release window rather than a floor, and it is enforced again in requirements.txt, where every pinned dependency carries the markers python_version >= "3.11" and python_full_version <= "3.12.3". The hash-pinned requirements file is generated by poetry export, which the Makefile has a target for.

The dev tooling is standard and thorough: black for formatting, ruff for linting, isort for import ordering, pre-commit, pytest with pytest-cov for coverage, pytest-mock, bandit for security linting, pytest-subprocess for testing subprocess calls, and mypy for typing.

The runtime dependencies also explain a lot about how the application works. requests is there to fetch ROM images and add-ons, schema and regex to validate the device and image metadata, py7zr to unpack the archives, and Pillow for image handling. The application is therefore a controller that talks to adb and fastboot, downloads and unpacks artefacts, and drives the device through a scripted sequence.

Working in the repository

The Makefile is the quickest way to understand the workflow, and its targets are short. The install target removes the openandroidinstaller/bin directory, installs with poetry including the dev group, runs scripts/download-tools.py and then installs the pre-commit hooks:

make
install:
	rm -rf openandroidinstaller/bin
	poetry install --with dev
	poetry run python scripts/download-tools.py
	poetry run pre-commit install

The script that downloads tools is doing something that matters: the application needs external binaries to talk to a phone, and those are not committed.

Running the application locally is a single target, poetry run python openandroidinstaller/openandroidinstaller.py, and there is a test-app variant that passes --test and --test_config sargo, which is a way to exercise the interface against a known device profile without a phone attached.

The other targets are the quality gates. format runs black, lint runs ruff check on the openandroidinstaller directory ignoring E501, typing runs mypy with --ignore-missing-imports, and test depends on format and lint before running pytest with coverage, with PYTHONPATH set to the package directory. Building the distributable is poetry run python scripts/build.py.

The repository also carries a requirements.txt with hashes, a poetry.lock, resources/ and scripts/ directories, a tests/ directory, a Makefile, and org.openandroidinstaller.OpenAndroidInstaller.json for the Flatpak build. The project is GPLv3, and the pyproject.toml names the author as Tobias Sterbak.

Where OpenAndroidInstaller is the wrong tool

Three limits are structural. The first is the finite device list, and it is the same limit as the tool's value. The application knows how to drive a device it has been taught about, and for the 88 listed models it has device-specific instructions. For anything else, you are back to the manual procedure, and using the application would only get you as far as the generic steps.

The second is the maintenance warning, which is the most important line in the README for anyone considering depending on this. The project is not actively maintained, everything is provided as is, and no bugfixes or new features are expected for now. For a tool that flashes a phone, that means a bug report will not be fixed, and it means the underlying assumptions, the ADB invocation formats and the ROM download URLs, can drift out of date with no announcement. New Android versions change how unlocking works, and this tool will not track them.

There is also the beta status on top of the maintenance warning, and the two together are the honest summary: this is a working tool with a finite life.

The third is the risk profile of the operation itself. The tool does the right thing in guiding you through unlocking a bootloader, which erases the device and can downgrade DRM, and no amount of UI quality removes that. The README's advice to back up to your PC or your Google account before proceeding is the operative instruction, and the warning that OEM backup solutions may become inaccessible from LineageOS afterwards is the kind of detail that only matters if you read it first.

The alternative approach is the manual procedure with a LineageOS wiki page and the ADB and fastboot documentation, which is more work but which you control and which does not depend on a project that has stopped. The difference in approach is that the application encodes a device's steps as data that a maintained project would keep current, and that data is now frozen. For a device on the tested list and a ROM you already have downloaded, it still saves real time. For anything else, the wiki route is the safer one.

Editorial conclusion

OpenAndroidInstaller suits a user who wants to install a free Android build without following scattered command line instructions, since it turns the ADB and flashing sequence into a step-by-step tutorial tied to a specific device and ships as a binary or a Flatpak. It is the wrong tool for an unsupported device, since the supported list is finite and its entries are best effort, and it is the wrong tool for anything expecting ongoing support, since the README states the application is not actively maintained and expects no bugfixes. Verify first that your device is in the supported list before downloading anything, and note that the newest release is v0.5.5-beta from 2025-07-01 with the last push on 2026-09-07.

Frequently asked questions

What does OpenAndroidInstaller do?

It is a Python and Flet desktop application that guides users through installing free Android operating systems such as LineageOS on a supported device, handling the ADB and flashing steps with a step-by-step tutorial. The project states the goal is helping users keep their device on free software after the manufacturer stops providing updates.

Which platforms does OpenAndroidInstaller support?

Linux is the best supported platform, tested with Ubuntu 20.04 and 22.04 LTS, while Windows and macOS are supported but may have more issues. ARM-based systems are not supported, and a Flatpak version, org.openandroidinstaller.OpenAndroidInstaller, is available on Flathub.

Is OpenAndroidInstaller still maintained?

No. The README opens with a warning that the application is currently not actively maintained, that everything is provided as is, and that no bugfixes or new features are expected for now. It is also stated to be in beta state and to be used at your own risk.

What happens to DRM keys when I unlock the bootloader?

Unlocking erases all data including the DRM keys stored in the Trim Area partition on recent devices, so devices supporting DRM L1 are downgraded to DRM L3, while devices already at L3 are unaffected. On Sony Xperia 1 and 5 series phones DRM L1 returns once the bootloader is relocked.

How many devices does OpenAndroidInstaller support?

The README states that the project supports 88 devices by various vendors, with the device list organised by vendor in tables giving vendor, device name, codename, models and status. Support is provided as best effort and things might still go wrong.

How do I set up the OpenAndroidInstaller development environment?

Run make install, which removes the bin directory, installs the project with poetry including the dev group, runs scripts/download-tools.py to fetch the external binaries, and installs the pre-commit hooks. The Makefile also has app, test-app, format, lint, typing, test and build-app targets.

Official sources

  1. License: GPL-3.0
  2. openandroidinstaller-dev/openandroidinstaller on GitHub
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/openandroidinstaller-dev-openandroidinstaller.svg)](https://hysenlabs.com/projects/openandroidinstaller-dev-openandroidinstaller)

Was this useful?