OS Updater pulls OxygenOS and ColorOS builds past the staged rollout queue

Staged rollout queues leave phones on old builds for weeks

OPPO, OnePlus and realme ship firmware updates through a staged rollout. The update reaches a percentage of devices first, then widens. If your device falls outside the early wave, you wait, sometimes for a long time, and there is no way to move yourself to the front of the queue from the stock updater. OS Updater exists to remove that wait. The README states the aim in one line: skip staged rollout queues and update your OPPO/OnePlus device ASAP.

The audience is therefore not developers looking for a general Android updater. It is owners of a specific set of devices who want a specific firmware build sooner. The repository description puts it as a third-party app that lets you skip rollout queues and update your OPPO/OnePlus/realme device ASAP, and the topic list names the platforms it targets: ColorOS, OxygenOS, OnePlus, realme and Android.

The implementation is Kotlin, and the repository layout is a standard Gradle Android project. There is an app directory, a root build.gradle.kts and settings.gradle.kts, a gradle wrapper with gradlew and gradlew.bat, a gradle directory, a bump.sh script, and a .github directory holding the CI workflow that the badge in the README title refers to. The whole thing is an Android Studio project, which means the realistic way to build it is Android Studio with the SDK installed.

The app is not a sideloaded experiment. It ships through the Google Play Store, and the README describes it as quick, easy and free. That distinction matters, because an update tool that needs privileged access on a modern Android phone has to earn the user's trust through a store listing, not only through a download link.

Play Store bundles and GitHub APKs, built from the same commit

The README is unusually firm about where builds come from. It names two places where new versions are published, the Google Play Store and the GitHub releases page, and says all others should not be trusted. The Play Store carries Android App Bundles and GitHub carries APKs.

The two channels are described as completely identical except for format differences, since they are built on the exact same codebase and commit. The usual order is a Play Store release first, with a 100 percent rollout target, and a GitHub release shortly after.

The project recommends the Play Store, and the reasons it gives are practical: much smaller download sizes, auto-updates including in-app updates, and Play Protect. The app is free, so the argument is not about price but about the friction of getting a build onto a phone that has to talk to a vendor server to install it.

One reassurance for people who install the APK anyway: installing via GitHub still supports auto-updates via the Play Store. The user does not have to choose between the small download and the automatic updates, only between the two places to get the first install from.

The release history is short and recent: v7.1.0 published on 2026-04-25, v7.0.0 on 2026-04-16 and v6.8.1 on 2026-03-26. The README badge for the latest release is pinned to v7.1.0.

Building it locally needs a Firebase project and a keystore

The development section gives the toolchain, and it is worth following exactly, because two pieces of configuration are required before anything compiles.

The first is Firebase. The README states that the app uses Google and Firebase APIs, so app/google-services.json needs to exist, and for development purposes you need to create your own Firebase project. That file is not in the repository, so a fresh clone will not build until you point it at a project you control.

The second is signing. Running non-debug variants of the app requires two things: generating a Java KeyStore and referencing it in keystore.properties. The KeyStore can be created in Android Studio through the Generate Signed Bundle / APK flow, or through the keytool command line instructions the README links to. The file itself is a properties file with four fields in the project root directory:

storePassword=<store-password>
keyPassword=<key-password>
keyAlias=<alias>
storeFile=<jks-location>

One path detail is called out. If you saved the JKS file in the app directory, storeFile does not need to be an absolute path, because it is relative to app.

The SDK levels are also pinned in the documentation. The app targets API 37, which the README calls Android 17, with a minimum API level of 23, Android 6 Marshmallow, and you are told to make sure both SDK platforms, and optionally sources, are installed via SDK Manager. The development table recommends Android Studio in its latest stable version, with any other IDE or even a text editor listed as alternatives, and it warns that extra tools such as ADB and the SDK Manager may need to be installed separately if your editor does not bundle them.

A real device is required, because the interesting features need root

The development table recommends an Android device and lists the Android emulator as the alternative, with a note attached: emulators generally perform worse than a real device, even with accelerators, and you will not be able to test the app's root-related features.

That sentence tells you what the app actually does under the hood. It touches root-related functionality on the device, which is what allows it to see and trigger updates outside the normal stock updater path. It also explains why the Play Store route matters commercially. A root-aware updater on a locked phone is a different proposition from the stock updater, and the store listing is how the project reaches people who would never install a sideloaded APK.

The emulator limitation follows from the same fact. The features that distinguish the app cannot be exercised on an emulator at all, so a developer without a physical OPPO, OnePlus or realme handset cannot verify the core behaviour of their change. That is a real constraint on contributions: bug reports from real devices are what the project wants, and the CI badge in the README title indicates an automated workflow, but automated checks cannot confirm that an update was pulled from the vendor server.

