Skip to content

VALIDATION.md

Latest commit

 

History

History
332 lines (216 loc) · 71.3 KB

VALIDATION.md

File metadata and controls

332 lines (216 loc) · 71.3 KB
Raw

🧪 Validation record / 验证记录

English · 简体中文

English

Updated 2026-10-10. Automated checks, desktop capture and emulator observations are distinguished from hardware capabilities that remain untested.

v0.4.0-alpha — completed software/package checks

The fourth mode, Enhanced first person, uses fixed physical 1:1 squares, original GPU inverse angular sampling and existing saved fit controls. Applications are 0.4.0, mobile build 8. Completed software, GUI, package and native Simulator evidence is recorded below; physical Huawei/PCVR checks remain deferred. The checks below concern this candidate; earlier v0.3.4 evidence remains historical. See the projection contract and current notes.

  • The complete local Windows desktop suite passed 334 tests plus 204 subtests. A separate scripts suite passed 22 unit cases; these are not included in the desktop count. Projection/geometry, capability negotiation, legacy fallback and retained input/connection boundaries are software checks, not physical gyro input or game/video measurements.
  • The actual frozen-preview Windows GUI on the ASUS display, with an isolated profile, passed Enhanced-mode radio selection, proportional square corner resizing 0.85 → 0.50, inward mirrored spacing to −0.55 contact, Save/reopen, and draft-pan Discard. The committed scale 0.50/separation −0.55/X=0/Y=0 stayed unchanged after Discard. Two unmodified owned editor screenshots are preserved; the tutorial example shows the reopened saved editor with an original synthetic grid and approximate desktop mesh. This was the pre-final-notices preview using the production candidate code, without capture, phone connection, poses or OS mouse output; it does not establish phone GPU, F8/Resume or performance acceptance.
  • Clean Android unit checks passed 133 cases (75 app + 58 core). APK and release AAR builds passed. Additional instrumentation containing 576 geometry/mask cases and 108 projection cases compiled but was not executed; no physical Android GLES result is claimed for the new mode.
  • The local APK's official signature verification matched the canonical public certificate SHA-256 c8221633041e9b4551cd6e9f4f657e7beeb0901a4b77999d1bfc11d3825b6d74. APK SHA-256 is 735472b004196fb8b5e9795cabee8197c94fc67d3e258336204fef33d271054f; changed release AAR SHA-256 is 088e9db45aa3e326fe8b4f790ac684417a1f27cf7711809a38e92367c84b6066. These establish built-artifact identity, not phone installation or streaming acceptance.
  • The final rebuilt Windows EXE passed the bytecode/native/notice audit: 22 project modules match current source, 38 native files match their exact recorded current origins, and 44 license files plus three root notices are byte-exact. EXE SHA-256 is 3fe0fb08be5485975ff03c991622f2ff9a166ce69ef3f6263f14dd633b2002b7. Native files are byte-identical to v0.3.4: 16 also match the initial historical audit; 22 retain the previously reviewed valid re-signing, with PE code/resources unchanged. No numpy, dxcam, comtypes, ADB or system D3D DLL is bundled; VRization's own DXGI implementation remains. The full prepublication Windows ZIP passed the clean-profile runtime/link check with SDK variables removed and an unexpected current-directory ADB ignored; no capture or OS mouse output ran. The final upload ZIP is regenerated with the same verified EXE and completed documentation. The previous local release is preserved.
  • An independent CPU screenshot-checker calibration accepted 38 original reference samples and rejected two negative controls with missing warp or wrong aspect. These are checker/reference-image checks, not actual mobile GPU or native UI output.
  • All four Actions 38088502161 jobs passed at source ae3469e7a7e54d6de079aeae6f55a524a03e8b0f. Independent iOS review confirmed 95 Swift core tests with zero failures, seven genuine native UI cases with zero failures/skips, and successful Simulator/unsigned device SDK builds. Environment: arm64 iPhone 17 Pro Max Simulator, iOS 26.2, Xcode 26.3.0 (17C529), macOS 15.7.9; app 0.4.0/build 8/minimum iOS 15. All 26 original native PNGs were independently decoded: 38 enhanced checks (12 RGB, four curved borders, 20 black masks, two exact seams) and 16 older-mode color/orientation plus two seam checks passed. All 15 ready/connected host checkpoints had zero OS mouse output. The exact-commit pixel checker reproduced the reports. A deliberate cancellation of a held LAN upgrade logged one ConnectionReset warning without native test failure. USB was simulated, not a physical Apple service/cable. Simulator ZIP SHA-256: 91aef23bd987d6aa7d14735bffd97ebf134a3fe2092c286902672797b2bf060a. The unaltered native Metal example shows an original calibration card, not the user's reference image or a physical iPhone screenshot.
  • The user explicitly deferred Huawei and PCVR hardware tests to the next chat. No new phone installation, physical GLES/Metal rendering, optics, gyro/game feel, true end-to-end latency or SteamVR/headset test ran in this round. The separate SteamVR experiment remains planned; normal direct-phone files and published history are preserved.

v0.3.4-alpha — completed software/package checks

Windows, Android and iOS applications are 0.3.4, mobile build 7; the reusable Android core AAR is unchanged. The Windows GUI enables First-person gyro mouse control across all foreground windows by default. The completed software/package/native Simulator results below do not establish physical gyro/game/video/latency or advanced Windows GUI acceptance.

  • Source 101174317613520c7d98375332c2a3bd9032cb2d: the Windows build script's complete suite passed 318 tests. The 31 new tests comprise 17 controller cases and 14 GUI/storage/real-loopback cases, including Stop/restart. They use fake input and synthetic capture; no actual operating-system mouse input or desktop capture ran in these tests. They establish software policy/lifecycle behavior, not physical gyro/game feel.
  • The frozen v0.3.4 EXE matches all 21 project modules and all 38 native hashes against the current recorded origins, and includes 44 license files plus three root notices. SHA-256: 19f19409cb1331e42b988e7a3f9b32920bd2c33397eb7fe687933abeca024a5d. Compared with v0.3.3, 22 CPython native-file hashes changed solely because of valid re-signing; their PE code and resources are unchanged. The first-release historical audit remains immutable. The release Windows ZIP passed the clean-profile runtime smoke check without SDK environment variables; that diagnostic check performed no capture/input.
  • The user confirmed the physical Huawei upgrade to 0.3.4 / build 7, without uninstalling or clearing data. The pulled installed APK matches the release APK SHA-256 c1be9b8ba11f8941844dbb9b84ebc463b695807874605a93c94dc238f32c70ad; its certificate matches the existing public SHA-256 fingerprint c8221633041e9b4551cd6e9f4f657e7beeb0901a4b77999d1bfc11d3825b6d74.
  • The new Windows GUI's initial startup and visible 0.3.4 version were observed. The advanced GUI check stopped when the user physically pressed Escape; actual GUI Resume/F8 acceptance is therefore not claimed. New-version physical gyro control, game feel, video delivery and latency were not tested.
  • Clean Android tests passed 116 cases (67 app + 49 core), with zero failures/ignored cases. APK, unchanged reusable AAR, instrumentation compilation and lint passed. Lint reported zero errors and nine CI warnings: eight existing local warnings plus OldTargetApi from the CI SDK inventory; no warnings were suppressed.
  • All four Actions 38081097956 jobs passed at source 101174317613520c7d98375332c2a3bd9032cb2d. Independent iOS verification confirmed 80 Swift core tests with zero failures, five genuine native UI tests with zero failures/skips, and successful Simulator and unsigned device-target SDK builds. The arm64 iPhone 17 Pro Max Simulator ran iOS 26.2 with Xcode 26.3 on macOS 15.7.9. Independently decoded screenshots passed 12 color pixel checks and two seam checks; all 12 host checkpoints had empty mouse-move lists. USB was explicitly simulated; no physical iPhone USB was tested. The Simulator app identifies as 0.3.4 / build 7 / minimum iOS 15 / arm64, and is not an installable iPhone IPA. Earlier results below retain their published versions.

v0.3.3-alpha — published checks

  • Source 76639de380c2b4dd26ce860dada30a24323874e8: the complete local Windows suite passed 287 tests plus 135 subcases. Cases include sender cleanup blocked after a real localhost WebSocket disconnect: host status/input are revoked before cleanup, a new session can connect, and old cleanup cannot affect the new owner. Android passed 116 unit tests, APK / release AAR builds, lint and instrumentation compilation. Signature-gate tests passed six cases; documentation checked 36 complete bilingual pages and local links.
  • The final frozen Windows EXE matches all 21 project modules, all 38 recorded native hashes, and includes 44 files under licenses/ plus the three root notices. SHA-256: 50d631ab2dfc0f0220b6da4d993fa5b916d8615ff87c19d5fa6773d96d50cf8c. The public ZIP passed its independent clean-profile runtime check with SDK environment variables removed; no capture/input ran in that check. Official Android tools remain separate.
  • The physical Huawei installed version 0.3.3 / build 6, visible in its Chinese UI. Its installed APK matches the local publication APK, SHA-256 2ae72ee5180b6b918f88680c87edb30d0dc3d12bd1cb7a87eab8b3e38ade58da, verified by the official apksigner against the existing public certificate. The update kept application data.
  • With the final EXE capturing ASUS PA279, six real phone Connect / Disconnect cycles each received at least five decoded desktop frames; each Disconnect stopped delivered frames for a full second and cleared both eye pixels and renderer texture. A concurrent host-health timeline returned disconnected. A real PC Stop closed the viewing session; the phone cleared its frame and received no new frames for a second. An explicit phone Connect then started the stopped host and received at least five new frames. Closing the EXE released its two owned reverse maps; the ordinary Start-Windows.bat restarted the same EXE and passed two of these cycles with fresh isolated PC preferences and SDK variables inherited only from that launcher. No cable unplug or ADB daemon reset was used. The probe's read-only preference wrapper verified saved phone settings unchanged and disabled pose output.
  • A separate click of the actual PC Connect / Start streaming button connected the open phone app. Host UI showed a bounded 60 FPS sending sample; this is not a new end-to-end latency benchmark or performance guarantee. Windows already masks protected regions; the corrected DXGI path streams that masked surface and retains fatal layout/access/resource guards.
  • Final Actions 38035750560, source cb22ebb1727846cdffea491d553ad4f52df4774f, passed Windows, Android, documentation and iOS jobs. Mac passed 80 Swift core tests and five genuine native UI cases, with zero failures / skips, on the arm64 iPhone 17 Pro Max Simulator, iOS 26.2 (Xcode 26.3 / macOS 15.7.9). Both Simulator and unsigned device-target builds passed. LAN / simulated USB Metal color checks passed 16 samples; exact seam checks passed two samples. All 12 host checkpoints were present and OS mouse moves were zero. Native cases exercised held LAN upgrades, cancellation / timeout clearing, replacement sessions, USB Stop acknowledgments and fresh reconnects. The fixture's 12 startup / lifecycle tests also passed. Physical iPhone USB, actual game input and motion-to-photon timing remain unverified for this change.

v0.3.2-alpha — archived checks

  • Final Actions 37991498159, source a9afaceabc5f237d31794a271ac5bc2ed6eb006b, passed all Windows / Android / iOS / documentation jobs. The Windows suite passed 220 tests, and its complete public ZIP passed a clean run without a developer SDK. Android APK / AAR tests, builds and lint passed. Documentation checks establish section / link structure, not translation quality.
  • The frozen local x64 Windows EXE matched 19 project modules, 47 notice files and 38 recorded native components in a static audit, with no forbidden research runtime or system D3D DLL bundled. Its SHA-256 is 19eaebd0d1420872b76db7add6fa3aee0835a4f18987a2bd997bcccee665378d. With SDK variables cleared and fresh application preferences, this EXE selected portable_executable tools, found one authorized physical USB phone and completed diagnostics without errors; no legacy developer-SDK fallback was found. Official tools are still separately installed.
  • The physical HUAWEI Pura 70 Ultra installed the final Android candidate; the pulled APK matched SHA-256 1a3094c8c182930bcf96c571412442104df2e4b7123914cf6316a1e7b7a1ff7e. An actual stabilization slider change saved 50% locally and reached the host. A 65% host update persisted on the phone, survived restart and restored to the host. The earlier viewing profile was retained and OS mouse moves stayed zero. These are settings / persistence checks, not real-game smoothing acceptance. The unmodified settings screenshot shows a temporary 65%; the default remains 0%.
  • A custom GLES runner on the same physical phone passed 288 offscreen mask cases across both eyes, covering the resolved physical display range. This exercises graphics code / pixels, not viewer lenses or motion-to-photon latency.
  • Phone-first USB retry passed with the original calibration card: the test host started 6.08 seconds after the phone; the phone connected at 7.67 seconds from its start, or 1.59 seconds after the host. Its profile was unchanged and OS mouse moves stayed zero. This is one bounded startup result, not permanent background reconnection or a long-duration stability guarantee.
  • Final Actions 37991498159 passed 77 Swift core tests and five genuine native UI cases, with zero failures / skips, on the arm64 iPhone 17 Pro Max Simulator running iOS 26.2 (Xcode 26.3.0 / macOS 15.7.9). Both Simulator and unsigned device-target builds passed. LAN / simulated USB Metal color and row-orientation checks passed for both eyes, as did exact viewport seam-boundary pixel checks. These are Simulator / software-bridge results, not a physical iPhone, real Apple USB service or signed IPA.

The official Windows Platform Tools 37.0.1 ZIP was actually imported into a separate test folder with its complete NOTICE preserved. Actual importer-GUI interaction is not claimed. An ordinary launcher with earlier builds was also confirmed visible by the user after portable SDK configuration. SDK visibility across packaged-app storage was a verified discovery issue; shared ADB-session and phone-authorization drops were observed separately. One authorized restart did not remove the need for the user to toggle phone USB debugging before recovery. No old-host GUI or port collision was found, and the full historical failure sequence is not attributed solely to MSIX.

Synthetic filter checks cover 0% exact bypass, moving input, smoothing and reset / no-output boundaries; they do not measure real-game feel or physical delay. Physical iPhone USB, actual viewer optics, real first-person game input, new Windows editor-GUI interactions and end-to-end latency remain unverified. Earlier performance numbers below keep their original release / configuration scope.

Completed for the first release

Check Environment and result What it establishes
Host core Windows x64, local CPython 3.12.14; 12 checks passed. Listed settings, protocol, input authorization, long-edge scaling and module behavior.
Android core JDK 17, Gradle 8.9, AGP 8.7.3; 6 tests passed. Pose math, angle handling and arbitrary tilted recentering.
Android build / lint Latest first-release APK assembled and linted successfully. APK generation, not universal device compatibility.
Windows EXE Local build succeeded with 40 license files; no Microsoft VCRUNTIME140*.dll. Packaging and bundled notices were checked; Microsoft runtime is a system prerequisite.
Display capture ASUS PA279 portrait source 2160 × 3840; limit 1280 produced 720 × 1280. Portrait capture, aspect preservation and longest-edge bound.
Desktop screenshot 1054 × 963 crop of this project's GUI, selecting that ASUS display. Actual controls, modes, display selection and stream settings.
Android installation / display Google-free Android 6.0 / API 23 emulator received the original animated card. Startup, JPEG / WebSocket reception and both-eye display in that environment.
Actual desktop stream Latest first-release APK received ASUS desktop frames at 720 × 1280 and stayed connected. Real Windows capture → network → Android rendering beyond synthetic frames.
Settings UI Scale, offsets, separation and distortion visible; hidden controls leave the image visible. Settings and viewing flow work in the emulator.
Endpoint round trip Real Android controls sent offsetX 0.3 and separation 0.2; host accepted, echoed and saved them without disconnecting. Float serialization did not incorrectly reject these boundary values.
No-sensor fallback Emulator has no usable rotation sensor; full screen works. Fixed viewing without sensor support.

The older emulator screenshot files show the final v0.1.1 English interface and show the original calibration example. Receive-FPS readings describe those sessions, not end-to-end latency measurements or performance benchmarks. The emulator uses software graphics; readings from actual desktop reception likewise do not predict physical phones, viewers or Wi-Fi. No game-FPS guarantee follows from them. The table above remains the historical first-release record.

v0.1.1-alpha follow-up checks

  • Windows host: 20 automated tests passed, including concurrent settings updates and language handling.
  • Android: 15 tests passed (6 core math tests and 9 app settings-order / session-dispatch regression tests); the v0.1.1 APK assembled and linted.
  • Actual Windows 11 build 26200 / ASUS display: English default, Chinese switching, persistence after reopen, language switching while streaming, and 1060 × 680 scrolling checked. Switching language disarms mouse control.
  • Documentation: all 20 project-owned pages pass language-order / section / local-file checks. Windows and Android license ZIPs were actually packaged with offline-link validation. Six checker smoke cases and discovery of a temporary nested Markdown page also passed; these checks do not judge translation quality.
  • The final packaged Windows EXE also started on the actual ASUS display with English UI and responded normally.

