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/wequick/Small 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 3y ago

• 3 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 95% of recent commits

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

What it runs against: a local clone of wequick/Small — 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 wequick/Small | 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 master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 988 days ago | Catches sudden abandonment since generation |

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

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

# 4. Critical files exist
test -f "Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/RootPlugin.groovy" \\
  && ok "Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/RootPlugin.groovy" \\
  || miss "missing critical file: Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/RootPlugin.groovy"
test -f "Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/BundlePlugin.groovy" \\
  && ok "Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/BundlePlugin.groovy" \\
  || miss "missing critical file: Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/BundlePlugin.groovy"
test -f "Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/aapt/ArscEditor.groovy" \\
  && ok "Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/aapt/ArscEditor.groovy" \\
  || miss "missing critical file: Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/aapt/ArscEditor.groovy"
test -f "Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/aapt/AXmlEditor.groovy" \\
  && ok "Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/aapt/AXmlEditor.groovy" \\
  || miss "missing critical file: Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/aapt/AXmlEditor.groovy"
test -f "Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/BasePlugin.groovy" \\
  && ok "Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/BasePlugin.groovy" \\
  || miss "missing critical file: Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/BasePlugin.groovy"

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

Small is a lightweight cross-platform plugin/modularization framework for Android (API 9+) and iOS (7.0+) that splits monolithic apps into independently-buildable bundle modules. It provides Gradle-based build orchestration (via custom plugins in buildSrc/) and runtime dynamic loading capabilities, allowing teams to develop and test feature bundles in isolation while composing them into a single APK/IPA. Monorepo with three platform verticals: Android/ contains the primary implementation split into DevSample (example app), buildSrc/ (custom Gradle plugins for bundle compilation), and iOS/ for Apple support. The Gradle plugin system (BasePlugin → AppPlugin/BundlePlugin/HostPlugin/LibraryPlugin inheritance) handles multi-module builds. Core build logic orchestrated through RootPlugin and specialized editors (aapt/) that directly manipulate compiled resources.

Android and iOS developers at organizations building large apps who need to split codebases into separately-owned feature teams without the complexity of full plugin architectures. Specifically targets teams using Gradle build systems who want modular development workflows and faster iteration cycles.

Moderately mature but aging: the framework has a complete Android implementation (322KB Java, extensive Groovy build tooling) and iOS support, with CI/CD via Travis CI. However, the codebase shows signs of gradual deprecation—the most recent activity visible suggests it peaked around 2016–2018 era (Gradle 2.3.0, Android SDK 25–27 buildTools), and there's no evidence of active maintenance for modern Android/iOS standards. Suitable for legacy system maintenance but risky for new projects.

Significant dependency-age risk: uses Gradle 2.3.0 (release candidate era, now 8+ versions behind stable) and Android buildTools v25 (5+ years outdated). The monolithic buildSrc structure with 60+ Gradle plugin files creates tight coupling; no package management separation visible. Single-maintainer appearance (wequick org) and lack of recent commits suggest bus factor risk. Binary format manipulation (aapt/, ArscEditor, AXmlEditor) adds fragility to resource handling across Android versions.

No visible recent activity in provided data. The .travis.yml suggests automated CI was configured but no recent commits or PR activity is evident. The buildSrc structure and all plugin implementations appear frozen at their final state.

Clone and explore the Android sample:

git clone https://github.com/wequick/Small.git
cd Small/Android/DevSample
./gradlew build  # Requires Gradle 2.3.0+ compatibility (may need wrapper update)

For iOS: cd Small/iOS && pod install (if Podfile exists; not visible in file list).

Daily commands: For Android DevSample:

cd Android/DevSample
./gradlew assemble        # Build all modules
./gradlew small:build     # Build only the 'small' plugin
./gradlew assembleDebug   # Create debug APK with bundles-as-assets

CI runs via .travis.yml (see TravisCI config). Note: Gradle wrapper compatibility may require update to modern versions.

• Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/RootPlugin.groovy — Entry point for the Small gradle plugin system that orchestrates all module builds and bundle assembly
• Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/BundlePlugin.groovy — Core plugin that transforms individual modules into Small bundles with resource splitting and manifest rewriting
• Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/aapt/ArscEditor.groovy — Modifies compiled Android resource tables to enable resource namespace splitting between bundles
• Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/aapt/AXmlEditor.groovy — Edits binary AndroidManifest.xml files to isolate component declarations per bundle
• Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/BasePlugin.groovy — Abstract base plugin containing shared build configuration and lifecycle hooks for all Small plugin types
• Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/util/DependenciesUtils.groovy — Manages dependency graph analysis to prevent duplicate classes across bundles and the host
• Android/DevSample/build.gradle — Sample DevSample project configuration demonstrating Small bundle plugin application and build settings

Create a new Small Bundle Module

1. Add new module directory with build.gradle applying Small bundle plugin (Android/DevSample/settings.gradle)
2. Apply bundle plugin and configure in module build.gradle (Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/BundlePlugin.groovy)
3. Define bundle-specific settings using BundleExtension (Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/BundleExtension.groovy)
4. Ensure manifest components are declared in module AndroidManifest.xml (AXmlEditor will isolate them) (Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/aapt/AXmlEditor.groovy)

Add Resource Splitting Configuration

1. Configure strictSplitResources in root small { } block (Android/DevSample/build.gradle)
2. ArscEditor automatically splits resource namespace IDs when building bundles (Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/aapt/ArscEditor.groovy)
3. Verify resource isolation with bundle manifest tests (Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/test/BundleManifestTests.groovy)

Resolve Dependency Conflicts Between Bundles

1. DependenciesUtils analyzes classpath to find duplicate classes (Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/util/DependenciesUtils.groovy)
2. StripAarTransform removes duplicates from AAR dependencies in bundles (Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/transform/StripAarTransform.groovy)
3. Run DuplicateClassesTests to validate no conflicts remain (Android/DevSample/buildSrc/src/main/groovy/net/wequick/gradle/test/DuplicateClassesTests.groovy)

Support Data Binding in Bundles

1. Create DataBinderMappable implementation in each bundle (Android/DevSample/small-databinding/src/main/java/small/databinding/DataBinderMappable.java)
2. Register bundle's mapper in central DataBinderMapper registry (Android/DevSample/small-databinding/src/main/java/small/databinding/DataBinderMapper.java)
3. Ensure small-databinding module is included as dependency (Android/DevSample/small-databinding/build.gradle)

• Gradle Plugin (Groovy) — Extends Android Gradle plugin with custom build tasks for module splitting, resource namespace management, and manifest rewriting
• Binary XML/ARSC Editing — Directly manipulates compiled AndroidManifest.xml and resources to isolate bundle namespaces without source recompilation
• ASM/Bytecode Tools — Analyzes .class files to detect and eliminate duplicate classes from AAR dependencies across bundles
• AA — undefined

Gradle version constraint: buildSrc assumes Gradle 2.3.0 (classpath 'com.android.tools.build:gradle:2.3.0'); Android plugin now requires Gradle 4.1+. Resource collision gotcha: strictSplitResources = false in root small {} means resource IDs can collide between bundles—set to true if your app has >1 active bundle. Binary format fragility: ArscEditor and AXmlEditor directly manipulate compiled binary formats (ARSC, compiled XML); Android OS resource format changes between SDK versions can break parsing. Asset loading path: buildToAssets = true embeds bundles as raw assets; you must ensure bundle loading code exists in host app (not visible in sample). No Kotlin support: KotlinCompat.groovy exists but appears to be stub/placeholder—Kotlin bundle compilation may fail. Missing IDE support: No AndroidStudio plugin integration; bundle edits don't auto-sync in IDE preview.

• Android Resource Table (ARSC) Binary Format — Small's entire resource isolation strategy depends on parsing and rewriting ARSC chunks in compiled APKs (ArscEditor, ResTableType, ResTableEntry)—understanding this binary format is essential to diagnosing resource collision bugs and adapting to Android OS changes
• Gradle Plugin Development (Groovy DSL) — The entire buildSrc/ system (BasePlugin, AppPlugin, BundlePlugin) uses Gradle's Groovy plugin API; modifying build behavior requires understanding Task registration, Extension blocks, and cross-project configuration
• APK/AAR Module Resource Namespace Isolation — Small solves the problem of multiple APK/AAR bundles sharing a single APK process without resource ID collisions by remapping R ids per-bundle (SymbolParser, ArscEditor)—this pattern is fundamental to understanding why strictSplitResources exists
• Binary Hex Editing and Format Parsing (CppHexEditor pattern) — Small manipulates compiled binary formats (ARSC, compiled XML) at build time rather than runtime—this requires low-level byte array manipulation (see CppHexEditor, ResStringPoolSpan) to inject resource ID mappings without re-compiling
• Dynamic Feature Loading via Asset Extraction — Small embeds bundle APKs as raw assets (buildToAssets=true) and loads them at runtime; this requires understanding ClassLoader delegation, AssetManager APIs, and DEX loading—the actual runtime loading code isn't in buildSrc but is critical to deployment
• Manifest Rewriting and Component Routing (AXmlEditor) — Bundle manifests are rewritten to route all Activities/Services through the host app's framework rather than registering them directly (AXmlEditor); understanding compiled XML format is needed to debug component dispatch failures
• Multi-Module Gradle Build Orchestration — RootPlugin and extension classes (RootExtension, BundleExtension, AppExtension) coordinate build logic across multiple Gradle modules—understanding task dependencies and subproject configuration is required to add new build phases

• alibaba/atlas — Direct competitor: Android app modularization framework using similar bundle-as-asset pattern; more actively maintained with better Gradle 4.x+ support
• google/bundletool — Modern official Google alternative: handles dynamic feature modules and asset delivery; represents post-Small evolution of the modularization problem
• Tencent/Shadow — Contemporary Chinese framework solving same plugin isolation problem with additional process/DexClassLoader sandboxing; more robust than Small for hostile bundle scenarios
• wequick/Ruru — Same author (wequick)—appears to be framework refactoring/successor; may contain modernized versions of Small's patterns
• google/android-gradle-dsl — Official Android Gradle plugin API reference; needed to understand BasePlugin and AppPlugin's Gradle API usage and modern alternatives

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 Gradle plugin transform and utility classes

The buildSrc contains complex Gradle plugin logic (StripAarTransform.groovy, ClassFileUtils.groovy, ZipUtils.groovy, DependenciesUtils.groovy) that manipulates Android resources and bytecode, but there are no visible test files in the repository. These utilities are critical for the plugin's core functionality of splitting apps into bundles. Adding unit tests would prevent regressions and improve maintainability.

• [ ] Create Android/DevSample/buildSrc/src/test/groovy directory structure
• [ ] Add test class for StripAarTransform.groovy covering AAR stripping scenarios
• [ ] Add test class for ClassFileUtils.groovy covering class file manipulation
• [ ] Add test class for ZipUtils.groovy covering ZIP file operations
• [ ] Add test class for DependenciesUtils.groovy covering dependency resolution
• [ ] Update Android/DevSample/buildSrc/build.gradle with testImplementation dependencies (spock, junit)

Add integration tests for BundlePlugin resource splitting logic

The BundlePlugin.groovy and related AAPT utilities (ArscEditor.groovy, AXmlEditor.groovy, SymbolParser.groovy) handle critical resource splitting and manifest manipulation. The BundleTests.gradle file exists but Android/DevSample lacks visible integration tests validating that bundles correctly split resources without duplication or corruption. This is essential given the strictSplitResources configuration option.

• [ ] Create Android/DevSample/BundleTests directory with test fixtures (test bundles with shared resources)
• [ ] Add integration test validating ArscEditor correctly splits resource tables across bundles
• [ ] Add integration test validating AXmlEditor correctly rewrites manifest package names
• [ ] Add integration test validating no duplicate resources appear in final bundles
• [ ] Add test for strictSplitResources=true vs false behavior
• [ ] Update BundleTests.gradle to execute these integration tests in CI

Add GitHub Actions CI/CD workflow for multi-version Android SDK testing

The .travis.yml exists (legacy CI) but there's no visible GitHub Actions workflow. The project supports Android API 9+ and uses Gradle 2.3.0, but it's unclear if builds are tested against multiple SDK versions or build tool versions. Adding a matrix-based workflow would catch compatibility issues early (e.g., AGP compatibility, Java version compatibility).