The device matrix also narrows the test surface. Code paths for other Android vendors, or for the same vendors on different OxygenOS and ColorOS versions, are only reachable on the matching hardware.

No licence, default copyright, and a trademark in the app name

The licensing section is the part of this project that deserves the most attention, and it is the opposite of what most open source repositories do. The README states plainly that the repository has no license, that default copyright laws apply, and it quotes GitHub's explanation that without a licence nobody may reproduce, distribute or create derivative works from the work.

The owner position is stated as well. For legal purposes, the owner of the organisation, named as Adhiraj Singh Chauhan, is considered the owner of the project and of all its associated files and build outputs, including APKs and AABs. Contributors agree to transfer copyrights to the owner, with two exceptions: code owners share ownership of their file and are usually marked with the @author annotation, and any source file carrying its own licence information overrides the repository default.

The practical effect is narrower than an ordinary open source licence and harder to work around. You can view and fork the repository, submit pull requests and raise issues, in accordance with GitHub's terms of service, but you are not permitted to redistribute or modify the source code or the build outputs without explicit permission. That covers the obvious commercial case of shipping a fork, and it also covers the grey area of a self-compiled build you distribute to a few friends.

If your intent is to read the code, patch it for your own phone, or contribute translations, none of that is in question. If your intent is to base a product on it, the answer is that you need to ask the owner first, and the README points to a Discord server and a support email for exactly that.

What a contributor actually touches, and what the project asks for

The contributing section is short. The README says all help is welcome and points to CONTRIBUTING.md in the repository for code or translations, and the top level entries confirm that guide exists alongside a CODE_OF_CONDUCT.md and a PULL_REQUEST_TEMPLATE.md.

Translations are called out explicitly as an area where help is welcome, which is the natural entry point for a contributor without an Android device, since the app is translated rather than merely localised. There is a bump.sh script at the root of the repository, which by its name suggests version bumping is scripted rather than manual, and the CI badge in the README title points at a workflow file in the .github directory.

Two governance files are worth reading before your first pull request. CODE_OF_CONDUCT.md sets the expectations for conduct, and PULL_REQUEST_TEMPLATE.md tells you what a good submission looks like before a maintainer reviews it. Given the copyright transfer clause in the licensing section, a contributor should also know that the @author annotation is the mechanism that marks code ownership, since it is the exception that preserves a co-owner's rights in the file they wrote.

The project also documents its own storefronts as the trusted sources and warns that all others should not be trusted. That warning applies to contributors as much as users: a build from anywhere other than the Play Store or the GitHub releases page is not a build this project vouches for.

Maintenance and the limits of what the app can do for you

The repository is not archived. The last push was on 2026-04-25, the same day as the v7.1.0 tag, and the two releases before it were published on 2026-04-16 and 2026-03-26. The README does not summarise what changed in 7.1.0, and it points at the GitHub releases page instead, so the release notes there are the place to read about behaviour changes.

The limits of the tool are more important than its maintenance state. It is an updater for OPPO, OnePlus and realme devices. If your phone is from another vendor, there is nothing to skip and nothing to wait for, because these vendors do not use this rollout mechanism in the same way. The app also targets API 37 with a minimum of API 23, so an older phone is out of scope on both ends.

The alternative approach for the same problem is the vendor's own channel. If you are willing to wait for the staged rollout, the stock updater does the same job with no third-party app, no root-related behaviour and no trust decision. The value os-updater adds is entirely in timing and in the device coverage where the stock path is slow, and if you are not in that situation, installing it adds risk without adding function.

There is also the plain fact that this is a third-party client for a vendor's update service. It depends on the vendor's endpoints and on the device side of the protocol, so when a vendor changes its update mechanism, a third-party updater is the first thing to break. That is an acceptable trade for a phone you own, and a bad trade for anything else.

Editorial conclusion

Use OS Updater if you own an OPPO, OnePlus or realme phone and the staged rollout queue has been leaving you on an old build for weeks; the app is published on the Play Store and as an APK on the GitHub releases page, and the two are built from the same commit. Do not adopt it as a codebase to ship in your own product, because the repository carries no licence, default copyright laws apply, and contributors are asked to transfer copyright to the project owner. Before contributing, read the contributing guide, create your own Firebase project so app/google-services.json exists in your checkout, and keep the JKS file out of version control, since the repository is configured to ignore all JKS files.

Frequently asked questions

Official sources

1. Issues
2. oxygen-updater/os-updater on GitHub
3. Project website
4. README
5. Releases