Editorial & Methodology 8 min read

How DroidPorts Tests Hardware Compatibility, Playability Badges & Clean-Room Standards

Inside our editorial and technical review pipeline: how 80bee LLC evaluates clean-room compliance, verifies source repositories, tests Android hardware tiers, and assigns playability status badges.

Published:
Last Reviewed:

Our Editorial Purpose: A Verifiable Engineering Registry

The Android game porting ecosystem is fast-moving, decentralized, and frequently fragmented across GitHub repositories, GitLab trees, Codeberg forks, and technical forums. Newcomers looking for reliable setup information often run into outdated build links, mislabeled emulator wrappers, or dubious third-party APK mirror sites that bundle modified binaries with adware.

Published and operated by 80bee LLC, DroidPorts.com was built to apply rigorous software engineering documentation standards to native Android game preservation. Every entry in the catalog goes through a structured verification checklist covering four dimensions:

  1. Clean-Room & Copyright Safe-Harbor Verification
  2. Source Code & Release Provenance Auditing
  3. Playability Status Classification
  4. Hardware Tier & GPU Driver Benchmarking

This document details the exact criteria our editorial and hardware testing team uses before publishing or updating any port in the index.


Before a project is considered for the DroidPorts catalog, we audit how it handles copyrighted game assets and proprietary code:

Zero Proprietary Assets in Distributed Builds

A community port (whether a decompilation, static recompilation, engine recreation, or source port) must never bundle proprietary retail ROM images, copyrighted level archives (.WAD, .PAK, .BSA, .MPQ, .VPK), or publisher-owned music and textures inside its public APK or repository releases unless the original rights holder has explicitly released those assets as freeware or open-source.

Explicit Asset Requirement Classification

Every catalog entry is assigned one of four strict assetRequirements.type classifications, enforced at build time by our Zod schema (src/content/config.ts):

  • pc-retail-required: The port requires data files copied from the user’s own legally purchased Steam, GOG, Epic Games Store, or retail PC disc installation. Where available, we link directly to the official Steam, GOG, or Epic storefront page so players can purchase a legal copy.
  • retail-assets-required: The port requires the user to supply their own legally backed-up console cartridge or optical disc image for local asset extraction on their own device.
  • freeware-standalone: Reserved exclusively for original standalone fangames or engines whose authors distribute their own original or legally cleared freeware assets.
  • commercial-purchase: Official commercial native Android releases sold directly by the publisher on the Google Play Store.

2. Source Code & Release Provenance Auditing

Security on Android matters. Installing an arbitrary .apk file downloaded from a file-sharing link or re-upload site exposes users to trojans and credential stealers.

To protect readers, our build pipeline enforces strict URL validation rules in src/content/config.ts:

  1. Verified Code Hosts Only: A project’s repoUrl (“Source Code” button) is validated at build time to ensure it points exclusively to an established source control host (github.com, gitlab.com, codeberg.org, sr.ht, or bitbucket.org).
  2. Direct Maintainer Releases: The releaseUrl (“Download Release / APK” button) must resolve to the maintainer’s official release page (such as GitHub Releases or Google Play), never to an anonymous file locker or forum thread.
  3. Unverified Build Warnings: If a notable community port is distributed as a binary preview before its source repository is made public, our template automatically renders a prominent Unverified Build Warning banner on the page, advising users that DroidPorts has not audited the source code and reminding them never to download builds from third-party mirrors.

3. How Playability Status Badges Are Assigned

Every game page displays one of four color-coded status badges. These badges are not subjective review scores; they represent specific technical completion milestones verified during testing:

Status BadgeTechnical Criteria Required
Verified PlayableThe game can be completed from the opening title screen to the ending credits on supported Android hardware. Core gameplay loops, save/load persistence, audio playback, and either touch or physical controller input work reliably. In our build schema, a port cannot be marked verified-playable unless it also has a live repoUrl, releaseUrl, or playStoreUrl.
Playable with GlitchesThe main campaign is bootable and playable through most areas, but known engine bugs remain: such as minor graphical shader corruption on specific GPUs, occasional audio crackle, broken secondary game modes (like multiplayer or bonus minigames), or manual config file workarounds needed on first boot.
Active AlphaAn early public build exists and boots into gameplay levels on Android, but major subsystems are incomplete, crashes occur during normal progression, or performance optimization is still underway. Recommended for testers and enthusiasts rather than casual playthroughs.
In DevelopmentAn active upstream decompilation, static recompilation, or Android port branch is under construction, or the PC/Linux decompilation has reached completion with Android NDK build targets actively being integrated.

4. Hardware Testing & Device Compatibility Verification

When we test a port or review structured community compatibility submissions from our GitHub issue tracker, we evaluate behavior across three hardware axes:

A. Reference Handheld & Smartphone Test Matrix

Our testing and community verification pool spans devices across all five DroidPorts Hardware Tiers:

  • Tier 4 Reference Devices (Snapdragon 8 Gen 2 / 8 Gen 3): AYN Odin 2 / Odin 2 Portal, Samsung Galaxy S23 / S24 series, OnePlus 12. Used to verify 120Hz high-frame-rate interpolation, 1440p internal scaling, and Adreno 7xx Mesa Turnip compatibility.
  • Tier 3 Reference Devices (Snapdragon 865 / 870 / Tensor): Retroid Pocket 5, Retroid Pocket Mini, Poco F3, Google Pixel series. Used as our baseline for “recommended 60 FPS” 3D decompilations, static recompilations, and OpenMW / Source Engine ports, plus Adreno 6xx vs. Mali-G710 comparisons.
  • Tier 2 & Tier 1 Reference Devices (Unisoc T820 / T618 / Dimensity 900 / Snapdragon 680): Anbernic RG556, Retroid Pocket 3+ / 4, budget phones. Used to verify minimum playable floors, OpenGL ES 3.0 fallback paths, and RAM footprints on 4 GB devices.

B. What We Check During a Port Review

For every port we document, we record and verify:

  1. Exact Asset Layout & Checksum Expectations: Which exact files (Data.rsdk, Morrowind.esm, pak0.pak, baserom.us.z64, or diabdat.mpq) are required, where they must be placed under Android 11+ Scoped Storage, and whether filename case sensitivity on Linux ext4/f2fs causes load failures.
  2. Renderer & Driver Behavior: Whether the port defaults to OpenGL ES or Vulkan, whether stock Qualcomm drivers exhibit shader glitches, and whether loading a custom Mesa Turnip driver resolves them.
  3. Input Ergonomics: Whether the port ships with a usable on-screen touch overlay, whether physical Bluetooth and USB-C controllers map cleanly via SDL2, and whether gyroscope motion aiming or USB-C OTG mouse/keyboard input is functional.

5. Automated Monitoring & Human-in-the-Loop Updates

Software repositories evolve every week. To prevent link rot and stale version numbers, DroidPorts runs an automated weekly release and health monitor (scripts/check-links.mjs and scripts/lint-content.mjs) paired with manual editorial review:

  • Release Tag Tracking: We track upstream GitHub and GitLab release tags (src/data/releases.json) so every game page displays the exact version tag and publication date of the newest upstream build.
  • Automated Content Linting: Every build runs scripts/lint-content.mjs and astro check to verify schema integrity, link safety, chip-tier coverage, and strict compliance with our clean-room editorial standards.
  • Community Compatibility Reports: Every game page includes a Report Device Test button linked directly to our structured compatibility report template on GitHub. When players submit frame-rate results, driver versions, or bug notes for a specific phone or handheld, our editors verify the report before adding the device to the port’s testedDevices matrix.