open-video-editor does five things to a clip on Android, and nothing else

The feature list is five operations on a clip

The whole feature set fits on one line of the README: trim, grayscale, resolution, scale and rotate. That is the honest scope of this application, and it is worth judging it on that basis rather than as a budget version of a full editor. There is no timeline, no sequence of clips, no transition between shots, no audio track and no text overlay in the documented list. What you get is a set of single clip adjustments, which covers a real need: shrinking a long recording for sharing, rotating a clip shot sideways, cutting the dead part off the start, or stripping colour down. The name of the project, Open Video Editor, invites a broader reading than the README supports, and anyone evaluating it for a production pipeline should assume the feature surface is exactly that list.

Kotlin, Compose and Media3 on a Gradle build

The project description gives the stack: it is an open source Android video editor built with Media3 and Jetpack Compose. The primary language is Kotlin, and the repository root is a standard Gradle project with build.gradle.kts, settings.gradle.kts, a gradle directory, gradle.properties and the wrapper scripts gradlew and gradlew.bat for Unix and Windows. The application code sits under an app directory, which is the convention for a single module Android application, and lint.xml at the root holds the lint configuration. Those choices tell you what to expect from the codebase rather than from the interface. Media3 is the media stack that handles playback and the export path, and Compose is the modern declarative Android UI toolkit, so the editor screens are built as composables rather than as XML layouts.

Four channels install the same application

The README offers four ways to get the app, and they differ in more than convenience. The first is a direct link to the latest GitHub release, which is the option that gets you the newest tagged build without a store in the middle. The second is IzzyOnDroid, an alternative Android app catalogue, which tracks upstream builds rather than waiting for a store review. The third is Google Play. The fourth is F-Droid, the free software catalogue that builds from source. The application identifier is the same everywhere, io.github.devhyper.openvideoeditor, so the four channels are alternative distributions of one program rather than differently named forks. For a reviewer this gives a concrete way to compare the same code path served from different pipelines, and for a user it means the choice is about trust and update speed rather than about features.

Store listing artwork and screenshots are versioned in the repository

The metadata directory holds the assets that every store submission needs, and the naming is explicit about it. There is a featureGraphicDark.png under the English locale images folder, which is the promotional image used in listings, and a phoneScreenshots directory containing eight numbered device screenshots. The assets directory holds the badge images that the README links to for the download buttons, including the Google Play badge and the F-Droid badge. Publishing to four channels means keeping the version metadata consistent across them, and putting the artwork under version control is the practical way to do that, since a screenshot in a pull request can be reviewed like any other change. The README also points at a Weblate project for translations and at the GitHub milestones page for the roadmap, so community translation is treated as a normal part of the workflow rather than an afterthought.

The newest tagged build is from 2024 while commits continue

The release history is short and it has not moved recently. v1.1.1 was published on 2024-03-17, v1.1.2 on 2024-04-27, and v1.1.3 on 2024-09-02. The repository itself is not archived and the last push was on 2026-08-26, which means development continued after that last tag. The gap matters in a practical way, because the README's primary install button points at the latest GitHub release, so a user who installs from that link gets the 2024 build rather than whatever is on the default branch. Whether the unreleased work is worth tracking depends on what the milestones page lists as in progress, and the repository has no newer tag to inspect. Anyone depending on this app in a pipeline should treat v1.1.3 as the current released version and check the commit history separately, rather than assuming the freshest source equals the freshest binary.

GPL-3.0 and a privacy policy in the repository root

The licence is GPL-3.0, with a LICENSE file at the repository root, and a PRIVACY_POLICY.md sits beside it. For a mobile application distributed through app stores and as an APK, the copyleft terms are the part to read carefully before you redistribute a build or base further work on the code, and this paragraph is not legal advice. The presence of a dedicated privacy policy is a useful signal for a video editor, because a tool that touches media files on a device usually raises questions about what it collects and whether anything leaves the phone. What the policy says is not visible in the repository listing, so it has to be read in the file itself, and the same goes for how the Google Play build and the F-Droid build differ in any data handling, since the README describes them only as channels.

A full timeline editor is the alternative when the job is bigger

The honest alternative for anything beyond single clip adjustments is a general purpose non linear editor, whether on a desktop or on a phone, and the difference in approach is structural rather than cosmetic. A timeline editor treats your footage as a sequence: you place clips in order, cut between them, layer audio, and shape the result as a piece with a beginning and an end. This project takes a different shape entirely. You hand it one clip, you apply one of five operations, and you get a result. That makes it quick for the narrow job and the wrong shape for assembly work, because there is nothing in the documented feature list to sequence clips with. The other alternative is command line tooling on a workstation, which suits batch work on a server but removes the on device, store installed path this project offers. Choose by the shape of the job, not by the price of the tools.

Editorial conclusion

Adopt open-video-editor if you want to trim, rotate, scale or adjust resolution and grayscale of a clip on a phone without signing into an account, and you are comfortable sideloading an APK from GitHub releases or F-Droid. Do not adopt it for multi clip editing, audio work or a creative timeline, since the documented feature list is five operations and no sequence. Before installing, check whether the build you would actually get is v1.1.3 from 2024-09-02 while the last commit landed on 2026-08-26, and read PRIVACY_POLICY.md and the GPL-3.0 terms to decide whether the Google Play build fits your distribution and privacy expectations.

Frequently asked questions

Official sources

1. devhyper/open-video-editor on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases