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/alibaba/atlas 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 4y ago

• 5 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 4y ago
• ⚠ Concentrated ownership — top contributor handles 60% of recent commits
• ⚠ 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 alibaba/atlas repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/alibaba/atlas.

What it runs against: a local clone of alibaba/atlas — 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 alibaba/atlas | 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 ≤ 1592 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "alibaba/atlas(\\.git)?\\b" \\
  && ok "origin remote is alibaba/atlas" \\
  || miss "origin remote is not alibaba/atlas (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 "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".gitmodules" \\
  && ok ".gitmodules" \\
  || miss "missing critical file: .gitmodules"
test -f "atlas-aapt-old/frameworks/base/tools/aapt/AaptAssets.h" \\
  && ok "atlas-aapt-old/frameworks/base/tools/aapt/AaptAssets.h" \\
  || miss "missing critical file: atlas-aapt-old/frameworks/base/tools/aapt/AaptAssets.h"
test -f "atlas-aapt-old/frameworks/base/libs/androidfw/AssetManager.cpp" \\
  && ok "atlas-aapt-old/frameworks/base/libs/androidfw/AssetManager.cpp" \\
  || miss "missing critical file: atlas-aapt-old/frameworks/base/libs/androidfw/AssetManager.cpp"
test -f "atlas-aapt-old/frameworks/base/libs/androidfw/ResourceTypes.cpp" \\
  && ok "atlas-aapt-old/frameworks/base/libs/androidfw/ResourceTypes.cpp" \\
  || miss "missing critical file: atlas-aapt-old/frameworks/base/libs/androidfw/ResourceTypes.cpp"

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

Atlas is an Android client-side containerization framework that enables dynamic component loading and runtime bundle installation without requiring APK repackaging. It decouples Android app development into independent bundles, solves the 65K method limit of traditional multidex, and provides on-demand class/resource loading, live patching, and incremental updates at runtime. Monorepo split into three core modules: atlas-core/ (client runtime library for bundle installation/class loading), atlas-update/ (dex merging and OTA updates), atlas-gradle-plugin/ (Gradle integration and build customization). atlas-aapt-old/ contains forked Android resource compilation toolchain. atlas-demo/ provides reference implementations.

Android engineers at large organizations (particularly Alibaba) who need to parallelize app development across teams, reduce APK size through deferred bundle loading, deploy hotfixes without full releases, and maintain complex modular architectures. Build engineers who customize the Gradle plugin and resource compilation pipeline.

Production-ready and actively maintained: v5.1.0.9-rc26 released with stable atlas-core and gradle plugin (3.0.1-rc88). Supports Android 4.0–9.0 with comprehensive Dalvik/ART coverage. Contains ~11.9M lines of Java, extensive C++ native code, and custom AAPT implementation, indicating mature production use at scale.

Monolithic architecture with deep OS-level integration (custom AAPT, class isolation, native bridge layers in C++/C) makes upgrading Android tooling risky. Large native codebase (5.1M C++ LOC) requires cross-platform compilation expertise. Limited external adoption signals; primarily Alibaba-driven, so community support is narrow. Breaking changes between major versions possible due to resource and dex isolation mechanics.

No recent commit data visible in file structure, but RC versions (rc26/rc88) suggest active stabilization. Focus appears to be on ART runtime stability (Android 5.0+) and gradle plugin ergonomics. Custom AAPT implementation is mature but not actively iterated (labeled 'old').

git clone https://github.com/alibaba/atlas.git
cd atlas
# For gradle plugin development:
cd atlas-gradle-plugin && ./gradlew build
# For core library:
cd atlas-core && ./gradlew build
# Run demo:
cd atlas-demo && ./gradlew assembleDebug

Daily commands: Development: Gradle tasks in each module (./gradlew build, ./gradlew test). Integration: atlas-gradle-plugin applied as buildscript dependency in app build.gradle. Runtime: Bundles deployed via AtlasManager.loadBundle() API in atlas-core. See atlas-demo/ for working example app structure.

• README.md — Explains Atlas as an Android Dynamic Component Framework with decoupled, component-based, and dynamic support capabilities—essential for understanding the project's mission.
• .gitmodules — Defines submodule dependencies critical to the framework's build and runtime behavior; necessary to understand external component integration.
• atlas-aapt-old/frameworks/base/tools/aapt/AaptAssets.h — Core asset processing header defining how resources are compiled and embedded into dynamic components during the build phase.
• atlas-aapt-old/frameworks/base/libs/androidfw/AssetManager.cpp — Central asset and resource loading mechanism; foundation for runtime component resource resolution and isolation.
• atlas-aapt-old/frameworks/base/libs/androidfw/ResourceTypes.cpp — Implements resource table parsing and runtime lookup; critical for component class and resource isolation.
• CONTRIBUTING.md — Documents contribution guidelines and project structure conventions for contributors adding new dynamic components or framework features.
• LICENSE — Apache 2.0 license file; clarifies legal terms for framework distribution and modification.