Android 16 / API 36 — final v0.1.1 APK

Tested on a Google-free AOSP emulator. The v0.1.0 APK upgraded in place to v0.1.1 (version code 2). English was the default; switching to Chinese persisted after force-stop / reopen, then switching back to English worked.

The actual client received the original 1280 × 720 calibration card over WebSocket and rendered both eyes with OpenGL. Host-selected cinema / FPS modes remained selected and Game Rotation Vector registration was observed in Android's sensor service; returning to full screen unregistered it. This does not establish physical gyro axes or real FPS input.

Hiding controls and restoring with Back passed. Entering the background changed the host's connected state to false, with no mouse output. After a language change, Home / background transition, and server close code 1001, explicitly tapping Connect restored reception. No AndroidRuntime, OpenGLRenderer or libEGL errors were observed during these checks. Receive-FPS readings are not benchmarks.

Android 6.0 / API 23 — final v0.1.1 APK

The same local debug signature upgraded v0.1.0 to v0.1.1 in place, preserving host, port and saved settings. On a Chinese-system fresh configuration, English was still the default. Both English and Chinese choices persisted after force-stop / reopen. APK v1 / v2 signature verification passed, and the locally built old / new certificate SHA-256 matched; this does not guarantee another machine's debug key matches.

The actual client rendered the original 1280 × 720 card in both eyes. Hiding controls / Back recovery passed. Dragging scale to 1.0 and offsetX to -0.3 remained stable after two seconds. Without a rotation sensor, host-selected cinema actively returned to full screen, and selecting FPS also remained in full screen. Home / background disconnected the host; explicit Connect restored reception after foreground return or a host close. The test FakeInput.moves list stayed empty.

No FATAL, native-fatal or out-of-memory errors were observed. One EGL_BAD_SURFACE appeared while the old PopupWindow was recreated during a Chinese language selection; the new Activity continued rendering normally afterward, with no persistent GL failure. This is recorded as a nonblocking lifecycle observation, not a claim of an entirely empty GL error log.

v0.2.0-alpha checks

  • Windows host: 107 automated tests passed, including USB discovery / mapping ownership, iOS relay framing / pairing checks, loopback bootstrap restrictions, Windows DPI fallback, actual WebSocket wire messages, capture pacing, original GPU resources and fallback / cache integration. Local Windows builds use CPython 3.12.14.
  • Android: 36 tests passed (8 core and 28 app), APK / AAR build and lint passed after the final latency improvements. The same local debug certificate upgraded the attached HUAWEI Pura 70 Ultra from version code 1 to code 3 without uninstalling.
  • Physical phone: HUAWEI Pura 70 Ultra, reporting Android 12 / API 31 compatibility, received the original 960 × 540 calibration card over an actual data cable. USB and English were default. Authorized discovery, fresh-launch automatic connection, both-eye rendering and hidden controls / Back recovery passed. No manual IP or pairing code was entered in USB mode.
  • Chinese persisted after force-stop / reopen; switching language disconnected the host and required an explicit reconnect. A new process launch made its documented one-time USB connection attempt. In FPS mode the host received 877 real sensor pose messages during the observed interval. No operating-system mouse input was armed; the fake sink remained empty. These observations do not verify physical gyro axes or real-game control.
  • USB detection encountered a real Huawei difference: ADB did not return a usable USB path. The final Windows implementation verifies the physical USB serial through native SetupAPI enumeration. Emulators and network ADB remain excluded.
  • The same phone also received actual ASUS PA279 portrait desktop frames over USB at 540 × 960. Home / background disconnected the host, and returning to the foreground did not silently reconnect. Full desktop capture performance is measured separately below.
  • New screenshots show this phone and its USB reception; the source is an original calibration card, not a game. The phone's observed ping round trip of 4–7 ms is a connection diagnostic, not end-to-end video latency.

The final calibration USB session, at 960 × 540 / target 60 FPS / JPEG 60, recorded 60 consecutive host-send samples averaging 59.99 FPS (59.74–60.22) after the Windows pacing fix. The phone UI showed approximately 60 FPS received. This is a synthetic-content diagnostic on the physical USB path, not desktop-capture performance or an end-to-end latency benchmark. The earlier Windows tick-based pacing fluctuated around 32–64 FPS. Different content / capture costs require separate measurement.

The actual ASUS desktop USB session used the native GDI backend and produced 540 × 960 frames. Its 24 host-send FPS samples averaged 11.05, ranging from 8.2 to 12.11. When the display layout later changed, the layout guard stopped producing new frames; no operating-system mouse input was emitted. This establishes the observed capture / USB path and fail-closed behavior, not a 60 FPS desktop guarantee or end-to-end video latency.

CS2 and Discord remained running as requested. GPU 3D utilization was observed near full load, while Discord used approximately one CPU core. These are concurrent-load observations, not a controlled performance comparison, and do not establish which application caused the capture limit. The local native / MSS timing trials likewise ran on the busy desktop; their results must not be presented as controlled backend benchmarks.

After the user reported exiting Discord, the first short retest stopped on another real display-layout change. A fresh 540 × 960 USB session on the new layout then recorded 14 host-send samples averaging 8.62 FPS (7.87–9.54), no capture errors and no operating-system mouse moves. Discord background processes remained but used approximately 0% of one CPU core in a two-second sample. The primary display resolution differed from the earlier session, so these observations cannot isolate Discord as a cause. Both test hosts were stopped and their owned USB mappings removed.

The pre-optimization EXE started on the actual ASUS display in English with USB discovery. Its clean preference profile selected 960 / 60 / 60; existing capture settings remained Custom. The desktop preview automation tool later failed to capture its window during a changed display-resolution / scaling layout, so further GUI interaction was not counted as passing.

Original GPU capture follow-up

The production MssCaptureSource selected the original DXGI / D3D11 backend on the ASUS PA279, performed rotation / resize on the GPU and streamed its actual 2160 × 3840 desktop as 360 × 640 / Q45 / target 60 FPS over USB. The HUAWEI phone's decoded-frame UI readings were 59.9 and 57.7 FPS, with link round trips of 2 and 7 ms. The host recorded 41 send-stat samples averaging 59.66 FPS, range 45.97 startup–60.14; excluding the initial startup sample, mean send FPS was 60.00. There were 2,338 distinct JPEGs, 173 repeated / static reads, zero empty reads and zero capture errors. Repeated packets are not distinct desktop updates. Mean production read / resize / JPEG time was 4.06 ms. No operating-system mouse input was emitted. DXcam, NumPy and comtypes were absent from the production runtime.

The stable preset captured an original 1280 × 720 animation window on ASUS as 640 × 360 / Q50 / target 30 FPS. The phone read 30.2 FPS; 13 send-stat samples averaged 29.43 FPS including startup, or 30.00 after the startup sample. All 391 JPEGs differed, with no repeats or capture errors. An owned calibration image had red / green / blue / yellow in the correct four corners, verifying crop, portrait-source rotation and channel order. The quality preset captured the full portrait display as 540 × 960 / Q60 / target 30 FPS: the phone read 30.0 FPS; 14 host samples averaged 29.56 including startup, or 30.00 afterward, with 417 distinct JPEGs and five repeated reads. Mean read times were 4.26 ms stable / 7.71 ms quality.

These are bounded sessions on one GPU / display / phone setup, with an original moving window on the desktop. They establish an actual desktop-to-phone path above 30 FPS for the default, without a controlled same-resolution comparison to the earlier GDI tests. Capture time plus ping RTT is not end-to-end video latency. Decode, render scheduling, screen scanout and input-to-photon latency require separate measurement. Current defaults are 640 / 60 / Q45, stable 640 / 30 / Q50, quality 960 / 30 / Q60. See performance and attribution.

The final latency-improved APK upgraded this Huawei phone in place with the same signing certificate. Its UI showed 59.9 decoded FPS, 7 ms link RTT and 11.3 ms mean phone-local processing from complete-JPEG reception to texture submission. That phone metric excludes PC capture, link transport and physical display. In the bounded final host session, 39 send samples averaged 59.68 FPS; after startup, host capture averaged 4.06 ms, latest-frame queue 0.30 ms and submission to the local transport 0.11 ms. The original moving window started partway through: there were 1,117 distinct JPEGs and 1,280 repeated / static reads, so the whole session is not a 60-distinct-update benchmark. No capture errors or operating-system mouse moves occurred. Phone decoding now hands frames directly to the renderer through a session gate, and same-size / same-format uploads reuse the texture. These independently measured components must not be added and labelled end-to-end latency.

