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/singwhatiwanna/dynamic-load-apk 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

• 11 active contributors
• Other licensed
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 54% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ 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 singwhatiwanna/dynamic-load-apk repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/singwhatiwanna/dynamic-load-apk.

What it runs against: a local clone of singwhatiwanna/dynamic-load-apk — 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 singwhatiwanna/dynamic-load-apk | Confirms the artifact applies here, not a fork | | 2 | License is still Other | 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 ≤ 691 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "singwhatiwanna/dynamic-load-apk(\\.git)?\\b" \\
  && ok "origin remote is singwhatiwanna/dynamic-load-apk" \\
  || miss "origin remote is not singwhatiwanna/dynamic-load-apk (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginManager.java" \\
  && ok "DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginManager.java" \\
  || miss "missing critical file: DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginManager.java"
test -f "DynamicLoadApk/lib/src/com/ryg/dynamicload/DLProxyActivity.java" \\
  && ok "DynamicLoadApk/lib/src/com/ryg/dynamicload/DLProxyActivity.java" \\
  || miss "missing critical file: DynamicLoadApk/lib/src/com/ryg/dynamicload/DLProxyActivity.java"
test -f "DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLProxyImpl.java" \\
  && ok "DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLProxyImpl.java" \\
  || miss "missing critical file: DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLProxyImpl.java"
test -f "DynamicLoadApk/lib/src/com/ryg/dynamicload/DLBasePluginActivity.java" \\
  && ok "DynamicLoadApk/lib/src/com/ryg/dynamicload/DLBasePluginActivity.java" \\
  || miss "missing critical file: DynamicLoadApk/lib/src/com/ryg/dynamicload/DLBasePluginActivity.java"
test -f "DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginPackage.java" \\
  && ok "DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginPackage.java" \\
  || miss "missing critical file: DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginPackage.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 691 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~661d)"
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/singwhatiwanna/dynamic-load-apk"
  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).

DynamicLoadApk is an Android framework that enables loading and executing uninstalled APK files at runtime without requiring installation. It solves the core dynamic loading problem by implementing custom resource management (via AssetManager reflection) and Activity lifecycle proxying, allowing plugins to access R resources and run Activities/FragmentActivities seamlessly within a host application. Maven/Gradle dual structure: lib/ is the core framework JAR (com/ryg/dynamicload/) containing proxy components (DLProxyActivity, DLProxyService), plugin base classes (DLBasePluginActivity, DLBasePluginService), internal managers (DLPluginManager, DLPluginPackage), and utilities (DLUtils, SoLibManager). sample/ contains host/plugin example implementations. Monolithic structure with no modular separation between interface contracts and implementation.

Android developers building plugin architectures or modular applications who need to load feature APKs dynamically. Target users are both host app developers (integrating DL) and plugin developers (extending via DLBasePluginActivity/DLBasePluginService) who want to reduce APK size and support independent module testing.

Early-to-mid stage (appears to be from 2014-2015 era based on Gradle 1.0.0 and support-v4 library). No visible CI/CD setup, no test directory structure in the provided files, and minimal recent commit history visible. Framework is conceptually complete (supports Activities, Services, Resources, 3 interaction modes) but shows signs of age (legacy Eclipse project files, no modern dependency management).

High risk for production use: single maintainer (singwhatiwanna), relies on hidden/reflection APIs (AssetManager.addAssetPath) that may break on new Android versions, targets ancient Android baseline (2.x), and lacks automated tests. Framework predates Scoped Storage and modern security restrictions, making it incompatible with Android 11+. No documented migration path or active maintenance visible.

No active development visible in file timestamps. Framework appears dormant; mentions of experimental features (multiprocess support in 'lab' branch, native library support in 'dev' branch) suggest exploration stopped before completion. No recent commits, PRs, or issues noted in provided data.

git clone https://github.com/singwhatiwanna/dynamic-load-apk.git && cd DynamicLoadApk && ./gradlew clean build. Requires Android SDK configured via local.properties. Import via Android Studio using the guide at Android Studio.md.