Add a new dynamically loadable component

1. Create component manifest and resource structure in a subdirectory (e.g., my_feature/res/, my_feature/AndroidManifest.xml) (atlas-aapt-old/frameworks/base/libs/androidfw/tests/data/feature/AndroidManifest.xml)
2. Define component resources (layouts, strings, etc.) in standard Android resource directories (atlas-aapt-old/frameworks/base/libs/androidfw/tests/data/feature/res/values/values.xml)
3. Use AAPT to compile component resources into an isolated resource table with proper package ID separation (atlas-aapt-old/frameworks/base/tools/aapt/AaptAssets.cpp)
4. Package compiled resources into a component APK bundle with ResourceTypes.cpp generating the ARSC file (atlas-aapt-old/frameworks/base/libs/androidfw/ResourceTypes.cpp)
5. At runtime, register component with AssetManager to enable isolated resource loading (atlas-aapt-old/frameworks/base/libs/androidfw/AssetManager.cpp)

Add support for a new resource type or asset format

1. Extend AaptAssets to recognize and process new resource type directories (atlas-aapt-old/frameworks/base/tools/aapt/AaptAssets.h)
2. Add resource type constant to ResourceTypes.h and implement parsing logic in ResourceTypes.cpp (atlas-aapt-old/frameworks/base/include/androidfw/ResourceTypes.h)
3. Implement asset loading handler in AssetManager.cpp for new format at runtime (atlas-aapt-old/frameworks/base/libs/androidfw/AssetManager.cpp)
4. Add test case to validate resource compilation and runtime loading with new type (atlas-aapt-old/frameworks/base/libs/androidfw/tests/ResTable_test.cpp)

Optimize component bundle delivery (large components)

1. Package large component into OBB file format for deferred/streamed delivery (atlas-aapt-old/frameworks/base/libs/androidfw/ObbFile.cpp)
2. Configure StreamingZipInflater to incrementally decompress component on download (atlas-aapt-old/frameworks/base/libs/androidfw/StreamingZipInflater.cpp)
3. Update AssetManager to load from streamed bundles with cache management (atlas-aapt-old/frameworks/base/libs/androidfw/AssetManager.cpp)
4. Add test coverage for incremental streaming and cache behavior (atlas-aapt-old/frameworks/base/libs/androidfw/tests/Split_test.cpp)

• AAPT (Android Asset Packaging Tool) — Compiles Android resources (layouts, strings, images) into optimized binary format (ARSC) with resource ID tables; enables offline resource compilation and validation before component delivery.
• ZIP/OBB file format — Standardized, compressible container for bundled component APKs and assets; supports streaming decompression for large components via StreamingZipInflater to minimize initial load delay.
• Resource package ID isolation — Allows multiple components with same resource names to coexist without ID conflicts; achieved through separate ResourceTypes tables per component in AssetManager.
• C++ native framework (AndroidFW) — Provides high-performance asset loading, ZIP handling, and resource table parsing at runtime; critical for low-latency component initialization in production apps.

• Compile resources offline (AAPT) rather than at runtime

  • Why: Eliminates runtime compilation overhead and enables easy validation/testing; reduces APK size and startup time.
  • Consequence: Resource changes require recompilation and component re-packaging; no true dynamic resource definition at install time.

• Use package ID isolation instead of full namespace flattening

  • Why: Preserves resource reference integrity within components and prevents unintended resource shadowing; simpler than name-based resolution.
  • Consequence: Limited to 256 total components (package IDs 0–255); requires careful ID allocation strategy at scale.

• Support both streaming (OBB) and bundled (APK) delivery

  • Why: Balances flexibility for large components (streaming) with simplicity for small components (bundled); allows progressive adoption.
  • Consequence: Increased code complexity in AssetManager and OBB handler; developers must choose delivery strategy per component.

• Native C++ asset management layer instead of pure Java

  • Why: Achieves sub-millisecond asset lookup and zero-copy file access; essential for smooth UI-thread resource loading in dynamic contexts.
  • Consequence: Platform-