A later bounded test used only the Alienware AW2726DL, after the user changed the selected test display. Actual 2560 × 1440 desktop capture became 640 × 360 / Q45 / target 60 using the final pre/post-layout validation. There were 34 host send samples, mean 59.59 FPS, 1,889 distinct JPEGs and 212 repeated reads; distinct updates were approximately 53.59 per second over the instrumented source interval. After startup, host capture averaged 2.96 ms, queue 0.36 ms, local send submission 0.12 ms. After the bounded run ended, the phone retained its final-window readings of 56.7 decoded FPS, 7 ms RTT and 10.8 ms phone processing. These retained readings are not live values or session-wide phone averages. No capture errors or OS mouse output occurred; ASUS was not used in this run.

The release retains the previous API 23 / 36 results above as historical evidence; they are not fresh coverage of every v0.2.0 change. GitHub Actions run 37889266302 passed the iOS checks: 40 reusable-core tests, both Simulator / unsigned device builds, two native UI cases using real slider and precision-button touches, LAN / simulated USB reception, settings echo, and original-image color / orientation validation. These are Simulator results, not physical iPhone USB or a signed IPA.

Still needs physical testing

  • Other phones / Android derivatives, Wi-Fi, heat and battery life.
  • Real rotation sensors: axes, stability, recentering and cinema tracking.
  • Viewer optics: alignment, field of view, distortion and comfort.
  • Real FPS games: input acceptance, control feel and compatibility.
  • Other GPUs, display layouts, Windows scaling, protected / exclusive content.
  • Quality, throughput, dropped frames and end-to-end latency with specified hardware and network conditions.

Screenshots and unit tests must not be presented as passing these untested cases.

Build provenance

The first locally verified release used CPython 3.12.14 and has the recorded native inventory. Windows CI uses 3.12.10; its embedded DLL versions must be inspected separately. Check actual Actions status for remote build outcomes and audit a concrete binary before redistributing it.

Microsoft Visual C++ v14 x64 runtime is installed by the system, not shipped inside the EXE. See build and third-party notices.

v0.3.0-alpha checks and remaining limits

The original Python headset-fit geometry / local transaction has 28 pure tests passing: landscape / portrait fit, symmetric eye spacing, unclipped valid bounds, all four normally center-fixed corners, pan / scale / signed-separation clamps, all four selected-eye directions, small-image seam contact, remaining-gap X limits, enlargement contact correction, negative-profile commit / discard, gesture-start rather than accumulated deltas, invalid numeric snapshots and one-shot commit / discard. They perform no capture, GUI automation, USB operation or OS mouse injection.

After the signed-seam correction, the complete local Windows suite passed 152 tests plus 36 subcases, including the geometry cases and headless editor / reset integration cases. They cover draft isolation, entry disarm, blocking desktop arming while editing, saving only fit fields into current settings, full reset / persistence, English / automatic USB defaults, and preservation of explicit display / region / ADB path. They do not exercise the new Windows GUI through real user interactions. The signed-seam x64 EXE's static package audit matched 15 project modules, 44 notice files and all 38 recorded native DLL / PYD hashes, without bundled research libraries or Windows system D3D DLLs; this validates the specific local build, and final release assets still require their own checks.

The local Android build with the signed-seam correction passed 70 JVM tests (49 app / 21 core), APK / AAR compilation and lint with zero errors / eight warnings. It targets min API 23 / target 35 with version 0.3.0, code 4, and uses the same local debug certificate as the preceding installed APK. These are automated / build checks, not physical-phone editor acceptance.

The final local v0.3 APK was installed on the physical HUAWEI Pura 70 Ultra over authorized USB; pulling the installed APK matched the release candidate SHA-256. Windows captured an original 1280 × 720 card in the sole AW2726DL output, using GPU resize to 640 × 360. The Android GL viewport was 2844 × 1260. All four selected-eye horizontal directions, proportional corner shrink from 85% to 50%, draft / Discard isolation, and inward contact at 50% / separation −0.50 / X 0 passed. Host revision and stored phone preferences stayed unchanged during preview; Save increased revision once. Eight sampled center-seam pixels were the same nonblack card color, and the unmodified normal-view screenshot was visually checked. Force-stop / reopen restored the committed negative profile. See actual editor screenshots.

PC ↔ phone persistence was checked through the actual HostWindow commit / event / save handlers headlessly, without interacting with the new Windows GUI or injecting OS input. Phone Save reached the host and PC test preferences. A PC fit commit of scale 0.60 / separation −0.40 / Y 0.05 increased revision once and matched host / PC / phone committed profiles; phone restart retained it. Near the seam, shared X 0.20 resolved to zero and Save synchronized both sides. The public phone language control persisted Chinese across force-stop / reopen. The public Reset all button restored full VR defaults, English, USB, empty host, port 8765 and an empty pairing field, and immediately disconnected. A fresh launch resumed initial USB detection and restored the committed defaults after hello; reset did not authorize mouse input. No fatal, out-of-memory or GL diagnostic error was found for the app's own process in this run.

A separate 30.02-second v0.3 hardware stream used the same AW original region at 640 × 360 / Q45 / target 60. Thirty host samples averaged 60.00 sent FPS, with 1,612 distinct JPEG reads and 189 repeats, or 53.70 distinct reads/s. Mean host capture / conversion / JPEG time was 3.21 ms, latest-buffer queue 0.39 ms, and local send submission 0.13 ms; reported throughput was 4.99 Mbit/s. After video stopped, the phone retained its final statistics window of 59.7 FPS and 9.7 ms mean reception-to-texture-call return. Individual continuing ping readings in XML / screenshots were 8–11 ms, not a session RTT mean or min / max. These are separate clock / stage measurements, not unique physical display FPS or end-to-end delay; see performance.

The same final APK also passed 14 real application-UI checks on a Google-free Android 6.0 / API 23 emulator. Actual touches closed the seam at 50% / −0.50 and enlarged the corner to 76% / −0.24 / X 0 while retaining contact. Center-preview pixel / frame checks were nonblack; these are emulator / overlaid-preview evidence, not physical light or FPS measurements. Save once / Discard isolation, negative profile after restart and validated-hello restoration once, PC negative broadcasts, Chinese persistence, and complete reset defaults / empty connection fields passed. Only an original calibration card and a fake no-mouse sink were used; this is separate from the physical Huawei result.

Final GitHub Actions 37897738507 passed 152 Windows tests, 70 Android JVM tests, 65 Swift core tests and three native iOS Simulator UI cases, with no failures / skips. Both Simulator and unsigned device-target iOS builds succeeded. LAN / simulated USB both-eye color checks and exact nonblack seam-boundary checks passed. Real UI preview / Discard left settings counts unchanged, Save sent once with a negative separation, and PC broadcasts, offline / restart persistence and full reset passed. The simulator observer recorded no mouse moves. Forty-six tested iOS / fixture Git blobs matched the downloaded source ZIP. The Simulator app identifies as 0.3.0 / build 4 / iOS 15 minimum / arm64, includes the original MIT license, and is not an installable signed iPhone IPA. iOS screenshots are explicitly native Simulator evidence. No physical iPhone USB, headset optics, real FPS game, new Windows GUI interaction or end-to-end latency result is claimed. The completed v0.2 evidence and original release notes remain historical records.

简体中文

更新日期：2026-10-10。这里区分自动检查、电脑采集和模拟器观察；未验证的硬件能力不以截图或单元测试代替。

v0.4.0-alpha——已完成软件／打包检查

