Daily English Article — October 4, 2026

Google has begun rolling out Android 17 QPR3 Beta 1 for eligible Pixel devices, just days after releasing the QPR2 update. This early beta is aimed at developers and enthusiastic users who want to test cutting-edge Android features before they reach the general public. The stable version of QPR3 is not expected until March 2027, meaning this beta represents a very early look at software that is still many months away from widespread release.

System images for Android 17 QPR3 Beta 1 are available across a wide range of Pixel hardware, spanning from the older Pixel 6a all the way up to the latest Pixel 11 series, including the Pixel 11 Pro Fold. The Android Emulator is also supported, giving developers who do not own physical Pixel devices a way to test and experiment with the new beta build in a virtual environment without requiring specialized hardware.

Users who wish to participate can join the Android Beta Program to receive the update over-the-air directly on their device. Alternatively, system images can be manually downloaded and flashed. Those who encounter problems during the beta period are encouraged to submit bug reports through the Android Beta Feedback app, accessible via the application drawer or Quick Settings, which files issues directly into Google's official issue tracker.

For users who decide the beta is not for them, opting out before installing QPR3 Beta 1 allows a clean return to the stable QPR2 release without any data loss. However, if a user opts out after installing Beta 1 or any subsequent beta update, the device will undergo a full data wipe as part of the standard downgrade process. This policy is consistent with Google's longstanding Beta Program guidelines and is designed to protect device integrity.

In addition to the official feedback app, Google maintains an Android Beta community on Reddit where participants can discuss issues, share findings, and connect with fellow testers. The simultaneous availability of QPR3 Beta 1 so soon after QPR2's public launch underscores Google's increasingly rapid development cadence, as the company works to continuously refine and improve the Android experience ahead of each scheduled stable release.

Software developer Lukas Vogel has accomplished what he readily admits is 'obviously a bad idea': rendering the classic 1993 first-person shooter Doom entirely within an SQL database. The project, called SQLDoom, uses a small Python client to manage user input, output, and display timing. The actual game logic, however, is driven by approximately 1,300 lines of SQL queries distributed across 89 common table expressions, while a series of CedarDB database tables track the game's geometry and ongoing state.

SQLDoom represents a significant leap forward from Vogel's earlier experiment, DoomQL, which attempted to build a multiplayer Doom-like shooter entirely in SQL. That project was limited to raycasting-based grayscale ASCII graphics reminiscent of the simpler, corridor-style maps found in Wolfenstein 3D. By contrast, SQLDoom generates full-color 640×480 pixel frames that are visually indistinguishable from those produced by the original Doom executable, marking a dramatic improvement in fidelity and technical ambition.

One of the more elegant aspects of the implementation involves Doom's binary-space partition trees, a core data structure used to determine rendering order. Vogel was able to map these trees into SQL tables using pre-computed sort keys for each position. A simple ORDER BY statement then determines, for every frame, which wall segments are visible and which can be safely discarded, dramatically reducing unnecessary computation and boosting overall rendering performance.

Despite the inherent overhead of reading and writing to SQL tables for every operation, Vogel achieved approximately 60 frames per second on a Ryzen 7-powered laptop, with performance occasionally dipping to around 35 fps during graphically intense scenes. One persistent challenge was rendering floors and ceilings, which typically rely on a column-based 'visplane' algorithm in the original engine. For SQLDoom, Vogel devised a self-described 'hacky' workaround that iterates over an ordered list of panels to approximate the same visual result.

Beyond the technical novelty, Vogel argues that a database-backed game server offers genuine practical advantages for multiplayer. The database's consistent reference snapshot of game state, combined with its built-in concurrency controls, eliminates the class of bugs common in networked games where clients disagree on what has actually happened. For those intrigued by the project, the source code is available on GitHub, a hosted online demo is accessible for quick testing, and CedarDB along with a Doom WAD file are the only prerequisites for running it locally.