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/cinit/QAuxiliary 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.

WAIT — Mixed signals — read the receipts

• Last commit today
• 10 active contributors
• Distributed ownership (top contributor 35% of recent commits)
• Other licensed
• CI configured
• ⚠ Non-standard license (Other) — review terms
• ⚠ No test directory detected

_{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 cinit/QAuxiliary repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/cinit/QAuxiliary.

What it runs against: a local clone of cinit/QAuxiliary — 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 cinit/QAuxiliary | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of cinit/QAuxiliary. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/cinit/QAuxiliary.git
#   cd QAuxiliary
#
# 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 cinit/QAuxiliary and re-run."
  exit 2
fi

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

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

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main 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 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
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/cinit/QAuxiliary"
  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).

QAuxiliary is an open-source Xposed module that extends QQ and TIM messaging clients with additional features and customizations. It runs as a runtime hook via Xposed Framework (or Frida for non-Xposed systems) to inject functionality into QQ ≥8.2.0, TIM ≥2.2.0, and other variants, enabling features like message filtering, UI customization, and protocol-level tweaks without modifying the original APK. Monolithic Android app module under app/ with Gradle build (app/build.gradle.kts) and icon resources (app/icons/* with themed variants: classic, QAPro, ChineseNewYear). Mixed Java/Kotlin codebase with native C/C++ components (likely for hooking internals). AIDL present for IPC. GitHub workflows handle CI automation including commit message validation (check_commit_message.yml) and PR-triggered builds (pr_ci.yml).

Android power users and QQ/TIM enthusiasts who want extended functionality in Tencent messaging apps, plus reverse engineers and Android developers interested in runtime hooking patterns. Contributors are primarily Chinese-speaking developers familiar with Xposed modularization and native Android interception.

Actively developed with rolling CI/CD releases (distinguishing between 'CI' and 'Recommended CI' versions), comprehensive GitHub Actions workflows (pr_ci.yml, push_ci.yml), and documented release channels (Telegram + GitHub). The codebase is substantial (2.4M LOC Java, 2.1M Kotlin, 1.2M C), but carries inherent risk due to its hooking nature and potential for breakage across QQ version updates. Production-ready for experienced users; requires caution around app compatibility.

High risk: directly hooks into closed-source QQ/TIM binaries, making it fragile across version updates (no version pinning visible). Single primary maintainer (@qwq233) creates bus factor risk. No visible test suite in file structure. The CC BY-NC-SA 4.0 + EULA license restricts commercial use and includes disclaimer that devs may 'stop updates or delete the project' at any time. Feature removal possible if features are widely abused.

Active rolling releases with auto-generated CI versions on every commit. Workflow system auto-closes stale issues (auto_close_issues.yml) and validates commit messages. PR template and issue templates (bug_report.yml, feature_request.yml, dev_feedback.yml) indicate structured contribution process. Code style enforced via editorconfig and IDEA inspection profiles.

Check README for instructions.

Daily commands: Requires Xposed Framework active on a rooted Android device (API 24+). After installing the APK, activate the module in Xposed Manager, reboot, then launch QQ/TIM and navigate to settings → QAuxiliary to configure features. Alternative: use Frida loader for non-Xposed systems (see docs/instruction-qauxv-frida.md).

• app/build.gradle.kts: Gradle configuration defining dependencies, build flavors (CI vs Recommended CI), compileSdk/targetSdk versions, and APK output naming.
• .github/workflows/pr_ci.yml: Automated PR validation: runs builds, code style checks, commit message validation before merge.
• .github/CONTRIBUTING.md: Developer guidelines and contribution rules specific to the non-commercial, open-source nature of the project.
• [LICENSE.md + PRIVACY_LICENSE.md](https://github.com/cinit/QAuxiliary/blob/main/LICENSE.md + PRIVACY_LICENSE.md): CC BY-NC-SA 4.0 EULA defining usage rights, restrictions on commercial use, and team's right to discontinue project.
• .idea/inspectionProfiles/Project_Default.xml: IDE code style and inspection rules enforced across contributors; enforces consistency.

New feature hooks belong in the main Kotlin/Java module under app/src/main/. Icon variants go in app/icons/[theme_name]/ic_qauxiliary_[variant]/. UI strings in resource files (res/values/). CI/CD changes in .github/workflows/. Settings UI likely in app/src/main/java/*/ui/ (not visible in file list but typical Android structure). Rebuild with ./gradlew assembleDebug after changes.

1. Xposed version lock: Module activation depends on active Xposed Framework; no graceful fallback if framework is uninstalled post-activation. 2. QQ version fragility: Method signatures and binary layouts in QQ change frequently; no version matrix visible—hookingmay break silently on untested QQ versions. 3. No local test env: Requires a rooted Android device; cannot unit-test hooking logic on JVM. 4. AIDL versioning: IPC contract between hook layer and settings UI may drift; no API versioning strategy visible. 5. CMake/native deps: C/C++ compilation requires NDK; build may fail silently if NDK is misconfigured (no explicit NDK version in visible files).

• Xposed Framework Method Hooking — QAuxiliary's entire architecture depends on intercepting Java method calls at runtime via Xposed; understanding XposedBridge.hookMethod() and how it replaces method implementations is critical to adding new features.
• Android Runtime (ART) vs Dalvik Bytecode Interception — Method hooking works differently on modern ART (Android 5.0+) vs older Dalvik; QAuxiliary targets Android 7.0+ so must understand ART's compiled-code execution model.
• Binary Protocol Reverse Engineering (QQ/TIM) — Many advanced features likely involve parsing or modifying QQ's proprietary protocol messages; contributors must understand how to identify and hook protocol-level methods in the QQ binary.
• Android AIDL (Android Interface Definition Language) — AIDL files present in repo (app/src/main/aidl) indicate IPC communication between the Xposed hook layer and the settings UI; understanding AIDL binding is needed for cross-process feature configuration.
• Frida Instrumentation & Gadgets — Alternative hooking mechanism for systems without Xposed (mentioned in docs/instruction-qauxv-frida.md); relevant for understanding how QAuxiliary adapts to different runtime environments.
• Android Content Provider & SharedPreferences for Feature Flags — Settings page (mentioned in README) likely stores user preferences via SharedPreferences or a ContentProvider; hooking code must read flags to conditionally enable features.
• Native Code Integration (JNI/NDK) — 1.2M LOC of C/C++ present in repo; likely contains low-level hooking internals or performance-critical protocol parsing that cannot be done in Java/Kotlin.

• Xposed-M/XposedFramework — Core runtime environment that QAuxiliary hooks into; understanding Xposed API and lifecycle is essential.
• cinit/QNotified — Direct predecessor to QAuxiliary; same codebase fork with focus on stability; reference for architectural patterns.
• LSPosed/LSPosed — Modern successor to Xposed Framework with improved compatibility; QAuxiliary explicitly tested against LSPosed (mentioned in README badges).
• RikkaApps/Riru — Alternative hooking framework for Android; relevant if understanding non-Xposed hooking approaches like Frida integration.
• frida/frida — Dynamic instrumentation toolkit referenced in docs as alternative to Xposed for non-rooted/Xposed-less systems.

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 GitHub Actions workflow for APK build verification and size tracking

The repo has pr_ci.yml and push_ci.yml workflows, but there's no dedicated workflow to verify APK builds succeed and track binary size changes across PRs. This is critical for a mobile app repo to catch build regressions early and monitor app size growth. Currently contributors may not know if their changes break the build until manual testing.

• [ ] Create .github/workflows/apk_build_check.yml that runs on PRs to compile all build variants
• [ ] Add build artifact size comparison against main branch (using app/build.gradle.kts)
• [ ] Post APK size metrics as PR comments to inform contributors of size impact
• [ ] Reference the workflow in CONTRIBUTING.md to document the automated checks

Create icon asset optimization and validation workflow

The repo contains 13+ icon themes across app/icons/ (ChineseNewYearIcon, QAPro, classic variants, etc.), each with multiple XML files. There's no automated validation that all icon sets are complete, properly formatted, or optimized. This leads to inconsistent icon resources and potential runtime errors on specific themes.

• [ ] Create .github/workflows/validate_icons.yml to run on PRs modifying app/icons/
• [ ] Add a Kotlin/Java validation script that checks all icon directories contain required files (icon.xml, icon_qa_background.xml, icon_qa_foreground.xml)
• [ ] Verify XML syntax and identify unused or duplicate icon definitions
• [ ] Document icon contribution guidelines in .github/CONTRIBUTING.md with the validation rules

Add ISSUE_TEMPLATE configuration for device/QQ version compatibility reports

The repo targets multiple QQ/TIM versions (8.2.0+) and Android versions (7.0+) across different devices, but the bug_report.yml template doesn't systematically capture this metadata. This makes triaging version-specific issues harder. A dedicated template would improve bug quality and help maintainers identify version-specific regressions quickly.

• [ ] Extend .github/ISSUE_TEMPLATE/bug_report.yml to add required fields for QQ version, TIM version, QQ Lite version, Android version, and device model
• [ ] Create a new .github/ISSUE_TEMPLATE/compatibility_issue.yml for QQ/TIM version-specific issues with dropdowns for known affected versions
• [ ] Update .github/ISSUE_TEMPLATE/config.yml to reference the new template
• [ ] Document the expected format in CONTRIBUTING.md to help users provide accurate environment details

• Add icon theme for Android 14+ Material You dynamic colors: create new variant in app/icons/material_you/ following the structure of app/icons/classic/ and update build.gradle.kts to register it.
• Write missing documentation for Frida loader setup: expand docs/instruction-qauxv-frida.md with step-by-step commands, common errors, and device permission fixes (currently referenced but likely sparse).
• Implement automated compatibility matrix tests: create a CI job in .github/workflows/ that reports which QQ versions (8.2.x, 8.3.x, 8.4.x) the latest build was tested against, to reduce user confusion.

• High · Xposed Module with Elevated Privileges — app/build.gradle.kts, entire codebase. QAuxiliary is an Xposed module that hooks into system processes and the QQ/TIM applications. Xposed modules operate at a privileged level with access to internal APIs and can intercept system calls. This creates a significant attack surface if the module code contains vulnerabilities or is compromised. Fix: Implement strict code review processes, use static analysis tools (lint, FindBugs), add comprehensive input validation, and maintain regular security audits. Consider using code signing and integrity verification.
• High · Hook-Based Modification of Third-Party Applications — app/src (hooks implementation). The module hooks into QQ/TIM applications and modifies their behavior at runtime. This can be exploited to intercept sensitive data (messages, tokens, user information) or perform unauthorized actions. The hooking mechanism bypasses normal security boundaries. Fix: Implement secure data handling practices when intercepting application data. Use encryption for sensitive data in transit and at rest. Implement access controls to restrict what data hooks can access. Add logging for security-sensitive operations.
• High · Frida Integration Without Runtime Verification — docs/instruction-qauxv-frida.md, app implementation. The documentation mentions support for Frida-based loading on non-Xposed systems. Frida requires root access and can be used to inject arbitrary code. There's no apparent mechanism to verify the integrity or origin of Frida payloads before execution. Fix: If Frida is supported, implement cryptographic verification of payload signatures. Use certificate pinning and secure boot mechanisms. Require explicit user confirmation before executing Frida payloads. Document security risks clearly.
• Medium · Dependency Management Visibility — app/build.gradle.kts. No dependency file (build.gradle.kts content, package.json, requirements.txt, etc.) was provided for analysis. This prevents evaluation of known vulnerabilities in third-party libraries and transitive dependencies. Fix: Provide and regularly update dependency information. Use dependency scanning tools (OWASP Dependency-Check, Snyk) in the CI/CD pipeline. Pin versions and audit for known vulnerabilities regularly. Review the ProGuard rules file (app/proguard-rules.pro) for proper obfuscation.
• Medium · Debug Build Configuration — app/src/debug/java/hook/DebugDump.kt. Presence of debug source files (app/src/debug/java/hook/DebugDump.kt) suggests debugging capabilities that may be included in release builds, potentially exposing sensitive information or creating attack vectors. Fix: Ensure debug builds are completely stripped from release APKs. Use BuildConfig.DEBUG guards for debug code. Implement proper build flavors to separate debug and release builds. Verify ProGuard configuration removes debug information from production builds.
• Medium · Missing Security Policy Documentation — Repository root (missing SECURITY.md). No SECURITY.md file is present for responsible vulnerability disclosure. The LICENSE.md and PRIVACY_LICENSE.md files suggest terms, but no clear security policy or vulnerability reporting process is documented. Fix: Create a SECURITY.md file with clear vulnerability reporting guidelines, contact information, and expected response times. Consider establishing a bug bounty program. Define security update policies.
• Medium · Inadequate Input Validation in Hook Context — app/src (hook implementations). As a hooking framework, the module intercepts data from QQ/TIM. Without explicit validation, intercepted data could be malformed, oversized, or malicious, leading to buffer overflows, DoS, or injection attacks. Fix: Implement comprehensive input validation for all intercepted data. Use allowlists where possible. Implement size limits and sanitization. Add try-catch blocks around parsing operations. Fuzz test the hooking implementations.
• Low · Publicly Disclosed Source Code with Security-Sensitive Features — GitHub repository (public). While open source itself isn't a vulnerability, the public disclosure of a privileged hooking module with integration with messaging applications allows attackers to analyze the code and develop exploits or malicious modifications. Fix: Implement code obfuscation (already attempted with ProGuard). Add runtime integrity checks. Implement anti-

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.