第四种“加强第一人称”使用固定物理 1:1 正方形、原创 GPU 逆角度采样与已有已保存适配控件；应用 0.4.0，手机构建号 8。以下记录已完成软件、界面、打包和原生模拟器证据，华为／PCVR 真机仍留待下次。以下证据对应当前候选，v0.3.4 旧证据仍是历史，见 投影约定 与 当前说明。

  • 完整本地 Windows 桌面套件通过 334 项测试及 204 个子测试；另一个脚本套件通过 22 项单元用例，不计入桌面数量。投影／几何、能力协商、旧端回退及保留的输入／连接边界属于软件检查，不是实际陀螺仪输入或游戏／视频测量。
  • 实际冻结预览 Windows 界面在 ASUS 显示器、隔离配置中，通过加强模式单选、正方形角点等比 0.85 → 0.50、镜像向内眼间距至 −0.55 接触、保存／重开及平移草稿 放弃；放弃后已提交 0.50／−0.55／X=0／Y=0 保持不变。保留两张未经修改的自有编辑器截图，教程示例 显示保存后重开的编辑器、原创合成网格与电脑近似网格；使用正式候选代码、最终通知重建前的预览，没有采集、手机连接、姿态或操作系统鼠标输出，不证明手机 GPU、F8／恢复或性能验收。
  • 干净 Android 单元检查通过 133 项（75 项 app＋58 项 core），APK 和 release AAR 构建通过；额外含 576 项几何／遮罩与 108 项投影用例的 instrumentation 仅编译，没有执行，不宣称新模式 Android 真机 GLES 已通过。
  • 本地 APK 经官方签名工具校验，匹配权威公开证书 SHA-256 c8221633041e9b4551cd6e9f4f657e7beeb0901a4b77999d1bfc11d3825b6d74。APK SHA-256 为 735472b004196fb8b5e9795cabee8197c94fc67d3e258336204fef33d271054f；有改动的 release AAR 为 088e9db45aa3e326fe8b4f790ac684417a1f27cf7711809a38e92367c84b6066。这证明构建产物身份，不是手机安装或串流验收。
  • 最终重建 Windows EXE 通过字节码／原生／通知审计：22 个自有模块对应当前源码，38 个原生文件准确匹配记录的当前来源，44 个许可文件及根目录三份通知逐字节相同。EXE SHA-256 为 3fe0fb08be5485975ff03c991622f2ff9a166ce69ef3f6263f14dd633b2002b7；原生文件与 v0.3.4 相同，其中 16 个也符合首版历史审计，22 个保留此前已核验的有效重新签名，PE 代码／资源未变。不附带 numpy、dxcam、comtypes、ADB 或系统 D3D DLL，保留 VRization 自身 DXGI 实现；完整预发布 Windows ZIP 在新配置、移除 SDK 环境变量并忽略意外当前目录 ADB 的条件下通过运行／链接检查，没有采集或操作系统鼠标输出；最终上传 ZIP 使用同一已核验 EXE 和完整文档重新生成，本地前一版已保留。
  • 独立 CPU 截图校验器校准接受 38 个原创参考采样，拒绝 两个缺失变形或比例错误的负面对照；这是校验器／参考图片检查，不是手机实际 GPU 或原生界面输出。
  • Actions 38088502161 在源码 ae3469e7a7e54d6de079aeae6f55a524a03e8b0f 的四项任务全部通过。iOS 独立审核确认 95 项 Swift 核心零失败、七项真实原生界面零失败／跳过及模拟器／未签名真机 SDK 构建通过；环境为 arm64 iPhone 17 Pro Max 模拟器、iOS 26.2、Xcode 26.3.0（17C529）、macOS 15.7.9，应用 0.4.0／构建 8／最低 iOS 15。独立解码全部 26 张原创原生 PNG，通过 **38 项加强检查（12 RGB、四项弯曲边框、20 项黑遮罩、两项准确接缝）**和 16 项旧模式颜色／方向及两项接缝；全部 15 个 ready／connected 主机检查点操作系统鼠标输出为零，准确 commit 的像素校验器重放与报告一致。一次刻意取消等待中的 LAN 升级产生 ConnectionReset 警告，没有原生测试失败。USB 为模拟，不是真实 Apple 服务／数据线；模拟器 ZIP SHA-256 为 91aef23bd987d6aa7d14735bffd97ebf134a3fe2092c286902672797b2bf060a。未修改的原生 Metal 例子 显示原创校准卡，不是用户参考图或真实 iPhone 截图。
  • 用户明确将 华为与 PCVR 真机测试留到下次聊天。本轮没有进行新版手机安装、真机 GLES／Metal、镜片、陀螺仪／游戏手感、真实端到端延迟或 SteamVR／头显测试；独立 SteamVR 实验版本仍为计划，普通直连手机文件与发布历史保留。

v0.3.4-alpha — 已完成软件／打包检查

Windows、Android 与 iOS 应用为 0.3.4、手机构建号 7，可复用 Android 核心 AAR 不变。Windows 界面默认启用所有前台窗口中的第一人称陀螺仪鼠标；以下已完成软件／打包／原生模拟器结果，不代表真机陀螺仪／游戏／视频／延迟或高级 Windows 界面验收。

  • 源码 101174317613520c7d98375332c2a3bd9032cb2d：Windows 构建脚本的完整测试通过 318 项。其中 31 项新增测试为 17 项控制器和 14 项 GUI／存储／真实回环连接用例，包含 Stop／重开；使用假输入与合成采集，没有执行操作系统鼠标或真实桌面采集。它们证明软件策略／生命周期，不代表真机陀螺仪或游戏手感。
  • 冻结 v0.3.4 EXE 匹配全部 21 个自有模块，按当前记录来源匹配全部 38 个原生哈希，包含 44 个许可文件及根目录三份通知。SHA-256：19f19409cb1331e42b988e7a3f9b32920bd2c33397eb7fe687933abeca024a5d。相对 v0.3.3，22 个 CPython 原生文件哈希仅因有效重新签名变化，PE 代码与资源保持不变；首版历史审计记录未改。发布 Windows ZIP 在新偏好、没有 SDK 环境变量下通过运行 smoke 检查；该诊断没有采集／输入。
  • 用户确认华为真机覆盖升级至 0.3.4／构建 7，没有卸载或清除数据。拉取的已安装 APK 与发布 SHA-256 c1be9b8ba11f8941844dbb9b84ebc463b695807874605a93c94dc238f32c70ad 一致；证书匹配原公开 SHA-256 指纹 c8221633041e9b4551cd6e9f4f657e7beeb0901a4b77999d1bfc11d3825b6d74。
  • 已观察新版 Windows 界面初次启动与可见的 0.3.4 版本。高级界面检查因用户实际按下 Escape 而停止，因此不宣称实际界面 Resume／F8 已验收；新版真机陀螺仪控制、游戏手感、视频传输与延迟未测试。
  • 干净 Android 测试通过 116 项（应用 67＋核心 49），零失败／忽略；APK、不变的可复用 AAR、测试工具编译和 lint 通过。Lint 零错误、九项 CI 警告：八项既有本地警告，加 CI SDK 清单产生的 OldTargetApi；没有抑制警告。
  • Actions 38081097956 四项任务在源码 101174317613520c7d98375332c2a3bd9032cb2d 全部通过。独立 iOS 核验确认 80 项 Swift 核心零失败、五项真实原生界面零失败／跳过，模拟器和未签名真机目标两种 SDK 构建通过；环境为 arm64 iPhone 17 Pro Max 模拟器、iOS 26.2、Xcode 26.3、macOS 15.7.9。独立解码截图通过 12 项颜色像素与两项接缝检查，全部 12 个电脑检查点鼠标移动列表为空。USB 明确为模拟，未测试真实 iPhone USB；模拟器应用标识 0.3.4／构建 7／最低 iOS 15／arm64，不是可安装到 iPhone 的 IPA。以下旧结果仍对应已发布版本。

