If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/barry-ran/QtScrcpy shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 5w ago
• 15 active contributors
• Distributed ownership (top contributor 47% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live barry-ran/QtScrcpy repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/barry-ran/QtScrcpy.

What it runs against: a local clone of barry-ran/QtScrcpy — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in barry-ran/QtScrcpy | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch dev exists | Catches branch renames | | 4 | Last commit ≤ 65 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of barry-ran/QtScrcpy. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/barry-ran/QtScrcpy.git
#   cd QtScrcpy
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of barry-ran/QtScrcpy and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "barry-ran/QtScrcpy(\\.git)?\\b" \\
  && ok "origin remote is barry-ran/QtScrcpy" \\
  || miss "origin remote is not barry-ran/QtScrcpy (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify dev >/dev/null 2>&1 \\
  && ok "default branch dev exists" \\
  || miss "default branch dev no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 65 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~35d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/barry-ran/QtScrcpy"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A software project. See architecture tab.

Developers.

See activity metrics.

Standard open source risks apply.

Check recent commits.

Check README for instructions.

Explore the code to find key files.

Fork and submit a PR.

Standard debugging applies.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for audio output pipeline (audiooutput.cpp/h)

The audio module (QtScrcpy/audio/audiooutput.cpp) currently has no visible test coverage. Given that audio synchronization is critical for a real-time device control application, adding unit tests would catch regressions in audio buffering, format conversion, and device switching. This directly supports the 'performance' and 'low latency' goals stated in the README.

• [ ] Create QtScrcpy/audio/tests/ directory with audiooutput_test.cpp
• [ ] Mock Qt's QAudioOutput/QAudioDeviceInfo classes using Google Test or Qt Test framework
• [ ] Write tests for: audio device enumeration, PCM format handling, buffer underflow scenarios, and audio stream lifecycle
• [ ] Integrate tests into CMakeLists.txt with a new test target (e.g., qtscrcpy_audio_tests)
• [ ] Add test execution to GitHub Actions workflows (.github/workflows/)

Add render pipeline unit tests for qyuvopenglwidget (render/qyuvopenglwidget.cpp)

The video rendering component (QtScrcpy/render/qyuvopenglwidget.cpp/h) is critical for the '30~60 fps' performance goal and quality requirements ('1920×1080 or above'). No visible tests exist for YUV to RGB conversion, frame buffering, or OpenGL context handling. Tests would prevent frame corruption and performance degradation across platform updates.

• [ ] Create QtScrcpy/render/tests/ directory with qyuvopenglwidget_test.cpp
• [ ] Use Qt Test framework with offscreen OpenGL rendering (QOffscreenSurface, QOpenGLContext)
• [ ] Write tests for: YUV420 format decoding, frame rate stability, resolution changes, and memory leak detection
• [ ] Create small test YUV frames (e.g., 320×240) to avoid large binary test data
• [ ] Add test target to CMakeLists.txt and integrate into all three platform workflows

Add integration test for multi-device group controller (groupcontroller/groupcontroller.cpp)

The groupcontroller module (QtScrcpy/groupcontroller/groupcontroller.cpp/h) orchestrates multiple connected Android devices but appears untested. Without tests, scaling from single to multi-device scenarios is error-prone. Integration tests would verify device lifecycle management, command broadcasting, and error isolation between devices—essential for a reliable multi-device tool.

• [ ] Create QtScrcpy/groupcontroller/tests/ directory with groupcontroller_test.cpp
• [ ] Mock ADB device connections using fixtures that simulate device connect/disconnect/error scenarios
• [ ] Write tests for: adding/removing devices, broadcasting input commands, handling device disconnections gracefully, and state synchronization
• [ ] Use Qt Test framework with QSignalSpy to verify controller signals (deviceAdded, deviceRemoved, etc.)
• [ ] Document test scenarios in QtScrcpy/groupcontroller/tests/README.md and run via CMake test target

Check the issue tracker.

QtScrcpy demonstrates a reasonable security posture for an open-source Qt/C++ application. The primary concerns are: (1) an outdated pinned Python dependency (dmgbuild 1.4.2 from 2019), (2) bundled APK binary in version control without verification mechanisms, and (3) lack of visible vulnerability disclosure policy. The codebase itself appears well-structured without obvious SQL injection or XSS risks typical of desktop applications. Recommendations include updating dependencies, moving binaries to artifact repositories, implementing comprehensive CI/CD security scanning, and establishing a security reporting process. No hardcoded credentials or critical misconfigurations were identified in the visible file structure.

• Medium · Outdated Dependency: dmgbuild — Dependencies/Package file (dmgbuild==1.4.2). The dependency file specifies dmgbuild==1.4.2, which is pinned to a specific old version. This version was released in 2019 and may contain known vulnerabilities. Modern versions should be used to ensure security patches are applied. Fix: Update dmgbuild to the latest stable version. Remove the exact version pin and use a version constraint like 'dmgbuild>=1.6.0' or implement dependency scanning in CI/CD pipeline.
• Medium · Bundled APK File Without Verification — QtScrcpy/sndcpy/sndcpy.apk. The repository includes a pre-compiled APK file (QtScrcpy/sndcpy/sndcpy.apk) which is checked into version control. This binary file cannot be easily audited for security issues and poses a supply chain risk if compromised. Fix: Move binary artifacts out of version control. Consider hosting APK files on a separate artifact repository with integrity verification (SHA256 checksums). Document the APK build process and make source code available for auditing.
• Low · Missing Security Headers in GitHub Workflows — .github/workflows/. GitHub Actions workflows are present but cannot be fully analyzed from the file structure provided. CI/CD pipelines should implement security best practices like signed commits, artifact verification, and dependency scanning. Fix: Implement GitHub Actions security best practices: use pinned action versions (with commit SHAs), enable branch protection rules, add SAST scanning (CodeQL), and implement artifact signing. Add dependency scanning for both C++ and Python dependencies.
• Low · No Visible Security Policy or Security.md — Repository root. No SECURITY.md or vulnerability disclosure policy is evident in the provided file structure. This makes it difficult for security researchers to responsibly report vulnerabilities. Fix: Create a SECURITY.md file with clear instructions for reporting security vulnerabilities. Include contact information and commitment to timely patching.
• Low · Potential ADB Command Injection Risk — QtScrcpy/ (entire codebase). The codebase controls Android devices via ADB/USB. While no explicit code analysis was performed, applications that execute system commands to interact with ADB are potential injection vectors if user input is not properly sanitized. Fix: Conduct a thorough code review of all command execution paths, especially in device control and interaction modules. Use parameterized commands and strict input validation. Avoid shell interpretation by using direct process execution with argument arrays.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.