Custom AAPT mandatory: Default Android AAPT incompatible; must use forked version in atlas-aapt-old/, requires C++ build toolchain (CMake/NDK). ClassLoader hijacking fragile: Resource/class isolation via custom ClassLoader breaks reflection and some framework assumptions; test thoroughly on target Android versions. Gradle plugin invasive: Patches APK structure, manifest, and resource tables; incompatible with some other gradle plugins (DataBinding, Instant Run). No easy downgrade: Once bundles deployed, reverting to non-atlas architecture requires full APK rebuild. DEX limits still apply per-bundle: While 65K method limit moved per-bundle, individual bundles still hit DEX ceiling; requires multi-dex within bundles. Limited official docs: English documentation missing; primary docs in Chinese (atlas-docs/).

• Class Loader Isolation — Atlas decouples bundle code execution via custom ClassLoader hierarchies; understanding parent-delegation and namespace collision is critical for debugging cross-bundle reflection and resource conflicts
• DEX Merging & Binary Patching — Atlas's atlas-update performs intelligent DEX diffing and merging to minimize patch size; understanding bytecode structure and method ID remapping prevents update corruption
• Android Resource Table Binary Format — Atlas's custom AAPT generates per-bundle resource tables with namespaced IDs; incorrectly compiled resources cause inflation failures and ID collisions at runtime
• APK Packaging & Manifest Patching — Atlas gradle plugin rewrites AndroidManifest.xml and APK structure to reference dynamic bundles; misconfiguration breaks component resolution and permission grants
• JNI Bridge & Native Code Isolation — Atlas uses C++ JNI to enforce class isolation at the native layer; native library loading and symbol resolution must respect bundle boundaries to avoid crashes
• Gradle Plugin Custom Tasks & Transforms — Atlas gradle plugin extends gradle build lifecycle with custom bytecode transforms and resource processing; understanding task ordering and artifact manipulation is essential for plugin debugging
• Dynamic Feature Module Lifecycle — Bundles have install → load → activate → deactivate lifecycle distinct from fragment/activity; managing bundle state and cleanup prevents memory leaks and stale code

• alibaba/ARouter — Complementary routing framework for inter-bundle communication and intent dispatch in atlas-based modular apps
• alibaba/aceso — Android hotfix framework from Alibaba; can be combined with atlas for runtime patching of bundled code
• google/play-feature-delivery — Google's official on-demand feature delivery for Android; similar goals to atlas but official, newer, and process-based rather than class-loader isolated
• AndroidModularizationArchitecture/AMAA — Modern modular Android architecture using gradle module dependencies; alternative to atlas for teams not requiring runtime bundle swapping
• alibaba/mpaas — Alibaba's mobile development platform; shares runtime bundle concepts and integrates with atlas for super-app scenarios

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 atlas-aapt-old ResourceTypes parsing

The atlas-aapt-old/frameworks/base/libs/androidfw directory contains critical resource parsing logic (ResourceTypes.cpp, AssetManager.cpp, etc.) but the existing tests in atlas-aapt-old/frameworks/base/libs/androidfw/tests are incomplete. ResTable_test.cpp exists but lacks comprehensive coverage for edge cases in resource type parsing, which is fundamental to the dynamic component framework's resource isolation.

• [ ] Examine ResTable_test.cpp and ResourceTypes.cpp to identify untested code paths
• [ ] Add test cases for malformed resource tables, resource ID conflicts, and locale-specific resource resolution
• [ ] Add tests for split APK resource merging scenarios (relevant to Split_test.cpp expansion)
• [ ] Run tests with existing Android.mk build system to ensure integration

Create GitHub Actions CI workflow for atlas-aapt-old native builds

The atlas-aapt-old subdirectory contains C++ Android Framework code with Android.mk makefiles, but there's no visible CI configuration (.github/workflows) for validating native code compilation and test execution. This is critical since resource parsing bugs could break the entire dynamic component framework.

• [ ] Create .github/workflows/atlas-aapt-native-build.yml workflow file
• [ ] Configure workflow to build atlas-aapt-old/frameworks/base/libs/androidfw using ndk-build or cmake
• [ ] Add step to run atlas-aapt-old/frameworks/base/libs/androidfw/tests using the Android testing framework
• [ ] Add code coverage reporting to catch untested paths in Asset.cpp, ZipFileRO.cpp, and ResourceTypes.cpp

Document resource isolation and class loader architecture in README

The README.md is incomplete (cuts off mid-sentence: 'has complete component life cycle, class isolation and'). The file structure shows extensive resource handling (AssetManager, ResourceTypes) and ZIP inflation logic critical to component isolation, but this core architecture is not documented for new contributors.