v0.3.3-alpha — 已发布检查

  • 源码 76639de380c2b4dd26ce860dada30a24323874e8 的完整本地 Windows 测试通过 287 项及 135 个子用例。其中用真实 localhost WebSocket 测试断线后的发送清理阻塞：清理前撤销电脑状态 / 输入，新会话仍可连接，旧清理不能影响新资源归属。Android 116 项单元测试、APK / release AAR 构建、lint 和测试工具编译通过；签名门槛六项测试通过，文档检查覆盖 36 页完整双语及本地链接。
  • 最终冻结 Windows EXE 匹配全部 21 个自有模块、38 个已记录原生哈希，包含 licenses/ 下 44 个文件及根目录三份通知。SHA-256：50d631ab2dfc0f0220b6da4d993fa5b916d8615ff87c19d5fa6773d96d50cf8c。公开 ZIP 在清空 SDK 环境变量、新偏好下通过独立运行检查，该检查没有采集 / 输入；Android 官方工具仍独立安装。
  • 华为真机已安装 0.3.3 / 构建 6，中文界面可见版本号。安装包与本地发布 APK 一致，SHA-256 为 2ae72ee5180b6b918f88680c87edb30d0dc3d12bd1cb7a87eab8b3e38ade58da，官方 apksigner 验证与原公开证书一致；覆盖升级保留应用数据。
  • 最终 EXE 采集 ASUS PA279，真机六次连接 / 断开循环每次收到至少五帧真实解码桌面；每次断开之后完整一秒没有新帧，两眼像素与渲染纹理均清空。同步电脑健康状态记录显示已断开。实际点击电脑 Stop 关闭观看会话，手机清空画面且一秒没有新帧；手机主动连接随后能启动已停止的电脑串流并收到至少五帧。关闭 EXE 后两条自有映射被释放，普通 Start-Windows.bat 用隔离的新电脑偏好、仅从启动器继承 SDK 配置，重开同一 EXE 并通过其中两次循环。全程没有拔 USB 或重启 ADB 服务。测试采用只读偏好包装，确认手机原保存设置不变，并禁用姿态输出。
  • 独立点击真实电脑“连接 / 开始串流”按钮，也连接了已打开的手机应用。电脑界面出现一次约 60 FPS 的发送样本，不代表新增端到端延迟测量或帧率保证。Windows 已遮罩受保护区域，修正的 DXGI 路径使用该系统遮罩画面，仍保留布局 / 访问 / 资源故障保护。
  • 最终 Actions 38035750560，源码 cb22ebb1727846cdffea491d553ad4f52df4774f，通过 Windows、Android、文档和 iOS 任务。Mac 在 arm64 iPhone 17 Pro Max 模拟器、iOS 26.2（Xcode 26.3 / macOS 15.7.9）通过 80 项 Swift 核心与五项真实原生界面用例，零失败 / 跳过；模拟器与未签名真机目标两种构建通过。局域网 / 模拟 USB 的 Metal 颜色检查通过 16 个采样，准确接缝检查通过两个采样；12 个电脑检查点全部存在，操作系统鼠标移动为零。原生用例覆盖延迟局域网升级、取消 / 超时清屏、替换会话、USB 停止确认与重新连接；测试服务的 12 项启动 / 生命周期检查也通过。此次改动仍未验证真实 iPhone USB、实际游戏输入或动作到显示延迟。

v0.3.2-alpha — 历史检查

  • 最终 Actions 37991498159，源码 a9afaceabc5f237d31794a271ac5bc2ed6eb006b，Windows / Android / iOS / 文档任务全部通过。Windows 220 项测试通过，完整公开 ZIP 通过脱离开发 SDK 的独立运行检查；Android APK / AAR 测试、构建、lint 通过。文档检查验证分区 / 链接结构，不评价翻译质量。
  • 冻结本地 x64 Windows EXE 静态审计匹配 19 个自有模块、47 份通知及 38 个已记录原生组件，未附带禁止的研究运行库或系统 D3D DLL。SHA-256 为 19eaebd0d1420872b76db7add6fa3aee0835a4f18987a2bd997bcccee665378d。清空 SDK 变量、使用新偏好后，该 EXE 选择 portable_executable 工具，识别一台已授权真实 USB 手机，诊断完成且无错误，没有发现旧开发 SDK 回退；官方工具仍另行安装。
  • HUAWEI Pura 70 Ultra 真机安装最终 Android 候选，拉回 APK 匹配 SHA-256 1a3094c8c182930bcf96c571412442104df2e4b7123914cf6316a1e7b7a1ff7e。实际拖动防抖滑块后，50% 本地保存并到达主机；主机更新 65% 后手机保存，重启保留并恢复到主机。原观看配置保留，操作系统鼠标移动为零。这是设置 / 持久化检查，不是真实游戏防抖验收。未修改的设置截图 为临时 65%，默认仍为 0%。
  • 同一真机自定义 GLES 检查通过双眼共 288 个离屏遮罩用例，覆盖解析后的物理显示范围；这是图形代码 / 像素检查，不是盒子镜片或运动到光子延迟。
  • 原创卡的手机先启动 USB 重试通过：手机启动后 6.08 秒才启动测试主机，手机启动后 7.67 秒成功连接，即主机启动后 1.59 秒。配置不变、操作系统鼠标移动为零。这是一次有限启动结果，不是永久后台重连或长期稳定保证。
  • 最终 Actions 37991498159 在 arm64 iPhone 17 Pro Max 模拟器、iOS 26.2（Xcode 26.3.0 / macOS 15.7.9）通过 77 项 Swift 核心与五项真实原生界面用例，零失败 / 跳过；模拟器与未签名真机目标构建都通过。局域网 / 模拟 USB 的 Metal 双眼颜色与行方向，以及准确视口中缝边界像素检查通过。这是模拟器 / 软件桥接结果，不是 iPhone 真机、真实 Apple USB 服务或已签名 IPA。

官方 Windows Platform Tools 37.0.1 ZIP 已实际导入独立测试目录，完整 NOTICE 保留；不宣称导入器界面交互已验收。较早构建的普通启动器也在便携 SDK 配置后由用户确认可见画面。打包应用存储的 SDK 可见性是一个已核实的发现问题，共享 ADB 会话和手机授权掉线另有实际观察；一次授权重启后，仍需用户切换手机 USB 调试才恢复。未发现旧电脑端界面或端口冲突，不把全部历史故障过程只归因于 MSIX。

合成滤波检查覆盖 0% 精确绕过、运动输入、平滑与重置 / 不输出边界，不测量真实游戏手感或物理延迟。真实 iPhone USB、盒子镜片、真实第一人称游戏输入、新 Windows 编辑器界面交互与端到端延迟仍未验证。下方历史性能数字保留原发布 / 配置范围。

首发已完成

项目 环境与结果 能说明什么
电脑端核心检查 Windows x64，本机 CPython 3.12.14，12 项检查通过。 设置 / 协议校验、姿态输入授权、长边缩放和模块行为通过所列检查。
Android 核心检查 JDK 17、Gradle 8.9、AGP 8.7.3，6 项单元检查通过。 姿态数学、角度处理与任意倾斜回正等逻辑通过检查。
Android 构建与静态检查 首发 APK 的 assembleDebug、lintDebug 成功。 能生成 APK；不等于所有设备兼容性验证。
Windows 最终程序 本机 EXE 打包成功，附带 40 份许可文件；不包含 Microsoft VCRUNTIME140*.dll。 打包与许可随附已检查；微软运行库由系统安装提供。
Windows 显示器采集 ASUS PA279，2160 × 3840 纵向显示器；最长输出边设为 1280，确认输出为 720 × 1280。 纵向整屏可采集，按原始比例缩放并限制最长边。
电脑教程截图 1054 × 963，截取本项目电脑端界面；截图选择上述 ASUS 显示器。 展示真实按钮、模式、显示器选择与串流设置。
Android 安装、连接和显示 无 Google 服务的 Android 6.0 / API 23 模拟器，安装首发 APK，接收原创动态校准卡。 APK 可在该环境启动，JPEG / WebSocket 接收与双眼显示可运行。
实际桌面到 Android 串流 首发 APK 在上述模拟器接收实际 ASUS 桌面采集，确认帧尺寸为 720 × 1280，连接保持。 除示例帧外，真实 Windows 采集 → 网络 → Android 显示路径也已连接验证。
设置操作 模拟器显示缩放、位置、双眼间距、畸变控制；隐藏操作区后仍显示双眼画面。 界面与观看流程可操作。
设置边界值往返 实际 Android 界面把水平位置设为 0.3、双眼间距设为 0.2，主机接受、回传并保存，连接保持。 浮点边界值不会因序列化误差被主机误拒绝。
无传感器回退 模拟器没有可用旋转传感器，客户端可使用全屏模式。 无传感器设备的固定画面路径可运行。

较早的模拟器截图文件展示最终 v0.1.1 英文界面，对应 examples/embedded_host.py 的原创校准卡，未用真实游戏画面冒充实机测试。接收帧率是当次连接状态，没有测量端到端延迟，也不构成性能基准；上表仍保留首发的历史记录。

上述模拟器使用软件图形渲染；实际桌面连接测试的接收读数同样不能代表 Android 真机、手机盒子或真实无线网络的性能。没有根据这些读数承诺游戏帧率。

v0.1.1-alpha 补充检查

  • 电脑端 20 项自动检查通过，涵盖并发设置同步与语言处理。
  • Android 15 项检查通过（6 项核心数学、9 项应用设置顺序 / 会话分发回归），v0.1.1 APK 构建与 lint 通过。
  • 真实 Windows 11 build 26200 / ASUS 显示器检查默认英文、中文切换、重开后保留、串流中切换与 1060 × 680 小窗滚动；切换语言会解除鼠标授权。
  • 20 个自有公共页面的语言顺序、分区与本地文件链接检查通过；Windows 与 Android 许可 ZIP 已实际打包并通过离线链接检查。6 个检查器烟雾用例和临时嵌套 Markdown 的发现检查通过；这些检查不判断翻译质量。
  • 最终打包 Windows EXE 已在真实 ASUS 显示器以英文启动，界面响应正常。

