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/DroidPluginTeam/DroidPlugin 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 — Stale — last commit 2y ago

• 20 active contributors
• LGPL-3.0 licensed
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 54% of recent commits
• ⚠ LGPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows 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 DroidPluginTeam/DroidPlugin repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/DroidPluginTeam/DroidPlugin.

What it runs against: a local clone of DroidPluginTeam/DroidPlugin — 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 DroidPluginTeam/DroidPlugin | Confirms the artifact applies here, not a fork | | 2 | License is still LGPL-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 ≤ 731 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(LGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"LGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is LGPL-3.0" \\
  || miss "license drift — was LGPL-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 "project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/PluginManagerService.java" \\
  && ok "project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/PluginManagerService.java" \\
  || miss "missing critical file: project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/PluginManagerService.java"
test -f "project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/HookFactory.java" \\
  && ok "project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/HookFactory.java" \\
  || miss "missing critical file: project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/HookFactory.java"
test -f "project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/core/PluginClassLoader.java" \\
  && ok "project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/core/PluginClassLoader.java" \\
  || miss "missing critical file: project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/core/PluginClassLoader.java"
test -f "project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/am/MyActivityManagerService.java" \\
  && ok "project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/am/MyActivityManagerService.java" \\
  || miss "missing critical file: project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/am/MyActivityManagerService.java"
test -f "project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/binder/ServiceManagerBinderHook.java" \\
  && ok "project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/binder/ServiceManagerBinderHook.java" \\
  || miss "missing critical file: project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/binder/ServiceManagerBinderHook.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 731 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~701d)"
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/DroidPluginTeam/DroidPlugin"
  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).

DroidPlugin is an Android plugin framework that enables host apps to run unmodified third-party APKs as plugins without installation or repackaging. It works by hooking Android's component resolution system (AMS/PMS) and using proxy activities/services to intercept lifecycle calls, allowing arbitrary APK code to execute in isolated plugin processes while maintaining complete resource and ClassLoader separation. Monolithic library structure: project/Libraries/DroidPlugin/src/main/ contains core Java code organized as com.morgoo.droidplugin.* with AIDL service definitions in aidl/ (IPluginManager, IApplicationCallback), C/C++ native code in sibling directories for lower-level hooks, and PluginApplication.java / PluginHelper.java as entry points for host app integration.

Android app developers and teams building collaborative/modular applications who need to dynamically load third-party APKs (e.g., feature modules, mini-apps, or white-label apps) without the overhead of app installation, source code access, or APK modification. Enterprise and ROM developers benefit from the low-level integration.

Actively maintained framework with production-grade features (compatible Android 2.3+), but showing signs of age — the documentation is in Chinese, last major activity appears concentrated around 2016-2017 era, and native code hooking gaps remain unresolved. Verdict: Production-ready core, but aging codebase with selective modern Android support.

High risk for Android 10+ due to scoped storage changes and stricter Binder/ClassLoader access; native code hooking is explicitly unsupported (noted in README problems), breaking many game and NDK-heavy apps. Single-author maintenance (Andy Zhang/cmzy) and lack of visible CI/test automation create sustainability concerns. Dependency on reflection and framework internals makes it fragile across Android versions.

Repository status unclear from file list alone — no recent commit metadata provided. Based on structure, active areas would be: Hook mechanism refinement (docs reference Hook机制之AMS&PMS.md), Activity/Service lifecycle management (docs cover all four components), and ClassLoader isolation (see ClassLoader管理.md). Problems section indicates ongoing gaps in Notification custom resources and native code support.

Clone the repo and integrate as a library: git clone https://github.com/DroidPluginTeam/DroidPlugin.git && cd project/Libraries/DroidPlugin && gradle build. Add to your host app's build.gradle: implementation project(':Libraries:DroidPlugin'). Modify AndroidManifest.xml to use android:name="com.morgoo.droidplugin.PluginApplication" or call PluginHelper.getInstance().applicationOnCreate() in your custom Application's onCreate().

Daily commands: This is a library, not a runnable app. Build via gradle build in project/Libraries/DroidPlugin/. To test integration: create a host app using the library (follow Usage section in README), then call PluginHelper.getInstance().installPlugin(pluginApkPath) and PluginHelper.getInstance().launchPlugin(). Example app structure would be in an example/ or demo/ folder (not listed in file structure provided).

