WAIT — Single-maintainer risk — review before adopting

• Last commit 6d ago
• 9 active contributors
• GPL-3.0 licensed
• CI configured
• ⚠ Single-maintainer risk — top contributor 85% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No test directory detected
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Vector is a Zygisk-based ART hooking framework that provides runtime method interception for Android 8.1–17, maintaining API compatibility with the original Xposed framework. Built on LSPlant, it enables non-destructive in-memory modification of system and app behavior without touching APK files, making changes reversible via reboot and compatible across ROM variants. Monorepo structure: app/src/main/java/org/lsposed/manager/ contains the manager UI (Material Design with custom SubtitleCollapsingToolbarLayout), app/src/main/java/org/lsposed/manager/repo/ handles module repository logic, and native instrumentation code lives in C++/AIDL layers. Web assets (app/src/main/assets/webview/) support markdown rendering with theme-aware CSS (dark/light modes).

Android developers and power users who create Xposed modules to modify system/app behavior; ROM developers integrating hook infrastructure; security researchers performing runtime analysis. Contributors include framework maintainers extending ART instrumentation and Zygisk module creators.

Production-ready with active development. The repo shows organized CI/CD (GitHub Actions workflows in .github/workflows/core.yml), semantic versioning with stable + canary release channels, Crowdin localization integration, and multi-language codebase (767KB Java, 279KB Kotlin, 236KB C++). Last activity appears current based on release cadence and documented Android 17 Beta support.

Single-maintainer risk (JingMatrix) with heavy reliance on LSPlant submodule; Magisk/KernelSU + Zygisk ecosystem stability is external dependency. The framework operates at ART runtime level (C++/native code) where bugs cause crashes or bootloops—testing coverage not visible in file list. No open issue backlog visibility in provided data.

Active localization via Crowdin badge; CI builds passing on master branch; stable releases published to GitHub with download metrics tracked. Manager app is feature-complete (module scope management via ScopeAdapter.java, app filtering via AppHelper.java). No visible PR data provided, but framework maintains compatibility through recent Android versions (17 Beta mentioned).

git clone --recursive https://github.com/JingMatrix/Vector.git
cd Vector
# For build, requires Android SDK + Gradle (Kotlin DSL detected from .gradle.kts files)
./gradlew assemble  # or gradlew.bat on Windows

Install as Magisk/KernelSU module post-build; requires Zygisk-enabled environment.

Daily commands: Development iteration: ./gradlew assembleDebug outputs APK; install via adb install-multiple or Magisk. Manager UI requires device with Vector framework already flashed. No dev server—APK must be installed on target device. For module development, use published Xposed API from org.lsposed.manager package.

• app/src/main/java/org/lsposed/manager/App.java — Application entry point and core initialization logic for the Vector framework manager
• app/src/main/java/org/lsposed/manager/ConfigManager.java — Central configuration management system that handles framework state, module interactions, and service communication
• app/src/main/java/org/lsposed/manager/util/ModuleUtil.java — Module loading, scanning, and lifecycle management utilities essential for framework operations
• app/src/main/java/org/lsposed/manager/ui/activity/MainActivity.java — Main UI entry point that orchestrates navigation and manages the overall application view hierarchy
• app/src/main/java/org/lsposed/manager/repo/RepoLoader.java — Module repository loading and caching system critical for discovering and distributing modules
• app/build.gradle.kts — Build configuration defining dependencies, version management, and compilation targets for the framework

Add a new Module Management Fragment

1. Create a new fragment class extending BaseFragment in app/src/main/java/org/lsposed/manager/ui/fragment/ (app/src/main/java/org/lsposed/manager/ui/fragment/YourNewFragment.java)
2. Register the fragment route in MainActivity's navigation setup by adding to the navigation controller (app/src/main/java/org/lsposed/manager/ui/activity/MainActivity.java)
3. Create corresponding layout XML in app/src/main/res/layout/fragment_your_feature.xml (app/src/main/res/layout/fragment_your_feature.xml)
4. Add navigation menu item by creating drawable icon in app/src/main/res/drawable/ic_your_feature.xml (app/src/main/res/drawable/ic_your_feature.xml)

Add Module Metadata Model

1. Create POJO class in app/src/main/java/org/lsposed/manager/repo/model/ with @SerializedName annotations (app/src/main/java/org/lsposed/manager/repo/model/YourModel.java)
2. Update RepoLoader to parse your model from JSON response (app/src/main/java/org/lsposed/manager/repo/RepoLoader.java)
3. Create adapter class in app/src/main/java/org/lsposed/manager/adapters/ to bind model to UI (app/src/main/java/org/lsposed/manager/adapters/YourAdapter.java)

Add New Configuration Setting

1. Add constant key to ConfigManager in app/src/main/java/org/lsposed/manager/ConfigManager.java (app/src/main/java/org/lsposed/manager/ConfigManager.java)
2. Add preference UI in SettingsFragment by creating new PreferenceCategory (app/src/main/java/org/lsposed/manager/ui/fragment/SettingsFragment.java)
3. Handle setting changes by overriding onPreferenceChange in SettingsFragment (app/src/main/java/org/lsposed/manager/ui/fragment/SettingsFragment.java)

• Kotlin DSL (Gradle) — Type-safe build configuration with IDE support and better dependency management for Android builds
• Material Design Components — Provides modern, consistent UI with Material 3 support; custom CollapsingToolbar extensions for advanced layouts
• RecyclerView with StateParcel — Efficient list rendering with state persistence for smooth navigation and configuration changes
• JSON serialization (Gson implied) — Handles module metadata and repository JSON without external parsing overhead

• Centralized ConfigManager vs distributed state management

  • Why: Simplifies IPC with native framework service and ensures single source of truth for module state
  • Consequence: ConfigManager becomes a bottleneck; all state queries serialize through it but ensures consistency

• Repository caching in RepoLoader vs always-fresh

  • Why: Reduces network latency and bandwidth for module discovery; critical for poor connectivity
  • Consequence: Risk of stale module data; cache invalidation strategy needed to prevent outdated versions

• Module compilation in app vs separate service

  • Why: Keeps compilation feedback UI-responsive and allows progress monitoring in real-time
  • Consequence: CPU/memory spikes on device during compilation; no background compilation capability

• Custom widget implementations (LinkifyTextView, ExpandableTextView) vs library

  • Why: Fine-grained control over rendering, styling, and framework integration without external dependencies
  • Consequence: Higher maintenance burden; potential bugs in custom rendering logic

• Real-time module execution monitoring (no runtime profiler/tracer built-in)
• Cross-device module synchronization (single-device only)
• Non-Android platform support (Android-only framework)
• Backward compatibility with pre-ART runtimes (ART-only)

Critical: Requires Zygisk-enabled Magisk/KernelSU—framework will not load without it; bootloop risk if Zygisk absent. Native code: C++ instrumentation bugs crash system_server or zygote; test on emulator first. Submodule: .gitmodules references LSPlant; recursive clone essential—bare clone causes build failure. ProGuard: app/proguard-rules.pro must preserve reflection-heavy Xposed API surface; obfuscation breaks module compatibility. AIDL versioning: IPC contracts in *.aidl are strict; changing signatures breaks existing modules.

• Zygisk Module — Vector is packaged as a Zygisk module to inject hooks at process startup; understanding Zygisk hooking points is essential for extending the framework
• ART Runtime Instrumentation — Vector hooks Android Runtime methods at the interpreter/JIT level; knowing ART class loading and method resolution is critical for debugging instrumentation
• AIDL (Android Interface Definition Language) — Manager app communicates with native framework daemon via AIDL binders; changes to IPC contracts require careful versioning
• Method Hooking / Aspect-Oriented Programming — Vector's core feature is runtime method interception before/after execution; Xposed modules leverage XposedBridge.hookMethod() for this
• ProGuard / Code Obfuscation — Vector's public Xposed API surface must not be obfuscated (see proguard-rules.pro) or modules will fail to resolve hooks via reflection
• Material Design 3 Components — Manager UI uses Material 3 theming and custom components (SubtitleCollapsingToolbarLayout); understanding Material specs is needed for UI contributions
• Module Repository Metadata Format — RepoLoader parses online module manifests (JSON); contributors must understand the Release, ReleaseAsset, Collaborator model for repo integration

• JingMatrix/LSPlant — Core native hooking engine that Vector depends on; contains ART instrumentation C++ code
• topjohnwu/Magisk — Root manager and Zygisk host environment required to run Vector modules; Vector is a Zygisk module
• rovo89/Xposed — Original Xposed framework; Vector maintains API compatibility with this predecessor for module portability
• JingMatrix/NeoZygisk — Enhanced Zygisk implementation recommended in README for stable Vector execution
• lsposed/LSPosed — Alternative modern Xposed implementation; shares similar architecture goals but different implementation approach

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 instrumentation tests for UI fragments and activities

