Stock OS Modification extends the Linux images on Anbernic handhelds

What the modification actually changes

The project describes itself as built on the StockOS of Anbernic, enhanced through modifications to achieve a better user experience. The list of what is included is five items and only one of them is the operating system itself. There are modified Stock OS images that support automatic partition expansion, package files that support lossless upgrades, a template package for customizing system themes, open source resources, and other additional tools. That first item is the substantive one, because the storage on these handhelds is small and the stock image leaves most of the card unusable, so a modified image that grows the partition to fill the device is the difference between a few gigabytes and a usable library. The second item is more useful than it sounds, since a lossless upgrade package means the user can move to a newer build of the modification without reflashing from scratch and losing their configuration and saves.

Twelve handhelds are on the supported list

The supported models are given by name, and the list is long enough to be worth reading in full because it defines the scope of the project. It covers the RG35xx Plus and the RG35xx 2024 revision, the RG35xx H, the RG35xxSP, the RG28xx, the RG40xx H, the RG40xx V, the RGcube XX, the RG34xx, the RG34xx SP, the RG35xx PRO and the RGSP. These are all machines running the same family of Allwinner-based Linux, and the fact that one image family covers eleven models is a sign that the modification is to the shared system rather than to a single board. The downloads are then split by model, with one Google Drive folder for the RG28xx, RG34xx, RG34xx SP, RGcube XX, RG35xx PRO and RGSP, and a second for the RG35xx Plus from 2024, the RG35xx H, the RG35xx SP, the RG40xx H and the RG40xx V, plus a third for the upgrade packages and other material, and a fourth for offline PortMaster installation on the RG28xx and the RG35xx 2024.

Flashing is where most of the trouble is, and the README says so

The installation advice is to use imaging software to write the image file to the TF1 card, and the recommendations are Rufus or rpi-imager on Windows, rpi-imager or a flash_dd_with_gpt.sh script on Linux, and rpi-imager or a MacOS variant of the script on Mac. The important warning comes next, and it is specific: when using programs such as BalenaEtcher and dd flash on MacOS or Linux systems, automatic partitioning will fail, with a link to an issue thread as the solution. That is the whole risk profile of the project in one sentence, because the partition expansion is exactly the step that the imaging tools interfere with. A second troubleshooting entry covers the case where the storage medium seems to have no partitions after flashing with the script on Linux, and the fix is to zero the device and format it manually to FAT32 before burning the image again.

$ sudo dd if=/dev/zero of=/path/to/device bs=32M status=progress conv=fdata
$ sync
$ sudo mkfs.fat -F 32 /path/to/device           
$ ./flash_dd_with_gpt.sh

The formatting command with its trailing whitespace in the readme is reproduced as it stands, and the operation it performs is the standard one: writing zeros across the whole device so that any leftover partition table is gone, then putting a fresh FAT32 filesystem on it.

The repository is a toolbox rather than a single script

The top level directory listing shows what is actually being shipped, and it is a collection of small utilities rather than one build. There is a Theme_Manager/ directory, a Bezel_Custom_Manager/ for the screen bezel, a Clock/, an Image_Browser/, a Tiny-scraper/ for artwork, a Modify_System_Settings/ and a Modify_System_Tools/ directory, and separate directories for RetroArch, PPSSPP and Java, which are the emulators and runtimes the device ships with. The Modified_System_Online_Upgrade/ directory corresponds to the online upgrade package in the release tags. There are also two directories that read like leftovers, a Temp/ and a Temporary_SAMBA_Server/ plus a Temporary_SSH_Server/, which are network access helpers, and a flash_dd_with_gpt.sh and a flash_dd_with_gpt.MacOS.sh pair at the root for the imaging step. The common factor across the release tags is that they are dated, with 20260930, 20260909 and 20260826, and each is labelled as an online upgrade of the 64-bit modification at version 4.0.3, 4.0.2 and 4.0.1 respectively.

Network control is the part that lives in another repository

The readme draws a boundary explicitly. PortMaster related issues should be raised not in this repository but in a separate one, PortMaster-for-StockOS-MOD, and the project points there rather than answering them here. PortMaster is the tool behind the compatible ports these modifications rely on, and the reason it needs its own tracker is that the questions are about a different project with its own compatibility surface. The readme also points at a wiki on a sibling repository, the RG35xx-P and RG35xx-H modification wiki, for more information, and at a spreadsheet of working ports that is regularly updated with tested games, which tells you both what the spreadsheet is for and that the list is a living document maintained by the community rather than a static compatibility table baked into the release.

Where this is the wrong project

The scope is narrow and the risk is real. The modification is tied to a specific family of devices and to the stock Linux image they ship with, so it does nothing for a handheld on a different system, and the flashing step rewrites the card, so the wrong image on the wrong device is a recovery job rather than a mistake you can undo. The second limit is that the images and packages are distributed through Google Drive folders rather than through a package manager or a release asset, which means the thing you flash is hosted somewhere that is not versioned alongside the repository, and the release tags in the repository point at the upgrade packages rather than carrying the images themselves. The third is that the source is open while the images are not, so a user who wants to know exactly what changed in the system build has the open source resources and the theme template but has to trust the image. The fourth is the practical one. The readme devotes more space to what can go wrong during imaging than to anything else, and that ratio is the honest signal about where the difficulty in this project lies.

Editorial conclusion

Stock OS Modification suits an owner of a supported Anbernic handheld who wants the free Linux build to behave like the device it was sold as, with more storage and a working upgrade path, and it suits anyone who wants to theme the system rather than accept the vendor image. It is the wrong tool for a handheld that is not on the supported list, and it is the wrong tool if you need the stock image to remain exactly as shipped. Before flashing, read the partition note, because the modification exists to expand the partition and that step is what goes wrong when the wrong imaging tool is used, and check the working ports spreadsheet for the games you care about. The last push was on 2026-10-01 and the release tags are dated, with 20260930 carrying version 4.0.3 of the 64-bit modification.

Frequently asked questions

Official sources

1. cbepx-me/Anbernic-H700-RG-xx-StockOS-Modification on GitHub
2. Issues
3. README
4. Releases