Daily commands: Build library: ./gradlew buildLib. Build sample host APK: ./gradlew assembleDebug (in sample directory). Push to device: uploadDebug task (custom Gradle task that pushes APK to /sdcard/DynamicLoadHost/). No test suite present; validation is manual APK deployment.

• DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginManager.java — Core plugin manager that orchestrates dynamic APK loading, manages plugin lifecycle, and handles resource/intent routing—foundational to the entire framework
• DynamicLoadApk/lib/src/com/ryg/dynamicload/DLProxyActivity.java — Proxy activity that intercepts and delegates lifecycle calls to dynamically loaded plugin activities—essential for Activity support
• DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLProxyImpl.java — Internal proxy implementation handling Activity lifecycle delegation and resource resolution for loaded plugins
• DynamicLoadApk/lib/src/com/ryg/dynamicload/DLBasePluginActivity.java — Base class that all dynamically loaded plugin activities must extend—defines the contract for plugin development
• DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginPackage.java — Encapsulates loaded plugin metadata, ClassLoader, and resources—critical data structure for plugin management
• DynamicLoadApk/lib/src/com/ryg/utils/DLUtils.java — Utility methods for APK parsing, resource loading, and ClassLoader creation—infrastructure supporting dynamic loading
• DynamicLoadApk/lib/AndroidManifest.xml — Declares proxy components and required permissions for the host application to support dynamic plugin loading

Create a new plugin Activity

1. Create a new Activity class in your plugin APK that extends DLBasePluginActivity (DynamicLoadApk/lib/src/com/ryg/dynamicload/DLBasePluginActivity.java)
2. Implement onCreate() and other lifecycle methods as normal; DLProxyImpl will handle delegation ([your-plugin]/src/com/example/MyPluginActivity.java (create new))
3. In host app, call DLPluginManager.loadPlugin() to load the plugin APK (DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginManager.java)
4. Use DLIntent or regular Intent with DLProxyActivity to launch the plugin activity (DynamicLoadApk/lib/src/com/ryg/dynamicload/DLProxyActivity.java)

Add plugin-to-host communication interface

1. Define a custom interface in a common library shared by host and plugin (DynamicLoadApk/sample/depend_on_interface/doi-common/src/com/ryg/dynamicload/sample/docommon/HostInterface.java)
2. In host app, create a manager that implements and exposes this interface (DynamicLoadApk/sample/depend_on_interface/doi-common/src/com/ryg/dynamicload/sample/docommon/HostInterfaceManager.java)
3. In plugin, pass the interface instance to DLPlugin via attachToHost() mechanism (DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLAttachable.java)
4. Plugin activities can now call host methods directly through the interface ([your-plugin]/src/com/example/MyPluginActivity.java (reference))

Load and execute a plugin APK from the host

1. Copy the plugin APK to a writable directory (e.g., /sdcard/DynamicLoadHost/) (DynamicLoadApk/build.gradle (see upload task))
2. Call DLPluginManager.loadPlugin(apkPath) to load and parse the APK (DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginManager.java)
3. Construct a DLIntent or Intent targeting DLProxyActivity with plugin class name (DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLIntent.java)
4. Call startActivity() to launch the plugin activity (proxy handles delegation) (DynamicLoadApk/lib/src/com/ryg/dynamicload/DLProxyActivity.java)

Support native libraries (.so) in plugins

1. Place native libraries in plugin APK lib/ directory as usual ([your-plugin]/libs/armeabi/lib*.so (create new))
2. SoLibManager extracts and loads native libraries from the loaded plugin APK (DynamicLoadApk/lib/src/com/ryg/utils/SoLibManager.java)
3. DLPluginManager calls SoLibManager during plugin loading (DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginManager.java)
4. Plugin classes can call System.loadLibrary() normally; ClassLoader routes to extracted .so ([your-plugin]/src/com/example/NativeCode.java (reference))

Critical: AssetManager.addAssetPath() is a hidden API—breaks on Android 7.0+; reflection lookup may silently fail. Plugin APKs must be manually deployed to /sdcard/DynamicLoadHost/ (hardcoded path in build.gradle allprojects). Plugin Activities must extend DLBasePluginActivity or use DLProxyActivity for resource access—vanilla Activities will crash on R resource access. No version compatibility checks; framework assumes plugin was compiled against same Android SDK. No support for Android 8+ (no scoped storage awareness). ClassLoader isolation incomplete—shared native library loading via SoLibManager can cause conflicts.