The repo has multiple UI components (MainActivity, HomeFragment, ModulesFragment, RepoFragment, etc.) but no visible test files in the file structure. Adding instrumentation tests would ensure UI stability across Android versions, particularly important for a framework that hooks into ART. This is critical for a Zygisk module that modifies system behavior.

• [ ] Create app/src/androidTest/java/org/lsposed/manager/ui/activity/MainActivityTest.java to test MainActivity lifecycle and fragment transactions
• [ ] Create app/src/androidTest/java/org/lsposed/manager/ui/fragment/ModulesFragmentTest.java to test module list loading and filtering
• [ ] Create app/src/androidTest/java/org/lsposed/manager/ui/fragment/RepoFragmentTest.java to test RepoLoader integration and RecyclerViewDialogFragment rendering
• [ ] Add AndroidX test dependencies (androidx.test.espresso, androidx.test.runner) to app/build.gradle.kts
• [ ] Create app/src/androidTest/resources/AndroidManifest.xml if needed for test configuration

Add unit tests for ConfigManager and RepoLoader data handling

ConfigManager.java and RepoLoader.java handle critical configuration and module repository operations. The absence of unit tests for data parsing (OnlineModule, Release, ReleaseAsset models) creates risk for regressions in module discovery/loading—core functionality for the framework.

• [ ] Create app/src/test/java/org/lsposed/manager/ConfigManagerTest.java to test configuration read/write operations
• [ ] Create app/src/test/java/org/lsposed/manager/repo/RepoLoaderTest.java to test repository JSON parsing and error handling
• [ ] Create app/src/test/java/org/lsposed/manager/repo/model/OnlineModuleTest.java to validate serialization of module metadata
• [ ] Create app/src/test/resources/mock_repo.json with sample repository data for test fixtures
• [ ] Add JUnit4 and Mockito dependencies to app/build.gradle.kts

Create missing AndroidManifest permissions documentation and validate framework permissions

A Zygisk module requires specific Android permissions and manifest declarations. While app/src/main/AndroidManifest.xml exists, there's no documented validation that all necessary framework permissions (SELinux, system_server hooks) are properly declared. Add documentation and validation to prevent installation failures on different Android versions.

• [ ] Create docs/PERMISSIONS.md documenting required Android permissions and why each is needed (INJECT_EVENTS, WRITE_SECURE_SETTINGS, etc.)
• [ ] Create app/src/test/java/org/lsposed/manager/ManifestValidationTest.java to parse and validate AndroidManifest.xml permissions at build time
• [ ] Update app/build.gradle.kts to run manifest validation as a pre-build task
• [ ] Document Zygisk-specific requirements (selinux policies, module loading permissions) in docs/INSTALLATION.md
• [ ] Add a GitHub workflow step in .github/workflows/core.yml to validate manifest during CI

• Add unit tests for RepoLoader.java parsing of OnlineModule JSON responses—currently no test files visible for repo package
• Implement missing dark mode CSS fallback in webview templates (template.html vs template_dark.html)—consolidate into theme-aware single template
• Extract hardcoded strings in AppHelper.java and ConfigManager.java to strings.xml for full Crowdin localization coverage

