photo-frame-dashboard: taking over a locked-down Android photo frame

A family dashboard built on a photo frame that cost fifty dollars

The premise of this project is simple to state. Buy a cheap Android photo frame, and point an agent at this repository, and let it rip. The frame becomes a family dashboard, with the vendor application replaced by your own web page running full screen.

The README describes the work as notes and scripts for getting full control of locked-down Android photo frames, and the list of the steps is the same for every device: getting ADB, backing up the firmware, getting root, removing the vendor app, and running your own launcher, browser and kiosk app.

What the frames are is the interesting part of the catalogue. The working list includes a 10.1 inch frame of the kind used in the video, which now often ships as the PF1007L, a Runxion 10.1 inch Frameo, a 15.6 inch Frameo, a Pastigio FRAME156 15.6 inch Frameo, a Dragon Touch Modern10 Charm, a Skylight Calendar 15 inch, a Humblestead 10.1 inch sold on Amazon Spain, and an Anna Bella 10.1 inch sold on Amazon Canada. The links are affiliate links, and the README is explicit that these are the frames confirmed to work, with the device index holding every frame, which board it has, and where to start.

The framing of the repository as notes rather than guides is a deliberate and correct choice. The README says these are records of the units their owners tested, not universal flashing guides, and that difference is the difference between a project that helps people and a project that bricks frames.

The community builds page is the other half. Thirty people have shared their hacked frames, and the range is a good argument for the project: a Star Trek LCARS interface, a retro weather channel display, chess puzzles with analytics, Linux running on a frame, an Omarchy Linux install on an A33 board, a family dashboard, and something called FamilyOS.

Same product name, different board

The section headed which frame do you have is the most important part of the README, and the reason is a single line: frames sold under the same name, even the same Amazon listing, can have different boards. The instruction is to check Settings and then About before following any guide.

The specific identifiers given are firmware strings, and they map to SoC families. The PF1007L and AiMOR frames have a firmware string containing `A33` and `PF1007L`, and that is an Allwinner A33. The BIUFRAME and Synergy 10X1 are a Rockchip RK3126 and show an ADB prompt on screen. The Skylight Calendar 150-CAL is a Rockchip RK3566. The LOOFII C-3 21.5 inch calendar is an Allwinner A133 running Android 10. And then there is the long tail, Frameo, Dragon Touch, Joyhong, Uhale, VESWWE, Pastigio and others, which the device index covers.

For a frame that is not on the list, the instruction is to work through the phase map, create a `docs/<device>.md` file, and send in what you find, and there is a whole section on checking for updates and sending back what you find. The repository is asking to be extended, per device, by the people who own the devices.

The reason this matters so much is in the scripts. A flashing script is written against a board, and running the Rockchip script on an Allwinner board, or the other way round, is how a device is bricked. The README says it plainly for the LOOFII: do not run the Rockchip or A33 scripts on it. The whole device index exists so that a person with a board nobody has documented yet does not guess.

The rules the project says it learned the hard way

There is a section with that exact heading, and it reads like a safety manual written by somebody who had incidents. These are the rules as the README states them.

Ask the owner before every write. Reads are fine, but writing flash, a partition, `/system`, or sending a RAM payload to the SoC needs explicit approval for that specific action. The reason for the phrase specific action is that approval for one write is not approval for the next one.

No writes before a verified backup, and the backup has to have an exact byte count, a SHA-256, a gzip readback, a check for `0xCC` filler, and independent re-reads of a few partitions that match.

Do not trust `OKAY`. Fastboot reported a successful boot write on the Skylight that never took effect, so verify writes by reading them back and checking the result on the device. This is the rule that most directly contradicts what a flashing tool tells you, and it is the one that would have prevented the incident it describes.

Stop at the first mismatch in a hash, model string, offset or size, and report it rather than working around it.

The fifth rule begins with the idea of one change at a time.

There is also a section addressed to agents, and it is short. You are probably helping someone with a similar device plugged into a Mac over USB, so read that section and then follow the links for the phase you are in, and do not run anything from a device section unless the identity checks match exactly.

This is a repository that treats a hardware write as something to be negotiated with a person, and that is a better design than most flashing guides, which treat it as a sequence of commands.

A worked example: the BIUFRAME and its three commands

The BIUFRAME, also sold as the Synergy 10X1, is the frame in the video, and its section is the most complete example in the repository.

