MiCode/Xiaomi_Kernel_OpenSource: Xiaomi's per-device kernel source branches

What the branch table actually gives you

This is a source distribution, not a product. The README is one long table with five columns: branch, device, Android version, base tag, and link. Each row maps a Xiaomi or Redmi device (often several devices sharing a codename) to a branch in this repository and to the Qualcomm or MediaTek baseline it was built from. A row such as alioth-r-oss covers Mi 10S and Redmi K40 on Android R with base tag LA.UM.9.12.r1-08000-SMxx50.0. A row such as begonia-p-oss covers Redmi Note 8 Pro on Android P with base tag listed simply as MTK.

The audience is narrow and specific: people who need the kernel source for a particular Xiaomi handset, usually because they are building a custom kernel, patching a driver, or checking what a vendor change looks like against a known baseline. The repository answers one question well, which is where the source for device X on Android version Y lives. It does not answer what to do with it afterwards.

Why the same device appears under several branches

Look at Redmi Note 8 Pro and you find begonia-p-oss, begonia-q-oss and begonia-r-oss. Redmi 1S appears as both armani-jb-oss and armani-kk-oss. Mi 8, MIX2S, POCOPHONE F1 and related models appear under dipper-o-oss, dipper-p-oss and dipper-q-oss. The pattern is that a branch corresponds to a device plus an Android release, not to a device alone. Xiaomi rebased the kernel for each major Android version it shipped, so the branch names carry both the codename and the version letter.

That has a practical consequence. If you pick the wrong branch you get a kernel tree for the right hardware running against the wrong Android baseline, and the base tag column is what tells you which vendor drop it came from. Qualcomm rows carry tags like LA.UM.8.12.r1-10600-sm8250.0 or LA.UM.7.1.r1-07600-sm8150.0. MediaTek rows usually just say MTK, which is less useful if you are trying to line the tree up against a specific vendor release. Read the base tag before you clone, not after.

Finding the branch for your codename

The README gives no install procedure, because there is nothing to install. What it gives you is a set of branch links, and the workflow is to open the branch the table points at. The link column is the entry point: for Redmi K40 the table gives the branch alioth-r-oss and a link to it under the repository's tree path.

The table itself is the lookup mechanism. Read down the device column until you find your model, then read across to the branch name and the Android version. Devices with more than one Android release have more than one row, so the codename alone is not enough to pick a branch. The base tag next to it tells you which vendor baseline that branch came from.

Once you have opened a branch, the README does not describe what is inside it. The repository's top level as reported contains only README.md, which is consistent with the actual source living on the branches rather than on the default branch. Nothing in the README states what files a branch contains, so the contents are something you establish by looking, not something the index promises.

The base tag column and what it does not promise

The base tag is the most informative column and the easiest to misread. Qualcomm entries name a specific baseline, for example LA.UM.9.1.r1-06700-SMxxx0.0 for courbet-r-oss or LA.UM.6.2.r1-08100-sdm660.0 for clover-o-oss. Those tags let you compare what Xiaomi shipped against the vendor drop it derived from, which is exactly what you want if you are auditing a driver change or backporting a patch.

MediaTek rows collapse this to the string MTK. For those devices the table tells you the chipset vendor but not which vendor release the tree is based on. If your work depends on knowing the baseline, the README is silent and you have to determine it from the tree itself. That is a real gap in the index, not a detail.

There is also a structural limit: the table is a name index. It records branch, device, Android version and base tag. It does not record kernel version, patch level, whether a branch has been updated since it was created, or whether it corresponds to the current shipping firmware for that device. Nothing in the README states that a branch is maintained after publication.

What the repository is not

It is not a flashable kernel, and it is not a build system. There are no build instructions in the README, no defconfig guidance, no toolchain requirements, no packaging steps, and no flash procedure. You get source. Turning that source into something you can boot requires a compiler setup and a device-specific build process that this repository does not document.

It is also not a complete device tree. If you are looking for the Android side of a custom ROM, the vendor blobs, the device configuration or the recovery, those are separate concerns and the README does not point at them. The branch table is about kernel source only.

Finally, it is not a support channel. There is no issue-triage promise, no changelog, and no release list. The repository metadata reports no releases. If a branch is broken or a device is missing, the README offers no route to report it.

Maintenance: a publication archive, not a development project

The last push to this repository was on 2026-09-20, and the repository is not archived. That is the only maintenance signal available. There is no release history, no changelog and no statement in the README about update cadence, so the fact that the repository received a push recently does not tell you whether any particular device branch is current.

Treat each branch as a snapshot published for a device and Android version, not as a living branch. The practical upgrade cost is that you track the branch yourself: when Xiaomi publishes a new branch for a newer Android release of the same device, it appears as a new row with a new name, as begonia did across P, Q and R. Your work does not migrate automatically, and the README does not describe what changed between those branches.

The licence is not stated in the repository metadata or the README. Kernel source derived from Qualcomm and MediaTek baselines normally carries the vendor's own licensing terms on top of the kernel's, and the base tag column is your only hint about which vendor baseline applies. This is not legal advice; if you plan to redistribute a modified kernel, determine the applicable terms for the specific branch and baseline rather than assuming the repository's silence means anything.

Alternatives and when a different source is the right one

The closest alternative is the vendor baseline itself. If your device row carries a Qualcomm tag such as LA.UM.9.12.r1-08000-SMxx50.0, the CodeAurora release for that tag is the upstream source Xiaomi started from. Going straight to it gives you the unmodified baseline with its own documentation and history. The difference in approach is that the baseline is generic to the chipset, while this repository is the device-specific tree Xiaomi actually shipped, including the changes it made. If you need to know what Xiaomi altered, you need this repository, not the baseline.

The second alternative is a community kernel project for your specific device, which typically ships a build script, a defconfig and a flashable image. That is the opposite trade: you get something you can build and install without assembling a toolchain, but you inherit that project's patch set and its choices rather than Xiaomi's shipping source. If your goal is to modify what Xiaomi shipped, a community kernel is the wrong starting point because it has already diverged.

Choose this repository when the question is what Xiaomi's kernel source for a given device and Android version contains. Choose something else when the question is how to get a working kernel onto the phone.

Editorial conclusion

Adopt this repository if you are building or patching a kernel for a Xiaomi device whose codename appears in the README branch table, and you can identify the Android version and base tag you need. Do not adopt it if you want a flashable kernel, a build system, or a device that is not listed: the repository contains source branches, and the README documents no build or packaging steps. Verify three things before you commit: that the branch name for your codename matches your device and Android version, that the base tag in the table matches the vendor baseline you are targeting, and that the branch actually contains the tree you expect after you clone it, since the README is the only index and it is a table of names.

Frequently asked questions

Official sources

1. Issues
2. MiCode/Xiaomi_Kernel_OpenSource on GitHub
3. README