• DexClassLoader and Plugin Class Loading — DL uses DexClassLoader(dex_path, cache_dir, lib_dir, parent_loader) to isolate plugin code—understanding parent ClassLoader delegation is key to debugging class not found errors
• AssetManager Resource Injection (Hidden API Reflection) — Core resource-loading technique using reflection on AssetManager.addAssetPath()—explains why R resources work in plugins and why it breaks on modern Android
• Activity Proxy Pattern / Intent Interception — DLProxyActivity/DLProxyFragmentActivity intercept lifecycle callbacks before delegating to plugin Activity—enables running uninstalled Activities without manifest registration
• Context Wrapping and mBase Substitution — Framework replaces Activity's internal ContextImpl (mBase field) to override getAssets/getResources—critical to understanding how resource contexts are swapped
• APK as ZIP and Asset Resolution — APKs are ZIP files; addAssetPath() loads resources by scanning APK structure—explains why resource IDs must match plugin APK's compiled resources
• Reflection-Based Method Invocation for Private APIs — DL relies on Method.invoke() to call hidden Android APIs—a fragile pattern that breaks across OS versions and requires catching NoSuchMethodException

• tiann/RePlugin — More modern (2015+) Android plugin framework with multiprocess support, stronger isolation, and active maintenance—direct evolution of DL concepts
• Tencent/VirtualAPK — Contemporary plugin framework (2016+) with better resource virtualization and manifest handling for complex plugins
• alibaba/atlas — Alibaba's modular app framework using similar proxy patterns but with more sophisticated ClassLoader delegation and hot-patching

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 DLPluginManager.java core functionality

The DLPluginManager.java (lib/src/com/ryg/dynamicload/internal/) is the core orchestration component for plugin loading, but there are no visible test files in the repository. Adding unit tests would validate plugin loading lifecycle, resource resolution, and proxy delegation mechanisms. This is critical for a dynamic loading framework where correctness directly impacts app stability.

• [ ] Create DynamicLoadApk/lib/src/test/java/com/ryg/dynamicload/internal/ directory
• [ ] Write DLPluginManagerTest.java testing: plugin load/unload, resource access via R, intent delegation to proxies
• [ ] Write DLProxyImplTest.java testing activity lifecycle delegation (onCreate, onDestroy, etc)
• [ ] Add test gradle configuration to lib/build.gradle for unit test execution

Create GitHub Actions CI workflow for Gradle builds and APK validation

The project has no .github/workflows/ directory for CI/CD. Given this is a library framework with multiple modules (lib, sample plugins, doi-common), automated builds would catch regressions across Android API levels. The gradle.properties and build.gradle files show the project is ready for CI but currently relies on manual testing.

• [ ] Create .github/workflows/android-build.yml workflow file
• [ ] Configure matrix build for multiple API levels (21, 28, 29+) using Android emulator or gradle tasks
• [ ] Add steps to: run ./gradlew build, validate APK generation in build/outputs/apk/, run any test suites
• [ ] Document in README.md how to run builds locally (e.g., ./gradlew buildLib)

Document plugin development API and lifecycle in DLBasePluginActivity.java/DLBasePluginService.java with JavaDoc and example usage guide

The framework provides base classes (DLBasePluginActivity, DLBasePluginFragmentActivity, DLBasePluginService) but they lack comprehensive JavaDoc and there's no dedicated plugin development guide. The README mentions 3 modes of host-plugin interaction but doesn't explain which base class to extend or how lifecycle methods are intercepted. This blocks new contributors from writing plugins correctly.

• [ ] Add detailed JavaDoc to DLBasePluginActivity.java explaining: attachment process, resource access via getResources(), lifecycle interception
• [ ] Add JavaDoc to DLBasePluginService.java explaining service-specific lifecycle and IPC patterns (reference DLServicePlugin.java)
• [ ] Create DynamicLoadApk/PLUGIN_DEVELOPMENT.md with: step-by-step plugin creation example, how to use R resources, how to call back to host via 3 modes, debugging tips
• [ ] Reference this guide in README.md under a new 'Plugin Developer Guide' section