The identifying facts are a Rockchip RK3126 and an ADB prompt that appears on screen, which is unusual and useful, since most of these frames hide ADB behind the vendor application. The guide to follow is `docs/biuframe-setup-guide.md`.

The tooling is three commands with very different risk levels, and the README explains the difference:

scripts/biuframe-setup.sh check

`check` changes nothing and confirms that the hardware matches, which is the whole point of the identity check. `backup` takes the backup, and the rules above say what a verified backup means: the byte count, the hash, the readback, the filler check. `apply` is the one that writes, and it is the one that needs the owner's approval.

The ordering is the same for every device in the repository. For the PF1007L the start-here document tests ADB over USB, then the network, and only then a boot patch, and the page warns that the vendor application accepts root shell commands from the vendor's server, so it should be read before the frame goes online. That is a specific and unusual warning, and it is the kind of thing that only somebody who looked at the application would write.

For the Skylight Calendar 150-CAL, the path is different again: `next-session.md` and then `app-analysis.md` for the hidden menu, with the manufacturer code intentionally not published, and the document showing where the application checks it. The firmware `D156.V0.10` ships with ADB and `su` already on, and there is a separate `skylight-d156.md`.

The LOOFII C-3 is the easy one, a 21.5 inch calendar on an Allwinner A133 running Android 10, with root ADB over USB out of the box, and a separate document for it, and a warning not to run the other scripts on it.

The dashboard, the kiosk app and the two finger menu

The payoff of all that work is the `dashboard/` directory, and the description is modest. It is the family dashboard the maintainers run on the BIUFRAME, and it uses mock data, which is a sensible choice for a repository that people will run on their own hardware and modify.

Technically it is a Vite web app deployed to Cloudflare Workers, so the page is a static bundle served from the edge and the frame only has to show a URL.

`dashboard/kiosk/` is the other half, a small full-screen WebView Android app that displays the dashboard. It is built without Gradle, which is a decision that pays off on a device with a locked bootloader and no build system, and it shows the same page.

The interaction model is worth noting because it is a workaround for the hardware. Holding two fingers still for 1.5 seconds opens a menu for the launcher, the Android settings and a reload, and on frames without system navigation there are optional floating Back and Dashboard buttons to help. The kiosk guide is `dashboard/kiosk/README.md`.

So the shape of the project is: a cheap screen, a cheap computer behind it, and a web page. The hard part was not the dashboard, it was the phases of getting the cheap computer to run a browser of your choosing, and the repository is mostly the record of that part, with the dashboard as the reward.

Where this project is the wrong tool

The limits are clear, and they are the limits of device modding rather than of this particular project.

The first is that it is destructive by nature. Flashing firmware and replacing the vendor application means that the device can be rendered unusable, and the rules the project states are the acknowledgement of that. For somebody who wants a dashboard and does not want a weekend of backup verification, this is the wrong project, and there is no way to make it not destructive.

The second is that it does not generalise. Every board needs its own document, and the repository's own count is the measure of the work: the documented frames and thirty community builds, each of which is one person with one device. A project that had a general flashing script would be a different and more dangerous project, and the fact that this one does not have one is a feature.

The third is the maintenance of the scripts themselves. A script that writes a partition is tied to a firmware version, and a vendor that updates its application can break the procedure. The README's rule about checking for updates and sending back what you find exists because the devices move underneath the notes.

The alternative, for somebody who wants a kitchen dashboard and not a rooting project, is to skip the frame entirely. A cheap tablet, a used phone on a wall mount, or a small computer with a screen and a browser can run exactly the same Vite page and the same Cloudflare Workers deployment, with no firmware writes and no backups. The difference in approach is that this project treats the frame as a device to be taken over, and the alternative treats the screen as a display to be bought, and the second is cheaper, more reliable and less interesting.

Editorial conclusion

photo-frame-dashboard fits somebody with a cheap photo frame and a spare afternoon, who wants a dashboard in the kitchen instead of a stock photo slideshow, and who is willing to read the identity checks before running anything. It is the wrong tool for a fleet of devices, because every board needs its own notes and every write is device specific, and it is the wrong tool for anybody who wants a quick result, since the project measures its progress in backups and verified reads rather than in features. Before running anything, check the firmware string in Settings and then About, and read the rules about backups, because the fastest way to brick a frame is to skip the readback.

Frequently asked questions

Official sources

1. Issues
2. README
3. wesbos/photo-frame-dashboard on GitHub