# dArkOSRE-R36 is a prebuilt firmware image, not a buildable project > dArkOSRE-R36 is a customised dArkOS build for R36S handheld consoles and clones, published as dated release images rather than as source you compile. Its value is the device support matrix in the README, and its risk is that a single maintainer ships binary firmware for hardware you cannot inspect. **southoz/dArkOSRE-R36** — Customized dArkOS firmware for selected R36S devices and Clones - Repository: https://github.com/southoz/dArkOSRE-R36 - Stars: 687 · Forks: 53 - Language: JavaScript - License: not declared - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/southoz-darkosre-r36 ## A replacement firmware for R36S handhelds, shipped as an image dArkOSRE-R36 is a customised build of dArkOS for selected R36S devices and their clones. The project does not present itself as a general Android distribution and does not describe a build system in the README. What it presents is a firmware image, published on GitHub releases with a name that carries its date, so the newest tag in the history is dArkOSRE-R36(03082026) from 2026-03-10, with darkOS-G80CA-RE(02062026) from 2026-02-08 and dArkOS-G80CA-RE(01242026) from 2026-01-30 before it. The users are a narrow and identifiable group: owners of the R36S family of handheld game consoles and of the clone boards that use the same motherboard designs, who want a system that differs from what the factory shipped. The fork naming makes the lineage visible, with the RE suffix on this repository and separate G80CA-RE tags on the related project the README links to. Two claims in the project's own summary deserve a sober reading. It states the build is guaranteed virus and malware free and scanned with the 7th Feb 2026 ClamAV daily update, which is a scan result for one date rather than an ongoing guarantee, and it notes that issues are off for a few days to allow the maintainer to catch up. Both lines are useful signals about how the project is run: one maintainer, one scanner, and issue handling that pauses. ## The support table is the documentation you actually need The centre of the README is a table of motherboard IDs, and it is the part that should drive your decision. Each row names a board variant and panel revision, labels it as r36s or clone, records a status, and names the person who tested it. Three status values appear: completed for boards that are marked finished, Beta Testing for boards in progress, and untested for boards with no result. The naming convention is precise and unforgiving. A row reads like R36S-V12 2023-08-18 Panel 0 for a genuine board, and G80CA-MB V1.2-20250422 Panel 8 for a clone. The date segment is a board revision, and the panel number selects a display variant, so two units that look identical from the outside can sit in different rows and behave differently. This is also why the tester column matters. A board marked completed with a named tester has been run by a person on that hardware, while a row marked untested has no result at all. In the visible table, that distinction is real: R36S-V22 2024-12-18 carries untested with no tester, and R36S-V12 2023-08-18 Panel 4 is marked completed with a second tester recorded against it. Hardware support for a consumer handheld is a per-panel affair, and this table is the closest thing to a support contract. One row pattern is worth flagging. Both R36S-V21 2024-12-18 and R36S-V22 2024-12-18 appear, and the V21 row has several batch suffixes (2550, 2551, 2552), so the suffix in your hardware's identifier has to match too. ## Getting the image means reading the wiki, not running a command There is no documented command line install in this project. The README does not describe flashing steps, does not list a flash tool, and does not give a script. What it does is point you at a wiki, with a Firmware-Installation page linked from every genuine board row of the support table and a separate section anchor for the clone boards, plus a Beta-Testing page linked from every row whose status is Beta Testing. The image itself comes from the GitHub releases page for this repository. So the intended workflow is manual and documentation-driven: identify the exact board string, check its status, download the dated release image, then follow the installation page for that category of device. That is a real difference of approach compared with projects where a single command produces a working artifact, and it has a practical consequence. The reader has to trust the wiki page and the release asset, because there is nothing in the repository that describes the flashing procedure in a way you can audit from the source tree. The repository layout reflects the same picture. The top level contains README.md, files/ and resources/. There is no package manifest, no build script and no test suite, and the repository's primary language is recorded as JavaScript, which reflects the configuration and asset side of the firmware rather than a buildable source tree. Treat the release tag as the version marker. The dates inside the tag names are the only versioning scheme on offer, and the newest tag is from 2026-03-10. ## Upcoming devices sit in beta, and the R36H layout is undecided The news section of the README lists the device expansion in progress, and it is candid about the state of each one: ```bash - R36H - Framework is in place to support different control schemes, trying to decide on buttons. - R36 Max - Working in latest Beta - R36 Ultra - Working in the latest Beta - V20 Clone - Working in latest Beta ``` The R36H entry is the most informative one, because it says the framework exists but that the control scheme is still being decided, specifically around buttons. On a handheld whose main appeal is physical controls, an undecided input layout is a serious open question rather than a cosmetic detail. The R36 Plus note adds another caveat: batch 2551 is working in the latest beta, other batches will also work, and battery capacity reporting has issues. Taken with the support table, the picture is consistent. Genuine boards such as R36S-V12 2023-08-18 Panel 0 and Panel 4 are marked completed, while the newer HL-R36H-V20 2024-05-18 and HL-R36H-V21 2024-11-18 are still in Beta Testing. The clone list follows the same pattern, with G80CA-MB V1.2-20250422 Panel 8 completed and the matching Panel 9 untested. The device names in the news list use a slightly different form from the table, for example R36 Max in the news against R36S-V12 2023-08-18 R36 MAX in the clone rows. When you check your board, work from the motherboard ID string, not from the marketing name, since the same hardware can appear under both. ## A single maintainer, no stated licence, dated binary releases The project metadata records the license as unknown, and there is no LICENSE file among the top level entries. The README contains a PayPal donation badge rather than any licence grant, and the repository itself is listed with no homepage. For a piece of firmware that replaces the operating system on a device you own, the absence of a stated licence means there is no permission text granting you rights to modify, redistribute or build on the images, whatever the practical situation may be for personal use. The same single-maintainer pattern shows up in the working notes. Issues are closed temporarily while the author catches up, the tester column contains individual community names such as southoz, RoiArthurB and Yayi23, and the support matrix is maintained by hand. That is a reasonable way to run hardware bring-up work, and the community testing is genuine work rather than decoration. It also means the support matrix is a human record that can lag behind reality. On cadence, the tagged releases cluster between late January and March 2026, while the last push was on 2026-05-01. The gap between the newest tag and the last push is the honest measure of how current the downloadable image is. Treat 2026-03-10 as the build you can obtain, not as the state of the work. ## When the stock firmware is the better answer This is the wrong tool in several ordinary situations, and it is worth being blunt about them. If your device is not in the table, the project simply has not claimed it, and there is no beta, no early support and no partial result to fall back on. If your board is listed as untested, you are the tester, and the firmware may not boot, may misreport battery capacity, or may have display and control issues that nobody has found yet. The alternative here is not another custom firmware project. It is the stock system that shipped with the console, which for these devices already boots the hardware it was built for, or a build from the upstream dArkOS project, which aims at the same devices without the RE additions. The difference in approach is narrow but real: this fork changes behaviour for specific hardware variants and exposes additional controls, and the upstream build does not carry those changes. A second alternative worth naming is simply not modifying the device. Some of the functions people want from a custom handheld firmware, additional control schemes and battery reporting, are exactly the kind of thing that an upstream project eventually addresses. Flashing a community image to get a feature is a reasonable trade, but it is a trade, and on an untested panel it is a bet. Because the artifacts are binary images with no source or build scripts in the repository, you cannot reproduce the firmware you install, patch a single driver, or roll back to a build of your own. You can only return to the previous dated release or to stock. ## Conclusion Adopt dArkOSRE-R36 if you own an R36S or a listed clone, the stock firmware does not do what you need, and your exact motherboard ID appears in the support table with a status better than untested. Do not adopt it on a device that is absent from the matrix, on a board whose status is untested, or if you need source you can audit and rebuild, because the repository publishes README.md, files/ and resources/ rather than a build system, and no licence identifier is stated. Before flashing, confirm your board ID string matches a table row exactly, read the firmware installation page in the project wiki, and note that the last push was on 2026-05-01, with tagged images dated 2026-03-10, 2026-02-08 and 2026-01-30. ## FAQ ### Which R36S devices does dArkOSRE-R36 support? The README lists supported boards in a table of motherboard IDs with variants and panel revisions, marking each as completed, Beta Testing or untested. Genuine R36S rows cover IDs such as R36S-V12 2023-08-18 Panel 0 and R36S-V21 2024-12-18, and clone rows cover boards such as G80CA-MB V1.2-20250422 Panel 8. ### How do I install dArkOSRE-R36 on my R36S? The project publishes dated release images on its GitHub releases page and links to a Firmware-Installation page in the project wiki from each supported board row. The README itself does not give flashing commands or name a flashing tool, so the wiki is the install path. ### What is the newest dArkOSRE-R36 release? The newest tag listed in the release history is dArkOSRE-R36(03082026), dated 2026-03-10, with darkOS-G80CA-RE(02062026) from 2026-02-08 and dArkOS-G80CA-RE(01242026) from 2026-01-30 before it. The last push to the repository was on 2026-05-01. ### Is the R36H supported by dArkOSRE-R36? Not as a finished build. The README lists R36H as upcoming, says the framework is in place to support different control schemes and that the button layout is still being decided, and the R36H board rows in the support table are marked Beta Testing. ## Sources - [Issues](https://github.com/southoz/dArkOSRE-R36/issues) - [README](https://github.com/southoz/dArkOSRE-R36/blob/main/README.md) - [Releases](https://github.com/southoz/dArkOSRE-R36/releases) - [southoz/dArkOSRE-R36 on GitHub](https://github.com/southoz/dArkOSRE-R36) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/southoz-darkosre-r36