• High · Potential XSS Vulnerability in WebView Components — app/src/main/java/org/lsposed/manager/ui/widget/ScrollWebView.java, app/src/main/assets/webview/template.html, app/src/main/assets/webview/template_dark.html. The codebase includes custom WebView implementations (ScrollWebView.java) and HTML template files for rendering markdown content. Without proper input sanitization and Content Security Policy headers, there's a risk of Cross-Site Scripting (XSS) attacks when displaying user-generated or remote content. Fix: Implement strict input validation and sanitization for all content rendered in WebViews. Use a library like jsoup or OWASP HTML Sanitizer. Add Content Security Policy (CSP) headers to HTML templates. Set WebView settings securely (disable JavaScript if not needed, use HTTPS only).
• High · Insecure Network Communication for Module Repository — app/src/main/java/org/lsposed/manager/repo/RepoLoader.java, app/src/main/java/org/lsposed/manager/util/UpdateUtil.java, app/src/main/java/org/lsposed/manager/util/CloudflareDNS.java. The RepoLoader.java and UpdateUtil.java components fetch module metadata and updates from remote repositories. Without mandatory HTTPS enforcement and certificate pinning, the application is vulnerable to Man-in-the-Middle (MITM) attacks that could lead to installation of malicious modules. Fix: Enforce HTTPS-only connections for all remote repository communications. Implement certificate pinning for known repository hosts. Validate cryptographic signatures of downloaded modules before installation. Consider using a secure channel for DNS resolution (DoH/DoT).
• High · Unsafe DNS Resolution Implementation — app/src/main/java/org/lsposed/manager/util/CloudflareDNS.java. CloudflareDNS.java implements custom DNS resolution which could bypass system DNS settings and security controls. Custom DNS implementations without proper validation are vulnerable to DNS spoofing and cache poisoning attacks. Fix: Use standard Android DNS resolution APIs. If custom DNS is required, implement DNS-over-HTTPS (DoH) with certificate pinning. Validate all DNS responses cryptographically. Ensure the implementation follows RFC 8484 for DNS-over-HTTPS.
• Medium · Potential SQL Injection in Database Operations — app/src/main/java/org/lsposed/manager/util/ModuleUtil.java, app/src/main/java/org/lsposed/manager/ConfigManager.java. The ModuleUtil.java and ConfigManager.java files likely handle database operations for storing module configurations and application metadata. If raw SQL queries are constructed with user input without proper parameterization, SQL injection vulnerabilities could exist. Fix: Use parameterized queries (prepared statements) for all database operations. Never concatenate user input into SQL queries. Use SQLite's built-in query APIs with proper argument binding. Consider using an ORM framework like Room for type-safe database access.
• Medium · Missing Input Validation in AppListFragment — app/src/main/java/org/lsposed/manager/ui/fragment/AppListFragment.java, app/src/main/java/org/lsposed/manager/adapters/AppHelper.java. The AppListFragment.java and AppHelper.java process application metadata and user selections. Insufficient validation of package names and application data could lead to exploitation or information disclosure. Fix: Implement strict validation for all application identifiers (package names). Use allowlists for expected package name formats. Validate all user selections before processing. Sanitize displayed application metadata.
• Medium · Backup/Restore Functionality Security — app/src/main/java/org/lsposed/manager/util/BackupUtils.java. BackupUtils.java handles backup and restoration of module configurations. Without proper encryption and integrity verification, backup files could be tampered with to inject malicious configurations or gain unauthorized access. Fix: Encrypt all backup files using Android KeyStore. Implement HMAC-based integrity verification for backup files. Validate backup file format and contents before restoration. Request user confirmation before restoring backups with security-sensitive changes.
• Medium · Inadequate Service Security — undefined. LSPManagerServiceHolder.java manages critical service interactions Fix: undefined

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

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

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/JingMatrix/Vector 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.

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

What it runs against: a local clone of JingMatrix/Vector — 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 JingMatrix/Vector | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 36 days ago | Catches sudden abandonment since generation |

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

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

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

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

# 4. Critical files exist
test -f "app/src/main/java/org/lsposed/manager/App.java" \\
  && ok "app/src/main/java/org/lsposed/manager/App.java" \\
  || miss "missing critical file: app/src/main/java/org/lsposed/manager/App.java"
test -f "app/src/main/java/org/lsposed/manager/ConfigManager.java" \\
  && ok "app/src/main/java/org/lsposed/manager/ConfigManager.java" \\
  || miss "missing critical file: app/src/main/java/org/lsposed/manager/ConfigManager.java"
test -f "app/src/main/java/org/lsposed/manager/util/ModuleUtil.java" \\
  && ok "app/src/main/java/org/lsposed/manager/util/ModuleUtil.java" \\
  || miss "missing critical file: app/src/main/java/org/lsposed/manager/util/ModuleUtil.java"
test -f "app/src/main/java/org/lsposed/manager/ui/activity/MainActivity.java" \\
  && ok "app/src/main/java/org/lsposed/manager/ui/activity/MainActivity.java" \\
  || miss "missing critical file: app/src/main/java/org/lsposed/manager/ui/activity/MainActivity.java"
test -f "app/src/main/java/org/lsposed/manager/repo/RepoLoader.java" \\
  && ok "app/src/main/java/org/lsposed/manager/repo/RepoLoader.java" \\
  || miss "missing critical file: app/src/main/java/org/lsposed/manager/repo/RepoLoader.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 36 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~6d)"
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/JingMatrix/Vector"
  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).

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