• project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/PluginManagerService.java — Core plugin lifecycle and IPC management service; orchestrates plugin loading, process creation, and communication between host and plugins
• project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/HookFactory.java — Central factory for creating and managing all framework hooks; essential to understand how interception of Android system calls is orchestrated
• project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/core/PluginClassLoader.java — Custom ClassLoader implementation for loading plugin APK classes in isolation; critical for plugin resource and code isolation
• project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/am/MyActivityManagerService.java — Hooks into ActivityManager to intercept and redirect Activity lifecycle calls for plugin apps without manifest registration
• project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/binder/ServiceManagerBinderHook.java — Hooks ServiceManager to intercept system service access; enables plugins to access system services through modified Binder proxies
• project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/PluginApplication.java — Base Application class for host app integration; entry point for initializing the plugin framework and installing hooks
• project/Libraries/DroidPlugin/src/main/aidl/com/morgoo/droidplugin/pm/IPluginManager.aidl — AIDL interface defining plugin management IPC contract; defines methods for plugin installation, querying, and lifecycle control

Add Hook for a New System Service

1. Create a new Binder hook class extending BinderHook in hook/binder/ directory (e.g., IMyCustomServiceBinderHook.java) to intercept service manager calls (project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/binder/IAppOpsServiceBinderHook.java)
2. Create a corresponding hook handle class in hook/handle/ directory (e.g., IMyCustomServiceHookHandle.java) to implement the actual method interception logic (project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/handle/IAppOpsServiceHookHandle.java)
3. Register both the Binder hook and handle in HookFactory.java by adding entries to the hook creation methods (project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/HookFactory.java)
4. Implement the interception logic in the hook handle to redirect plugin calls to plugin-aware implementations or pass them through with permission checks (project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/handle/IActivityManagerHookHandle.java)

Add Support for a New Component Type (BroadcastReceiver, etc.)

1. Add pre-registered stub components in AndroidManifest.xml to occupy component slots without actual implementation (project/Libraries/DroidPlugin/src/main/AndroidManifest.xml)
2. Create a component mapper class (similar to ServiceStubMap.java) to dynamically assign plugin components to stubs at runtime (project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/am/ServiceStubMap.java)
3. Add interception logic in the appropriate ActivityManager hook handle to redirect component lifecycle calls to the mapped stubs (project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/am/MyActivityManagerService.java)
4. Add IPC interface definitions in aidl/ directory if new inter-process communication is needed for the component type (project/Libraries/DroidPlugin/src/main/aidl/com/morgoo/droidplugin/pm/IPluginManager.aidl)

Enable Host App to Load and Run a Plugin APK

1. Initialize DroidPlugin framework in host app's Application class by extending PluginApplication or calling PluginHelper initialization methods (project)

• Manifest authority collision: The AUTHORITY_NAME buildConfigField defaults to com.morgoo.droidplugin_stub but must be unique per host app integration or ContentProvider delegation fails silently — see config snippet's warning.
• Android version brittleness: Reflection-based hooking of framework internals (AMS/PMS) breaks across Android versions; APIs like PackageManager.getPackageInfo() have signature changes in Android 11+ not mentioned in docs.
• Process death recovery: Plugin processes are separately managed but no visible watchdog or automatic restart mechanism — crashed plugin processes may leak resources or leave stale state.
• Native code incompatibility: README explicitly lists lack of native layer hooks as a blocker — any plugin using NDK/JNI will fail, including most game engines (Unity, Unreal).
• Notification rendering trap: Custom RemoteViews and drawable resources in Notifications cannot be sent from plugins (known limitation #1 in README) — framework converts to Bitmaps, breaking animated/dynamic UI.
• No visible test suite: File list shows no tests/, androidTest/, or CI config (no .github/workflows/, Jenkinsfile, etc.) — integration quality unknown and regressions likely on version bumps.

• Binder Proxy Pattern — DroidPlugin uses AIDL to create Binder proxies between host and plugin processes (IPluginManager, IApplicationCallback); understanding how Binder RPC works is critical to grasping inter-process communication in this framework.
• Method Reflection & Hooking — The core mechanism: DroidPlugin uses Java reflection to replace system service methods (AMS, PMS internals) at runtime without modifying the framework; this is how plugins hijack component resolution.
• ClassLoader Hierarchy & Delegation — Each plugin gets a custom PathClassLoader that loads only its DEX while delegating framework classes to the parent loader; this enables complete resource/code isolation while maintaining system API access.
• Android Component Manifest Slots & Intent Resolution — DroidPlugin pre-registers stub/proxy activities in its own manifest and maps real plugin intents to these slots; understanding Android's intent filter matching (action/category/data) is essential to see how the mapping works.
• Process & Activity Lifecycle Management — DroidPlugin must track and delegate lifecycle callbacks (onCreate, onResume, etc.) from the system's proxy activities to actual plugin activities across process boundaries; this is why docs have a dedicated file on Activity lifecycle management.
• ResourcesManager & AssetManager Patching — To provide plugins with isolated Resources, DroidPlugin patches the ResourcesManager to create separate Resource instances per plugin; this prevents drawable/layout conflicts between host and plugin APKs.
• Package Manager Service (PMS) Internals — Plugins must be 'visible' to PackageManager queries (getPackageInfo, resolveIntent, etc.) even though they're not installed; DroidPlugin hooks PMS to intercept these calls and inject plugin package data.

• SandHook/SandHook — Modern Android hooking framework using inline hooks and Xposed-style replacements; more robust than DroidPlugin's reflection approach for bypassing newer Android versions.
• asLody/VirtualApp — Alternative plugin framework using virtual environment approach with custom Binder implementation; handles native code better and supports Android 10+ more reliably.
• tiann/Xposed — Foundational framework hooking system that inspired many Android plugin frameworks; understanding Xposed's hook strategy clarifies DroidPlugin's reflection-based approach.
• android/platform_frameworks_base — Android framework source code; necessary reference for understanding AMS/PMS internals that DroidPlugin hooks into via reflection.
• Tencent/Shadow — Tencent's modern plugin framework addressing DroidPlugin's limitations (native code support, Android 10+ compatibility); direct successor in the same problem domain with active maintenance.

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 Hook mechanism (BaseHookHandle.java and HookFactory.java)

The Hook mechanism is critical to DroidPlugin's functionality (as evidenced by extensive documentation in DOC/tianweishu/ covering Hook机制). However, there are no visible test files for core hooking classes. Adding comprehensive unit tests would catch regressions in Binder hooking, AMS hooking, and proxy hook implementations, which are complex and error-prone.

• [ ] Create project/Libraries/DroidPlugin/src/test/java/com/morgoo/droidplugin/hook/ directory
• [ ] Add unit tests for BaseHookHandle.java covering hook installation, method interception, and cleanup
• [ ] Add unit tests for HookFactory.java verifying correct hook instantiation for different Android versions
• [ ] Add integration tests for binder hooks (IAppOpsServiceBinderHook.java) with mock Binder objects
• [ ] Run tests against multiple SDK levels (minSdkVersion 9 and higher) to ensure compatibility

Add instrumented tests for Activity lifecycle management in plugin apps

Documentation exists (DOC/tianweishu/Activity生命周期管理.md) describing Activity lifecycle handling, but no test suite validates this critical functionality. Plugin Activities must integrate seamlessly with the host app's lifecycle—failures here cause crashes. Tests should verify pause/resume/destroy cycles for both stub and plugin Activities.

• [ ] Create project/Libraries/DroidPlugin/src/androidTest/ directory structure
• [ ] Implement tests in ActivityLifecycleTest.java using AndroidJUnit4 to verify stub Activity state transitions
• [ ] Add tests validating plugin Activity lifecycle callbacks match expected sequences
• [ ] Test edge cases: activity rotation, back button, app backgrounding while plugin Activity is running
• [ ] Verify RunningActivities.java correctly tracks plugin activities across the lifecycle

Create comprehensive documentation for ContentProvider and BroadcastReceiver plugin implementation with code examples

While DOC/tianweishu/BroadcastReceiver插件化.md and DOC/tianweishu/ContentProvider插件化.md exist, there's no corresponding detailed source-code walkthrough matching the level of detail in Activity/Service documentation. New contributors struggle to implement these components. Adding a detailed guide with code examples from the actual codebase would reduce contributor friction.

• [ ] Create DOC/implementation_guide_receiver.md explaining BroadcastReceiver hooking and stub registration patterns from source code
• [ ] Create DOC/implementation_guide_provider.md explaining ContentProvider authority mapping and query/insert/delete interception
• [ ] Include specific code references to PluginManagerService.java showing how receivers and providers are registered
• [ ] Add diagrams showing message flow for broadcast delivery and content provider queries
• [ ] Include troubleshooting section for common issues (permission denied, provider not found, broadcast not received)

• Add unit test coverage for ClassLoader isolation: Create tests in project/Libraries/DroidPlugin/src/test/ verifying that two plugins with conflicting dependency versions (e.g., different OkHttp versions) load correctly without cross-contamination. This directly addresses the 'Resource management are also completely separated' claim but has no visible test evidence.
• Document Android 10+ scoped storage and Binder SELinux changes: Write a compatibility guide expanding DOC/tianweishu/Hook机制之AMS&PMS.md with concrete examples of how the AMS/PMS hooking strategy breaks on modern Android and proposed workarounds. This addresses the aging codebase without code changes.
• Implement Intent Filter support for plugin components: Add a field to IPluginManager.aidl to register plugin activity/service intent filters and update PluginManagerService.java to resolve intent matches against registered filters. This addresses known limitation #2 in README (plugins currently invisible to external intents).

• High · Dynamic Code Execution via Plugin Loading — project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/core/PluginClassLoader.java, PluginProcessManager.java. DroidPlugin framework allows loading and execution of arbitrary third-party APKs without installation or verification. The PluginClassLoader and plugin loading mechanisms in the core module could execute malicious code. The framework's ability to dynamically register components (Activities, Services, BroadcastReceivers, ContentProviders) from untrusted sources creates a significant attack surface. Fix: Implement cryptographic signature verification for all loaded plugins. Use APK signature validation before loading. Implement a whitelist of allowed plugin packages. Consider sandboxing plugin execution with restricted permissions.
• High · Unprotected Binder Interface Exposure — project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/binder/. The IPluginManager.aidl and multiple BinderHook implementations expose system services through inter-process communication without proper permission validation. The extensive use of Binder hooking (IActivityManagerService, IPackageManagerService, etc.) bypasses Android's normal permission checks and security boundaries. Fix: Implement strict permission checks on all Binder interfaces using checkCallingPermission(). Restrict Binder access to only authorized processes. Use signature-based permission enforcement rather than relying on package names alone.
• High · Hook Mechanism Bypasses System Security — project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/hook/. The Hook framework (BaseHookHandle.java, HookFactory.java) systematically intercepts and modifies Android system behavior including AMS (Activity Manager Service) and PMS (Package Manager Service). This allows plugins to bypass standard Android security checks, access controls, and platform restrictions. Fix: Validate hook targets and limit hook scope. Implement audit logging for all hook invocations. Only hook methods that are absolutely necessary and validate all intercepted calls against security policies.
• Medium · Hardcoded Authority Name Configuration — project/Libraries/DroidPlugin/build.gradle (authorityName definition). The ContentProvider authority is hardcoded as 'com.morgoo.droidplugin_stub' in build.gradle. While comments suggest customization, this default creates a predictable target for inter-process communication attacks and potential authority hijacking if not properly configured. Fix: Make authority name mandatory and unique per implementation. Generate authority names dynamically or require configuration during initialization. Implement authority validation and collision detection.
• Medium · Missing Input Validation in Plugin Installation — project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/PluginManagerService.java. The PluginManagerService.java and package management components accept plugin APKs without documented validation of APK integrity, manifest content, or component declarations. No evidence of DEX verification or code analysis before loading. Fix: Implement comprehensive APK validation including: DEX file verification, manifest schema validation, component name validation, and potentially code static analysis. Reject suspicious or malformed APKs.
• Medium · Service Stub Process Isolation Issues — project/Libraries/DroidPlugin/src/main/java/com/morgoo/droidplugin/am/ServiceStubMap.java, StaticProcessList.java. The ServiceStubMap.java manages service process mapping but the 'stub' approach creates a single point where multiple plugins could potentially interact. The static process list (StaticProcessList.java) may not properly isolate untrusted plugins from each other. Fix: Implement true process isolation for untrusted plugins. Use separate processes with restricted capabilities for each plugin. Implement inter-process communication firewalls.
• Medium · Outdated Android SDK Target — project/Libraries/DroidPlugin/build.gradle (minSdkVersion 9). The minSdkVersion is set to 9 (Android 2.3), indicating the code targets very old Android versions. This suggests potential use of deprecated and insecure APIs. The codebase may contain security patches not applied to older API levels. Fix: Update minSdkVersion to at least 21 (Android 5.0) to leverage modern Android security

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.