android-locker: a community map of bootloader unlock policies

A comparison hub for unlock status, not a how-to guide

The project describes itself as a comprehensive, community-maintained hub for comparing bootloader unlock, kernel source and warranty policies across major Android manufacturers, and the README headline is Android Manufacturer Bootloader Unlock Status. The word hub is the accurate one. This is not a guide to unlocking a bootloader, it does not contain the tools to do it, and the topics list has a single entry, android and bootloader, with no tooling language or technique tags. It is a reference table that answers three questions per manufacturer: whether unlocking the bootloader is possible, whether the manufacturer publishes kernel source, and what the warranty position is. That third question is what separates it from the community lists that already exist, because unlocking a bootloader is often a decision made with a warranty in mind, and the policy sits next to the technical facts. The audience is a buyer or an enthusiast trying to work out whether a device is worth modifying, and the way the project is built reflects that audience, a fast browsable site rather than a tool.

Three kinds of data, and where they come from

The references section is short and honest, and it is the most useful part of the README for anyone assessing the data. There is a reference to the MobileModels Bootloader and Kernel Source List, a community document, and a reference to the Android Verified Boot Documentation on source.android.com, in the section on device state and the user settable root of trust. A third line simply says other reference sites are listed on the website, which is an admission that the list of sources is longer than the two links in the readme. The Android verified boot documentation is the anchor for the vocabulary, because the state of the bootloader, the root of trust and the unlock state of a device are the concepts the table is built on, and a reader who needs the precise meaning of a column should read that document rather than the table. The community list is the source for the per-manufacturer facts, which is exactly the point at which the data's age becomes the thing to check. The README does not describe a review cadence, a per-row source link or a policy for stale entries, and that omission is the practical limitation of the project.

A static Vite and React site, deployed by GitHub Actions

The implementation is a modern static site, and choosing that stack is a deliberate fit for a data table. The package manifest is the standard Vite React and TypeScript template named vite_react_shadcn_ts, with Tailwind for styling, a shadcn style component layer built on Radix primitives, TanStack Query for data fetching, Framer Motion for animation, and the usual utility packages. The scripts are the template ones with two additions that matter, a build:dev variant that builds in development mode, and a postbuild hook that runs two Node scripts after the build.

npm run dev
npm run build
npm run preview

The postbuild step is the interesting one, because it shows what the project does with the fact that a data site needs more than an index page.

    "postbuild": "node scripts/generate-404.cjs && node scripts/generate-sitemap.cjs"

A static site generator that only emits a bundle gets you very little for search traffic, and this project treats search as a first class concern. The sitemap generator makes the pages discoverable, and the custom 404 page, which the README describes as animated with Framer Motion and SVG, turns a dead URL into a route back into the site. The deployment is the last piece, with GitHub Actions CI/CD configured for automatic deployment to GitHub Pages, a custom domain workflow, and the live site published at a.zli.li. The setup is a good example of a static site being treated as a product surface rather than a personal page.

Three languages, and why that shapes the build

The multilingual claim is the one that most distinguishes this project from the community lists it draws on, and it is implemented rather than aspirational. The README lists a multilingual user interface and SEO across Chinese, Hindi and English, and the contributors section names the roles, with a Hindi translator credited separately alongside the maintainer and two contributors. That combination tells you something about the priority order. A bootloader unlock question is asked disproportionately by users in markets where the manufacturer does not publish kernel source and where the documentation is not in English, so the Hindi translation is aimed at an audience that other references do not reach, and the Chinese translation at another. Doing that in a static site is straightforward, and doing it with SEO metadata for each language is the part that requires discipline, since every page needs a translated title, description and canonical URL rather than a machine pass at the body text. The consequence for the build is that the site is bigger than its data warrants, with a routing layer, per locale metadata and translation resources, and a project that must keep the base path configuration correct for whichever deployment it lands on.

Deployment paths, and the base path trap

The deployment section is short and it addresses the mistake that breaks most GitHub Pages projects. The project is configured for GitHub Pages deployment through GitHub Actions, and for a custom domain you set base to a single slash in vite.config.ts and add your domain to public/CNAME. For a GitHub Pages subpath deployment, set base to your repository name prefixed with a slash. The reason this matters is that Vite computes asset URLs relative to that base, so a project built for a custom domain and then served from a repository subpath will load its JavaScript from a path that does not exist, and the symptom is a blank page rather than an error message. The CNAME file in the public directory is the mechanism that makes the domain work at all, because GitHub Pages reads it to serve the site from a custom host. For a project whose entire value is being found through search in three languages, the deployment detail is not incidental housekeeping, since a misconfigured base silently removes the site from the index.

A community wiki with a licence that limits reuse

Two things to weigh before you rely on this project. The first is the licence, and it is not the usual open source grant. The README points at the Attribution-NonCommercial-ShareAlike 4.0 International licence, and GitHub classifies the repository licence as a custom one it cannot categorise. Read plainly, Creative Commons Attribution-NonCommercial-ShareAlike lets anyone read, adapt and redistribute the content with attribution, as long as the use is non-commercial and derivatives keep the same licence. For a personal reference site that is generous. For a company that wants to reuse the dataset in a product, a paid tool or a commercial research project, the non-commercial clause is a blocker, and no amount of attribution fixes it. The repository also carries a SECURITY.md and a CONTRIBUTING.md with contribution guidelines, and the community-driven data is described as easy to contribute and update, which is the right model for a table that has to track vendor policy changes. The second thing is the maintenance signal. The repository is not archived, but the last push was on 2026-04-11 and the newest release, v1.5.0, carries the same date, with the previous releases from August and July 2025. So the site is not frozen, but a table about vendor policy that nobody has touched since April needs checking against the vendors themselves before you quote it.

Editorial conclusion

Adopt android-locker as a reference and a starting point if you are comparing what unlocking the bootloader costs you on different Android manufacturers, and you want the comparison in a language that mainstream vendor documentation does not cover. It does not fit a commercial product, because the licence is Attribution-NonCommercial-ShareAlike 4.0, and it does not fit a decision you need to be certain about, because the data is community maintained and the repository records a last push on 2026-04-11. Before you rely on a row, follow the two references the project lists, the MobileModels bootloader and kernel source list and the Android verified boot documentation, and check the manufacturer yourself.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. xuemian168/android-locker on GitHub