Android 16 / API 36 — 最终 v0.1.1 APK

在不含 Google 服务的 AOSP 模拟器测试，v0.1.0 可覆盖升级到 v0.1.1（version code 2）。默认英文，切换中文后强制停止再打开仍保留中文，再切回英文成功。

实际客户端经 WebSocket 接收 1280 × 720 原创校准卡并通过 OpenGL 显示双眼画面。电脑切大屏幕 / FPS 后客户端保留相应模式，Android 传感器服务注册 Game Rotation Vector；回到全屏后注销。这不代表真实陀螺仪轴向或真实 FPS 输入已经通过。

隐藏操作区与返回键恢复通过。进入后台后主机连接状态变为 false，没有鼠标输出。切换语言、Home 进入后台、服务端 1001 关闭之后，均显式点击连接即可恢复接收。这些检查期间未观察到 AndroidRuntime、OpenGLRenderer 或 libEGL 错误；接收帧率读数不作为性能基准。

Android 6.0 / API 23 — 最终 v0.1.1 APK

相同本地 debug 签名从 v0.1.0 原地升级到 v0.1.1，保留 host、port 与设置。系统中文的首次配置仍默认英文，English / 中文各自选择后强制停止再开均保留。APK v1 / v2 签名验证通过，本机构建旧新版证书 SHA-256 一致；这不保证其他机器的 debug key 相同。

实际客户端显示 1280 × 720 原创卡的双眼画面，隐藏 / 返回恢复通过。拖到 scale 1.0、offsetX -0.3 并等待两秒后值保持稳定。没有旋转传感器时，主机推大屏幕会主动回全屏，选择 FPS 也保持全屏。Home 进入后台后主机断开，回前台或主机关闭后显式点击连接均恢复接收；测试 FakeInput.moves 始终为空。

未观察到 FATAL、原生 fatal 或内存不足错误。中文语言选择重建旧 PopupWindow 时出现过一次 EGL_BAD_SURFACE，随后新 Activity 持续正常渲染，没有持续 GL 失败。这里如实记录为非阻塞生命周期观察，不声称该环境的 GL 错误日志完全为空。

v0.2.0-alpha 检查

  • Windows 电脑端 107 项自动检查通过，包含 USB 识别 / 映射归属、iOS 中继分帧 / 配对、回环 bootstrap 限制、Windows DPI 回退、实际 WebSocket 报文、采集节奏、原创 GPU 资源及回退 / 缓存接入。本地 Windows 使用 CPython 3.12.14 构建。
  • Android 36 项检查通过（核心 8、应用 28），最终延迟优化后的 APK / AAR 构建与 lint 通过。同一本地 debug 证书在接入的 HUAWEI Pura 70 Ultra 从 version code 1 覆盖升级到 code 3，无需卸载。
  • 真机 HUAWEI Pura 70 Ultra 报告 Android 12 / API 31 兼容层，经真实数据线接收 960 × 540 原创校准卡。默认 USB 和英文，授权发现、新启动自动连接、双眼渲染、隐藏设置 / 返回恢复通过，USB 未手填 IP 或配对码。
  • 中文在强制停止 / 重开后保留；切换语言会断开并要求显式重连。新进程启动进行了文档约定的一次 USB 自动尝试。FPS 模式的观察区间收到 877 条真实传感器姿态消息，未授权操作系统鼠标，假接收器保持为空。这不代表陀螺仪实际轴向或真实游戏控制已经验证。
  • 真机测试发现华为差异：ADB 未提供可用 USB 路径。最终 Windows 实现通过原生 SetupAPI 枚举确认真实 USB 序列号，继续排除模拟器与网络 ADB。
  • 同一手机还经 USB 接收真实 ASUS PA279 竖屏桌面，尺寸 540 × 960。Home 进入后台后主机断开，回到前台不会悄悄重连；整屏采集性能另行记录如下。
  • 新截图展示此手机的 USB 接收，来源是原创校准卡而非游戏。手机观察到 4–7 ms ping 往返仅作连接诊断，不是端到端视频延迟。

最终 960 × 540 / 目标 60 FPS / JPEG 60 校准 USB 会话在 Windows 节奏修复后，连续 60 个电脑发送样本均值 59.99 FPS（59.74–60.22），手机接收读数约 60 FPS。这是实际 USB 路径上的合成内容诊断，不是桌面采集成绩或端到端延迟基准。此前 Windows tick 等待的读数约在 32–64 FPS 间波动；其他内容 / 采集负担需要分别测量。

实际 ASUS 桌面 USB 会话使用原生 GDI 后端，输出 540 × 960 帧；24 个电脑发送 FPS 样本均值 11.05，范围 8.2–12.11。随后显示布局改变，布局保护停止产生新帧，没有发出操作系统鼠标输入。这说明当次实际采集 / USB 路径与异常停止行为，不代表桌面可保证 60 FPS，也没有测量端到端视频延迟。

按用户要求，CS2 和 Discord 保持运行。观察到 GPU 3D 利用率接近满载，Discord 约占用一个 CPU 核心。这些只是同时运行负载的观察，不是受控性能对比，也不能确定哪个应用造成采集限制。本地原生后端 / MSS 计时试验同样在忙碌桌面运行，不把读数作为受控后端性能基准。

用户报告退出 Discord 后，第一次短复测因另一次实际显示布局变化停止。按新布局重新启动 540 × 960 USB 会话后，14 个电脑发送样本均值 8.62 FPS（7.87–9.54），没有采集错误，没有操作系统鼠标移动。Discord 后台进程仍存在，但两秒采样约占一个 CPU 核心的 0%。主显示器分辨率与之前不同，因此这些观察无法单独确定 Discord 是否造成问题。两个测试主机均已停止，并移除了各自建立的 USB 映射。

优化前的 EXE 在实际 ASUS 显示器以英文启动并识别 USB，当时全新偏好选中 960 / 60 / 60，已有采集设置保留为自定义。桌面分辨率 / 缩放布局变化期间，界面预览自动化工具随后无法捕获窗口，因此不把后续 GUI 操作计为通过。

原创 GPU 采集补充检查

正式 MssCaptureSource 在 ASUS PA279 选择原创 DXGI / D3D11 后端，在 GPU 完成旋转和缩放，把真实 2160 × 3840 桌面以 360 × 640 / Q45 / 目标 60 FPS 经 USB 发送。华为手机解码帧率读数为 59.9、57.7 FPS，链路往返分别为 2、7 ms。电脑 41 个发送样本均值 59.66 FPS，范围 启动阶段 45.97–60.14；去掉首个启动样本后均值 60.00。统计到 2,338 张不同 JPEG、173 次重复 / 静态读取、零空读取、零采集错误；重复发送不算新的桌面更新。正式采集 / 缩放 / JPEG 平均 4.06 ms，没有发出操作系统鼠标输入。正式运行环境没有 DXcam、NumPy 或 comtypes。

稳定预设在 ASUS 采集原创 1280 × 720 动画窗口，输出 640 × 360 / Q50 / 目标 30 FPS。手机读数 30.2 FPS；电脑 13 个发送样本含启动均值 29.43 FPS，去掉首个启动样本后 30.00。391 张 JPEG 均不同，无重复、无采集错误。原创校准画面的红 / 绿 / 蓝 / 黄四角位置正确，验证了选区、竖屏来源旋转与颜色通道。画质预设采集竖屏全屏，输出 540 × 960 / Q60 / 目标 30 FPS，手机 30.0 FPS；电脑 14 个样本含启动均值 29.56，之后 30.00，417 张不同 JPEG、五次重复读取。平均读取时间分别为稳定 4.26 ms / 画质 7.71 ms。

这是同一 GPU / 显示器 / 手机上的限时会话，桌面包含原创动态窗口。默认预设的真实桌面到手机路径超过 30 FPS，但与此前 GDI 测试没有做相同分辨率的严格对照。采集耗时加 ping 往返不是端到端视频延迟。 解码、渲染调度、屏幕扫描和输入到显示仍需分别测量。当前默认 640 / 60 / Q45，稳定 640 / 30 / Q50，画质 960 / 30 / Q60。见 性能与来源说明。