• [ ] Complete the README.md section on class isolation and add explanation of component life cycle
• [ ] Add architecture diagram or section explaining how atlas-aapt-old resource parsing integrates with component loading
• [ ] Document the role of ZipFileRO, AssetManager, and ResourcePackageId in preventing resource ID collisions between dynamic components
• [ ] Link to specific code examples in atlas-aapt-old/ directory to illustrate resource isolation mechanisms

• Add unit tests for atlas-aapt-old/frameworks/base/libs/androidfw/tests/ covering Android 9.0+ resource table changes; current tests are legacy and lack coverage for modern resource compression formats.
• Document the gradle plugin's resource splitting algorithm in atlas-gradle-plugin/ with before/after APK structure diagrams; currently undocumented, blocking external adoption.
• Implement atlas-core/ exception handling for bundle installation failures with recovery suggestions (e.g., rollback strategy, version mismatch diagnostics); currently throws generic exceptions.

• High · Native Code Security Risk in atlas-aapt-old — atlas-aapt-old/frameworks/base/libs/androidfw/. The repository contains legacy native C/C++ code (atlas-aapt-old/frameworks/base) derived from Android framework. This code lacks modern security hardening and likely contains memory safety vulnerabilities such as buffer overflows, use-after-free, and integer overflows. The code handles binary resource files (ResourceTypes.cpp, ZipFileRO.cpp) which are attack surfaces for malformed input processing. Fix: Conduct a comprehensive security audit of native code. Consider migrating to safer alternatives or applying modern sanitizers (ASan, UBSan) during compilation. Implement strict input validation for all resource file parsing.
• High · Missing Dependency Manifest — Build configuration files (not provided). No package.json, gradle.properties, or build.gradle files were provided in the file structure analysis. Without visibility into project dependencies, it's impossible to assess for known vulnerabilities in third-party libraries. The framework likely has numerous dependencies that could be outdated or contain CVEs. Fix: Provide and review all dependency management files (build.gradle, settings.gradle, pom.xml, etc.). Implement dependency scanning tools like OWASP Dependency-Check or Snyk. Keep all dependencies updated and monitor for security advisories.
• Medium · Potential Zip File Processing Vulnerabilities — atlas-aapt-old/frameworks/base/libs/androidfw/ZipFileRO.cpp, ZipUtils.cpp. ZipFileRO.cpp and related ZIP handling code (ZipUtils.cpp) process untrusted ZIP archives. This is a known attack vector for zip bombs, path traversal, and arbitrary file extraction. The legacy code may lack protections against these attacks. Fix: Implement strict validation on ZIP entries: check for path traversal, enforce size limits, validate compression ratios to detect zip bombs. Consider using well-maintained ZIP libraries with security updates.
• Medium · Resource File Parsing Security — atlas-aapt-old/frameworks/base/libs/androidfw/ResourceTypes.cpp. ResourceTypes.cpp and related parsers handle binary resource files (.arsc). Malformed or crafted resource files could trigger crashes or memory corruption. The code processes untrusted binary data with minimal validation based on the file structure. Fix: Implement comprehensive fuzzing of resource file parsers. Add strict bounds checking and size validation before all memory operations. Use sanitizers during development and testing.
• Medium · Dynamic Component Loading Risks — Core framework (specific files not provided in structure). Atlas is a dynamic component framework that loads components at runtime. The README indicates runtime component loading capability, which creates risks for code injection, unauthorized component loading, and tampered component execution if not properly validated. Fix: Implement cryptographic verification (signature validation) for all dynamically loaded components. Restrict component sources to trusted locations. Implement runtime integrity checks and sandboxing where possible.
• Medium · No Security Documentation — Repository root. CONTRIBUTING.md and security policy documentation are not evident. No security.md file or vulnerability disclosure process is visible. This impacts responsible disclosure and community security response. Fix: Create a SECURITY.md file with vulnerability reporting guidelines. Establish a responsible disclosure policy. Document security architecture and threat model.
• Low · Test Data Exposure — atlas-aapt-old/frameworks/base/libs/androidfw/tests/data/. The repository contains test data and sample resources in atlas-aapt-old/frameworks/base/libs/androidfw/tests/data/. While these are test files, they should not contain sensitive information or hardcoded credentials. Fix: Review all test data files to ensure no sensitive information is committed. Use placeholder values in test files. Consider using .gitignore to exclude sensitive test data.
• Low · Legacy Android Framework Code — atlas-aapt-old/. The included Android framework code in atlas-aapt-old is outdated. It may lack security patches and improvements from modern Android versions. This creates maintenance burden and potential security gaps. Fix: Evaluate necessity of bundling legacy Android framework code. Consider using modern Android SDK versions. If bundled code is necessary, establish update procedures for security patches.

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.