2026-All-Brands-Bootloader-Unlock-Status: a device modification tracker, not a tool

A status document that is mostly warnings

The repository is described as a comprehensive summary of the current state of phone bootloader opening and rooting across all brands, covering Xiaomi with MIUI and HyperOS 2.0, Oplus with ColorOS 15 and 16, Huawei, Vivo, Honor, and the situation with Apple iOS jailbreaks. The description calls itself the most complete guide of its kind and emphasises that it is rigorously compiled and rejects outdated information.

What the README actually contains is a wall of urgent warnings rather than a how-to. The opening instruction is blunt: whatever your brand and whatever your chip, do not upgrade your system in any form, followed by references to fuses, monitoring, cloud control, restrictions and anti-fraud measures, and the claim that the more you upgrade the fewer freedoms you get.

A second warning block is aimed at users of VPN software or of modified and cracked applications. It says that regardless of whether you flash your device, your brand or your chip, you should not update your system, and that you should downgrade to the lowest version that can still be downgraded if you can. It then says it is not excluded that cloud control will at some point activate restrictions that were reserved in advance but never switched on.

The tone is worth registering as a property of the source rather than a detail. This is an advocacy document written by someone with a position on device rights, and the position shows through in how the warnings are framed. That does not make the version numbers wrong, but it does mean the document is arguing something while it informs.

The repository is a single README.md plus four dated snapshot files, and it has no releases, no licence recorded and no primary language recorded in the metadata. The last push to the repository was on 2026-10-21.

Four dated snapshots, and why the dates matter

The top level of the repository holds README.md alongside four files whose names are dates: README_26_01_16 .md, README_26_04_05.md, README_26_06_13.md and README_26_08_18.md.

That layout is the most useful thing about the project, and it is a design decision rather than an accident. The subject of the document is a moving target: the status of a given model changes when the manufacturer ships a version that closes the door, and a single README that is edited in place loses the history of when a particular version was still open. Keeping dated snapshots preserves that history, so a reader can answer a question about the past, which is the question most people actually have when they discover an update has already been applied to their device.

The naming is not perfectly tidy. The first snapshot has a space before its extension, README_26_01_16 .md, which is the kind of detail that breaks a build script or a link and suggests the files were added by hand over time rather than generated.

The snapshots also tell you how the situation was moving. The dates run from January through August 2026, and the README's own text refers to updates dated 2026.1.15, 2026.4.5, 2026.6.13 and the note about a 2025.9.1 change, so the content moves on a similar clock to the versions it describes. The most recent snapshot is the one to read, and the earlier ones are there to show the direction of travel.

The vocabulary, and what a fuse actually means here

The document uses a small set of terms repeatedly, and reading them is a prerequisite for reading the entries.

The central one is the fuse, rendered in the original as a permanent, irreversible event. When a manufacturer ships a version that closes bootloader modification for a given model, the README calls it a fuse, and the claim is that once a device has taken such an update, the state is permanent and cannot be reversed. The language used is strong, describing a destructive, irreversible fuse that leaves the phone unable to boot any previously released package at all, including the stock system, because a low-level partition carries an irreversible anti-rollback mechanism, and attempting to install anything after that turns the device into a brick instantly.

The reason a fuse is possible is described in the entries. A boot chain has a signed configuration region, and once a version is burned into it, the bootloader refuses to accept anything signed by an earlier key, which is the mechanism behind both the fuse and the anti-rollback behaviour that makes downgrading impossible after the fact.

The second concept is the emergency download path, referred to by its platform number as the 9008 mode, which is a Qualcomm service mode reached through a diagnostic interface. The document tracks, per model, whether that path still works without an authorisation code, and treats the loss of that ability as serious, because in a case where the device is bricked and the authorised service centre cannot help, the owner may have to physically remove a component to recover it. That is the reason the fuse is treated as severe: it is not only that modification is closed off, it is that the recovery path closes with it.

The third term is the depth test, which is a manufacturer programme through which an owner applies to be granted the permission to enter fastboot on certain models, and the document tracks the approval thresholds for that programme per model.

What the per-model entries actually record

The visible portion of the README covers OnePlus, and the structure of the entries is consistent enough to describe.

Each entry opens with the threshold for opening the bootloader on the China region version, then gives the firmware version limits, and then lists model-specific warnings. The threshold for the current generation is that the device must be approved through the depth test programme before it can be opened, and the entry warns that later firmware revisions may add restrictions and block the downgrade route that depends on it.