• [ ] Create .github/workflows/android-build.yml with matrix testing for compileSdkVersion=[25, 27, 30, 31]
• [ ] Include matrix for buildToolsVersion and AGP version compatibility checks
• [ ] Add lint checks for buildSrc Groovy code quality
• [ ] Add test task execution for bundling scenarios
• [ ] Add artifact upload for failed build logs
• [ ] Update README.md with GitHub Actions badge

• Upgrade Gradle wrapper from 2.3.0 to current stable (8.x) and update Android Gradle plugin dependency in buildSrc/build.gradle—requires testing ArscEditor/AXmlEditor binary parsing against latest AAPT2 output format (involves modifying ResTableType.groovy and CppHexEditor.groovy to handle new resource chunks)
• Add integration tests for resource ID collision detection: BundleTests.gradle exists but contains no actual test cases for verifying strictSplitResources={true,false} behavior—write parameterized tests that build 2+ bundles with overlapping resource names and verify ArscEditor remapping is correct
• Document symbol table format and resource remapping algorithm: README.md mentions 'resource splitting' but SymbolParser.groovy and the R.txt→ID remapping logic are undocumented—add inline code comments and a doc/ file explaining how resource IDs are rewritten to prevent collisions across bundles

The codebase has significant security concerns primarily related to outdated dependencies and build infrastructure. The Gradle build tools (2.3.0), Android build tools (25.0.2), and support libraries (25.1.0) are all 6+ years old and lack critical security patches. The reliance on the defunct JCenter repository and missing dependency verification mechanisms creates additional risk. The target and compile SDK versions are below current standards, missing modern Android security features. Immediate action is required to update the build system and migrate to current, maintained dependencies.

• High · Outdated Gradle Build Tools — Android/DevSample/build.gradle (dependencies section). The build configuration uses Gradle 2.3.0 (com.android.tools.build:gradle:2.3.0) which is significantly outdated and contains multiple known security vulnerabilities. This version was released in April 2017 and is no longer maintained. Fix: Update to the latest stable version of Android Gradle Plugin (currently 7.x or 8.x). This will include security patches, vulnerability fixes, and improved build security features.
• High · Outdated Build Tools Version — Android/DevSample/build.gradle (android.buildToolsVersion). Build tools version 25.0.2 is outdated (released in 2016). This version may contain security vulnerabilities and lacks modern security features in the Android build system. Fix: Update buildToolsVersion to a recent stable release (33.0.0 or newer). Ensure alignment with the latest Android SDK standards.
• High · Outdated Support Library — Android/DevSample/build.gradle (android.supportVersion). Support library version 25.1.0 is deprecated and outdated (released in 2016). It lacks current security patches and maintenance. Google has migrated to AndroidX. Fix: Migrate from the legacy Support Library to AndroidX artifacts. Use androidx.* libraries instead of com.android.support.* packages with current versions.
• Medium · Deprecated Gradle Repository (JCenter) — Android/DevSample/build.gradle (buildscript.repositories and allprojects.repositories). The build configuration relies on JCenter repository (jcenter()) which was shut down by JFrog in 2021. This repository is no longer maintained and may serve compromised or outdated dependencies. Fix: Replace JCenter with Maven Central (mavenCentral()) and Google's Maven repository (google()). Update all repository references in build files.
• Medium · Missing Gradle Security Configuration — Android/DevSample/build.gradle. No checksum verification or signature validation configured for dependencies. This could allow man-in-the-middle attacks or dependency tampering. Fix: Implement dependency verification using Gradle's built-in verification features (verify-metadata.xml or dependency signatures). Consider using gradle/wrapper/gradle-wrapper.properties with checksum verification.
• Low · Resource Modification Disabled by Default — Android/DevSample/build.gradle (small.strictSplitResources). The configuration sets 'strictSplitResources = false' which disables strict resource splitting validation, potentially allowing unintended resource access patterns. Fix: Review the necessity of disabling strict resource splitting. If possible, enable it (set to true) and address any resulting build issues to ensure proper resource isolation.
• Low · Compiled Target SDK Below Current Standard — Android/DevSample/build.gradle (android.compileSdkVersion). compileSdkVersion is set to 27 (Android 8.1), which is significantly below the current recommended version (33+). This may miss important security features and privacy protections. Fix: Update compileSdkVersion to 33 or higher to leverage the latest Android security features, permissions model updates, and privacy enhancements.

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.