• Add unit tests for DLPluginManager.loadPlugin() covering APK parsing, ClassLoader creation, and error cases (currently no test/ directory exists)
• Document the 3 plugin interaction modes (no-call, partial-call, full-call) with concrete code examples in each sample submodule and add mode validation to DLIntent
• Add Android 7.0+ compatibility shim: detect hidden API availability and fall back to alternative resource loading (e.g., manual AssetManager.open() for raw resource files)

This dynamic APK loading

• High · Outdated Gradle Build Tool — DynamicLoadApk/build.gradle. The project uses gradle 1.0.0 (classpath 'com.android.tools.build:gradle:1.0.0'), which is extremely outdated and contains numerous known security vulnerabilities. This version was released in 2014 and no longer receives security updates. Fix: Update to the latest stable version of Android Gradle Plugin (currently 8.x). This requires updating the gradle wrapper and build configuration accordingly.
• High · Dynamic APK Loading Without Verification — DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginManager.java. The framework dynamically loads APK files without apparent signature verification or integrity checking. The dynamic loading mechanism could be exploited to load malicious APKs if an attacker can write to the /sdcard/DynamicLoadHost directory or intercept the loading process. Fix: Implement APK signature verification, checksum validation, and ensure secure storage of plugin APKs with restricted file permissions. Validate plugin authenticity before loading.
• High · Hardcoded Storage Path with Insufficient Permissions — DynamicLoadApk/build.gradle (dlPath variable). The project uses a hardcoded path '/sdcard/DynamicLoadHost' for storing and loading APKs. The /sdcard directory is world-readable/writable on many Android devices, allowing any application to potentially modify or replace loaded plugins. Fix: Use Android's private app storage directories (getFilesDir(), getCacheDir(), or getExternalFilesDir()) instead of public /sdcard. These directories have proper permission controls that prevent unauthorized access.
• Medium · Unsafe Reflection Usage in Dynamic Loading — DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/. The README mentions 'basic no reflection calls' but the dynamic loading framework still relies on reflection to instantiate classes from loaded APKs. This could allow reflective gadget chain attacks if untrusted APKs are loaded. Fix: Implement a whitelist of allowed classes and methods that can be accessed via reflection. Use restricted ClassLoader configurations to limit what can be loaded.
• Medium · ADB Push in Build Script Without Authentication — DynamicLoadApk/build.gradle (uploadDebug task). The build.gradle file contains an 'uploadDebug' task that pushes APKs via ADB without any authentication checks. This is intended for development but creates a security risk if build scripts are compromised. Fix: Restrict the uploadDebug task to development environments only. Do not use this mechanism for production builds. Add environment-based conditionals and documentation about the security implications.
• Medium · Missing Input Validation in Plugin Loading — DynamicLoadApk/lib/src/com/ryg/dynamicload/internal/DLPluginManager.java. The DLPluginManager and related classes likely lack comprehensive input validation when loading plugin APKs, particularly around file paths, manifest parsing, and component instantiation. Fix: Implement strict validation of plugin APK files, manifest entries, and all user-supplied paths. Use a safe path traversal prevention mechanism.
• Medium · Outdated Android Support Library — DynamicLoadApk/lib/libs/android-support-v4.jar and DynamicLoadApk/sample/depend_on_interface/doi-common/libs/android-support-v4.jar. The project uses android-support-v4.jar, which is an old version of the Android Support Library. Modern projects should use AndroidX libraries which receive more regular security updates. Fix: Migrate to AndroidX libraries. Remove the legacy support library JAR and update build.gradle dependencies to use androidx equivalents.
• Low · Missing Security Headers and Best Practices Documentation — README.md and documentation files. The project lacks documentation on security best practices for using the dynamic loading framework, such as plugin validation, secure communication, and permission handling. Fix: Add a security best practices guide covering plugin validation, signature verification, permission models, and secure communication patterns for plugin developers.

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.