The model warnings are the substantive part. They name individual devices and the exact build number at which they were affected, for example the January 2026 firmware revisions listed for a range of handsets and tablets. They also record exceptions, such as the devices where a one-click method still works if the fuse has not been taken, and the specific pair where the fuse is permanent and unrecoverable.

The entries distinguish between two different mechanisms, and that distinction is the most technically interesting thing in the document. Some models carry a detectable fuse, where reading a signed configuration region tells you whether it has been taken, and the document states that a problem in that region guarantees a fuse while the absence of a problem does not guarantee safety. Other models use a hidden fuse, where there is no way to detect it in advance, which is why the document says such a fuse cannot be anticipated. The tools that claim to check for fuses are described as unreliable for that second class, and the advice given is simply not to update.

The same entries carry forward-looking warnings, such as the claim that a future kernel-level mechanism was introduced in a later build to target users who had avoided the fuse by modifying particular partitions, and that the tools marketed as protection against fuses cannot save you from it.

How the document is maintained, and how to reach the author

There is no code, no test suite, no issue tracker convention for corrections and no release process. The repository is a document that is rewritten.

The contact route is the standard one for a GitHub repository. The README says to use the built-in Issues feature, notes that the Issues option is at the top of the screen and works on both phone and computer, and says that a GitHub account can be registered without a phone number if you do not have one. It mentions email contact for those who prefer it, while saying that it is not ready yet and asking readers to wait patiently, and it says the author is collecting opinions on whether to provide free unlocking tools for the mainstream models mentioned, so that newcomers can use them more easily.

The document also names a community group for obtaining tools and instructions for specific models, with the caveat that joining the group may be a problem and that the reader should contact the author if they know how it works. That is a reasonable disclosure to make in a document of this kind, and it is also the point at which the project stops being information and starts being a referral.

For the sake of clarity about what this repository is: it is a community-maintained claim register. Each line is a report about a device and a firmware version, and the README gives no test procedure, no command transcript and no reproduction steps for any of them. That is a meaningful limitation for a document whose central claim is that a particular build permanently bricks a phone, and it is the reason the article above stops at describing the entries rather than reproducing them.

Where this tracker is the wrong tool

Three cases point elsewhere. The first is anyone who wants the tooling. The repository is a pointer list, and for several models it points outward for the methods and the utilities, including through a community group. If your question is how to perform the modification, you need documentation of the method rather than a register of whether it is still possible.

The second is a reader who needs a verified answer rather than a community claim. The document is explicit that the information is compiled from community reports, and it carries forward dates and version numbers without a test harness behind any of them. For a decision that can permanently brick a device, a claim with a specific version number is more useful than a vague one, but it is still a claim, and the reader has to decide how much weight to put on it.

The third is a reader outside the Chinese market or outside the OnePlus and Oppo ecosystem whose models are not in the document. The stated coverage is broad, but the visible entries in detail are for the Chinese-region OnePlus devices, with separate sections for the other brands further down, and the specific thresholds, depth test conditions and fuse versions are per model and per region. A device sold elsewhere may be on a different firmware track entirely, and the document's own instruction not to update your system is written for the region and models it describes.

The alternative worth comparing is the manufacturer's own documentation for your specific model, paired with the community forums for that model, and the difference in approach is about the level of specificity and the level of trust. The manufacturer's own page for opening the bootloader tells you the official route and the current requirements, and it is the authoritative source for what is permitted, though it is also the source with an interest in keeping the door closed. A per-model forum thread is a community claim too, but it is a claim about a narrower question, with a discussion attached that shows other people hitting the same wall. This tracker is the broad version of the community claim, and its value is that it is dated and comparative across models, which is exactly what you want when you are trying to work out whether an update you have not yet installed is worth avoiding.

Editorial conclusion

This repository fits a device owner who has just read that an update might close the door on custom firmware and wants a per-model, per-version answer rather than a forum search. It does not fit anyone looking for the tooling itself, since the repository ships no code and points outward for that, and it does not fit a reader who needs a verified reference, because the entries are unverified community claims with no test procedure attached. Before you act on any line in it, check the version number in the entry against the version on your own device, and treat the four dated snapshot files as a history rather than a single current answer.

Frequently asked questions

Official sources

1. AdaUnlocked/2026-All-Brands-Bootloader-Unlock-Status on GitHub
2. Issues
3. README