最终低延迟 APK 用相同签名在此华为手机覆盖安装。界面显示 59.9 解码 FPS、7 ms 链路往返，以及从完整 JPEG 接收到纹理提交的 11.3 ms 手机本地平均处理耗时；该手机指标不含电脑采集、链路和物理屏幕显示。最终限时电脑会话 39 个发送样本均值 59.68 FPS；启动之后电脑采集平均 4.06 ms、最新帧排队 0.30 ms、提交给本地连接 0.11 ms。原创动态窗口在会话中途启动，统计 1,117 张不同 JPEG、1,280 次重复 / 静态读取，因此整个会话不能当作每秒 60 次不同桌面更新的基准。没有采集错误或操作系统鼠标移动。手机解码通过会话门直接把帧交给渲染器，相同尺寸 / 格式上传复用纹理。这些独立测得的环节不能相加并称为端到端延迟。

用户改变测试显示器后，后续限时测试只使用 Alienware AW2726DL，以最终采集前后布局校验采集真实 2560 × 1440 桌面，输出 640 × 360 / Q45 / 目标 60。电脑 34 个发送样本均值 59.59 FPS，1,889 张不同 JPEG、212 次重复读取；仪表记录区间的不同更新约 53.59 次每秒。启动后电脑采集平均 2.96 ms、排队 0.36 ms、本地发送提交 0.12 ms。限时会话结束后，手机保留的末次统计窗口读数为 56.7 解码 FPS、7 ms RTT、10.8 ms 手机本地处理；这不是当时仍在串流的实时值，也不是整段手机平均。没有采集错误或系统鼠标输出，此轮没有使用 ASUS。

上面的 API 23 / 36 结果保留为历史证据，不代表重新覆盖 v0.2.0 的所有改动。GitHub Actions 37889266302 的 iOS 检查通过：40 项可复用核心测试、模拟器 / 未签名真机目标构建、两个通过实际滑条与精确按钮触摸的原生界面用例、局域网 / 模拟 USB 接收、设置回传，以及原创图像颜色 / 方向校验。这些是模拟器结果，不代表 iPhone 真机 USB 或已签名 IPA。

仍需实机验证

  • 其他 Android 手机 / 衍生系统、无线网络、发热与续航。
  • 真实陀螺仪 / 旋转传感器的方向、稳定性、回正和大屏幕转头体验。
  • 手机 VR 盒子的镜片对齐、视场角、畸变与佩戴舒适度。
  • FPS 游戏实际接收鼠标输入的行为、头部控制手感与兼容性。
  • 不同 GPU、显示器组合、Windows 缩放和受保护 / 独占全屏内容。
  • 硬件与网络条件明确的画质、帧率、丢帧、流量和端到端延迟测量。

这些未完成项不影响已有源码、自动检查与模拟器串流记录的真实性，也不应被描述为已经通过。

构建来源与审计范围

首发本机构建使用 CPython 3.12.14，仓库原生运行时清单对应该产物。Windows CI 固定 CPython 3.12.10，不能据此宣称两个构建的内置 DLL 版本相同。重新发布时对具体产物核查许可与运行组件；以 GitHub Actions 的实际运行状态判断远程构建是否成功。

Windows 程序使用系统安装的 Microsoft Visual C++ v14 x64 运行库，不在 EXE 中分发 VCRUNTIME140*.dll。完整说明见 构建指南 与 第三方声明。

v0.3.0-alpha 检查与剩余限制

原创 Python 盒子适配几何 / 本地事务已有 28 项纯检查通过：横竖比例、对称双眼间距、合法边界不偷偷裁切、四个通常中心固定角点、平移 / 缩放 / 有符号间距限制、选中眼四种方向、小画面中缝接触、剩余间隙对 X 限位、接触放大修正、负值保存 / 放弃、手势起点而非重复累加、非法数字快照及一次提交 / 放弃。检查不采屏、不做界面自动化、不操作 USB、不注入系统鼠标。

有符号接缝修正后，本地完整 Windows 套件 152 项测试及 36 个子项通过，包含几何与无真实界面的编辑 / 重置集成检查：草稿隔离、进入解除授权、电脑编辑期间禁止授权、只将适配字段合并到当前设置、全部重置 / 保存、英文 / USB 自动默认，以及保留明确显示器 / 选区 / ADB 路径。它们没有通过真实用户操作验收新的 Windows 界面。该有符号接缝版 x64 EXE 静态审计匹配 15 个自有模块、44 份许可通知及全部 38 个原生 DLL / PYD 哈希，没有附带研究库或 Windows 系统 D3D DLL；这是针对本地具体构建的检查，最终发布资产仍需各自核查。

有符号接缝修正后的本地 Android 构建70 项 JVM 检查通过（应用 49 / 核心 21），APK / AAR 编译及 lint 通过，零错误 / 八条警告。最低 API 23、target 35、版本 0.3.0 / code 4，沿用此前已安装 APK 的本地 debug 证书；这是自动化 / 构建检查，不是手机实机编辑器验收。

最终本地 v0.3 APK 已通过授权 USB 安装到 HUAWEI Pura 70 Ultra 真机，拉回已安装 APK 的 SHA-256 与候选产物一致。Windows 在唯一 AW2726DL 输出选定 1280 × 720 原创卡区域，通过 GPU 缩到 640 × 360；Android GL 视口为 2844 × 1260。选中眼四种横向方向、角点从 85% 等比缩到 50%、草稿 / 放弃隔离，以及 50% / 间距 −0.50 / X 0 收拢相接均通过。预览期间主机 revision 与手机已存偏好不变，保存只增加一次 revision；中缝八个采样像素均为相同非黑测试卡颜色，普通观看原图也已目视核对。强制停止 / 重开恢复已提交负间距配置，见 真实编辑截图。

电脑 ↔ 手机持久化通过实际 HostWindow 提交 / 事件 / 保存处理器无界面调用检查，没有操作新 Windows 界面或注入系统输入。手机保存到达主机及电脑测试偏好；电脑提交缩放 0.60 / 间距 −0.40 / Y 0.05 只增加一次 revision，主机 / 电脑 / 手机已提交配置一致，手机重启仍保留。接近中缝时共用 X 0.20 解析归零，保存后两端一致。手机公开语言控件选择中文后，强制停止 / 重开仍保留；公开全部重置按钮恢复完整 VR 默认、英文、USB、空主机、8765 端口和空配对字段，并立即断线。全新启动恢复初次 USB 检测，hello 后恢复已提交默认值；重置不授权鼠标。本轮应用自身进程未找到 fatal、内存不足或 GL 诊断错误。

独立的 30.02 秒 v0.3 硬件串流使用同一 AW 原创区域、640 × 360 / Q45 / 目标 60。30 个主机样本平均 60.00 发送 FPS，1,612 次不同 JPEG 读取、189 次重复，即 53.70 次不同读取/秒。主机采集 / 转换 / JPEG 均值 3.21 毫秒、最新帧缓冲 0.39 毫秒、本地发送提交 0.13 毫秒，报告吞吐 4.99 Mbit/s。停止视频后手机保留最终统计窗口 59.7 FPS、接收到纹理调用返回均值 9.7 毫秒；继续 ping 的 XML / 截图个别读数为 8–11 毫秒，不是整段 RTT 均值或最小 / 最大值。这些属于不同的时钟 / 阶段，不是物理屏幕独特帧率或端到端延迟，见 性能说明。

同一最终 APK 还通过无 Google 的 Android 6.0 / API 23 模拟器 14 项真实应用界面检查：实际触摸在 50% / −0.50 收拢，再拖角点放大到 76% / −0.24 / X 0 仍相接；中央预览像素 / 边框检查非黑。这是模拟器 / 带覆盖控件预览证据，不是物理光子或 FPS 测量。一次保存 / 放弃隔离、负配置重启及合法 hello 一次恢复、电脑负设置广播、中文记忆、完整重置默认 / 空连接字段均通过；只使用原创卡和假无鼠标接收器，与华为真机结果分开。

最终 GitHub Actions 37897738507 通过 Windows 152 项、Android 70 项 JVM、Swift 核心 65 项及 iOS 原生模拟器界面三项，无失败 / 跳过；模拟器与未签名真机目标两种 iOS 构建成功。局域网 / 模拟 USB 双眼颜色及准确中缝非黑边界检查通过；真实界面预览 / 放弃不改变设置计数，保存只发送一次负间距配置，电脑广播、离线 / 重启持久化及全部重置通过，模拟器观察器没有鼠标移动。46 个已测试 iOS / fixture Git blob 与下载源码 ZIP 一致；模拟器应用为 0.3.0 / build 4 / 最低 iOS 15 / arm64，含原创 MIT 许可，不是可安装的已签名 iPhone IPA。iOS 图例 明确属于原生模拟器证据。不宣称真实 iPhone USB、盒子镜片、真实 FPS 游戏、新 Windows 界面实际交互或端到端延迟已验证；v0.2 完成证据及 原发布说明 仍保留为历史。