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/xuexiangjys/XUI 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.

AVOID — Looks unmaintained — solo project with stale commits

• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Solo or near-solo (1 contributor active in 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 xuexiangjys/XUI repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/xuexiangjys/XUI.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "xuexiangjys/XUI(\\.git)?\\b" \\
  && ok "origin remote is xuexiangjys/XUI" \\
  || miss "origin remote is not xuexiangjys/XUI (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 "app/src/main/java/com/xuexiang/xuidemo/MyApp.java" \\
  && ok "app/src/main/java/com/xuexiang/xuidemo/MyApp.java" \\
  || miss "missing critical file: app/src/main/java/com/xuexiang/xuidemo/MyApp.java"
test -f "app/src/main/java/com/xuexiang/xuidemo/activity/MainActivity.java" \\
  && ok "app/src/main/java/com/xuexiang/xuidemo/activity/MainActivity.java" \\
  || miss "missing critical file: app/src/main/java/com/xuexiang/xuidemo/activity/MainActivity.java"
test -f "app/build.gradle" \\
  && ok "app/build.gradle" \\
  || miss "missing critical file: app/build.gradle"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "app/src/main/AndroidManifest.xml" \\
  && ok "app/src/main/AndroidManifest.xml" \\
  || miss "missing critical file: app/src/main/AndroidManifest.xml"

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

XUI is a lightweight Android native UI framework (< 1MB) that provides 40+ pre-built Material Design components (TextView, Button, EditText, Dialog, PopupWindow, Banner, TabBar, StateLayout, FlowLayout, etc.) with customizable themes to accelerate Android app development without writing boilerplate layout code. Monorepo structure: app/ is a feature-complete demo with Material Design themes and sample screens (proto, SMS, chart HTML assets in app/src/main/assets/); the core XUI library likely sits in a top-level library module (not visible in top 60 files—check for xui/ or similar). Plugins are registered via build.gradle (xaop, xrouter-plugin, booster) for annotation processing and routing.

Android developers building consumer-facing apps who want to ship polished UI quickly using native Android components and Material Design patterns without wrestling with custom View implementations or third-party design systems.

Production-ready. The project has 7.8k+ GitHub stars, extensive documentation at the wiki, a live demo APK (app/apk/xuidemo.apk), and v1.2.1 stability (versionCode 22). However, recent commit activity is not visible in the file list; check the git log to confirm ongoing maintenance.

Low-to-moderate risk: single maintainer (xuexiangjys) is a known concern for long-term support; the codebase uses older minSdkVersion 17 (pre-Android 5.0) which may lag on modern OS features; proguard configuration present but no visible automated testing framework in the file structure. Monitor upstream Android SDK deprecations.

The file list shows v1.2.1 was the last tagged release. The presence of JitPackUpload.gradle and Maven Central versioning suggests active JitPack distribution. No PR or open-issues metadata is visible; check the GitHub Issues tab and recent commit history for current work streams.

Check README for instructions.

Daily commands:

./gradlew :app:assembleDebug  # Build debug APK
./gradlew :app:installDebug   # Deploy to connected device
adb shell am start -n com.xuexiang.xuidemo/.MainActivity  # Launch app

Requires Android Studio 4.0+, SDK API 17+, and an emulator or device.

• app/src/main/java/com/xuexiang/xuidemo/MyApp.java — Application entry point and initialization hub for XUI framework setup and configuration
• app/src/main/java/com/xuexiang/xuidemo/activity/MainActivity.java — Primary activity demonstrating the core UI components and framework usage patterns
• app/build.gradle — Build configuration defining XUI plugin dependencies, SDK versions, and annotation processors
• README.md — Framework documentation covering supported components, installation, and API usage guidelines
• app/src/main/AndroidManifest.xml — Android manifest declaring all activities, permissions, and framework-level configurations
• app/src/main/java/com/xuexiang/xuidemo/DemoDataProvider.java — Central data provider for demo activities, showcasing typical model/data patterns used in XUI apps

• MainActivity (Android Activity, RecyclerView, Intent) — Entry point activity managing the demo navigation menu; displays all available UI components and routes user selections to specific demo activities
  • Failure mode: If navigation fails, user cannot access any demos; requires restart
• DemoDataProvider (JSON parsing, Asset loading, Data serialization) — Singleton data source providing mock content for all adapters and activities; parses JSON assets and generates structured data objects
  • Failure mode: If data fails to load, all demo activities display empty or default states
• Adapter Pattern (RecyclerView) (RecyclerView.Adapter, ViewHolder, Delegate pattern) — Multi-type adapter implementations (Common, News, Delegate) binding data to views; handles view recycling and type-specific rendering logic

Add a New Demo Activity Showcasing a UI Component

1. Create new Activity class in app/src/main/java/com/xuexiang/xuidemo/activity/ (app/src/main/java/com/xuexiang/xuidemo/activity/YourComponentActivity.java)
2. Add Activity declaration to AndroidManifest.xml (app/src/main/AndroidManifest.xml)
3. Register data source in DemoDataProvider.java with component metadata (app/src/main/java/com/xuexiang/xuidemo/DemoDataProvider.java)
4. Add menu item in MainActivity to route to new activity (app/src/main/java/com/xuexiang/xuidemo/activity/MainActivity.java)

Add a Custom RecyclerView Adapter for New Content Type

1. Create data entity class in app/src/main/java/com/xuexiang/xuidemo/adapter/entity/ (app/src/main/java/com/xuexiang/xuidemo/adapter/entity/YourContentType.java)
2. Create adapter extending CommonRecyclerViewAdapter in app/src/main/java/com/xuexiang/xuidemo/adapter/ (app/src/main/java/com/xuexiang/xuidemo/adapter/YourContentAdapter.java)
3. Implement onBindViewHolder and getItemViewType overrides for custom rendering (app/src/main/java/com/xuexiang/xuidemo/adapter/YourContentAdapter.java)
4. Generate test data in DemoDataProvider.java for adapter testing (app/src/main/java/com/xuexiang/xuidemo/DemoDataProvider.java)

Add Static Content Assets (Fonts, Data, Web Resources)

1. Place asset files in appropriate subdirectory under app/src/main/assets/ (app/src/main/assets/your_category/your_resource)
2. Reference asset in code using AssetManager or direct path strings (app/src/main/java/com/xuexiang/xuidemo/activity/MainActivity.java)
3. For JSON data, add dataset to assets and load in DemoDataProvider or target activity (app/src/main/java/com/xuexiang/xuidemo/DemoDataProvider.java)

• Android Native (No Cross-Platform) — XUI is a pure Android framework providing direct access to native components without abstraction layers; enables fine-grained styling and performance optimization
• Gradle with XUI Plugins (XAOP, XRouter) — Annotation processing and automatic route registration reduce boilerplate and enable compile-time optimization of navigation and aspect-oriented features
• RecyclerView with Delegate Adapters — Multi-type content rendering with clear separation of concerns; delegate pattern minimizes adapter complexity for mixed content types
• Material Design Theming — undefined

• Minimum API Level 17 (Android 4.2) instead of higher

  • Why: Broader device compatibility to reach legacy devices
  • Consequence: Cannot use modern APIs like AndroidX stable features; requires support library dependencies and compatibility shims

• Demo-heavy structure with embedded sample activities

  • Why: Developers can directly learn from working examples without external documentation
  • Consequence: Larger APK size and app complexity; not ideal for production app templates but excellent for framework education

• Annotation-driven plugin system (XAOP, XRouter) vs. reflection-based

  • Why: Compile-time route registration and AOP weaving avoids runtime reflection overhead
  • Consequence: Requires annotation processors in build pipeline; more build complexity but faster runtime

• Backend API integration or network layer abstraction (framework provides only UI)
• Real-time data synchronization or reactive streams (example data is static)
• Cross-platform support (Android-only native framework)
• Authentication or security module (app handles permissions only)
• Database or persistent storage layer (examples use only in-memory data)

1. The actual XUI library code is not in the top 60 files—it likely lives in a separate module (e.g., xui/ or library/) that must be cloned and explored. 2) Build requires Baidu LBS SDK (app/libs/BaiduLBS_Android.jar) which is pre-downloaded; removing it breaks location-based demo features. 3) Gradle plugins (xaop, xrouter-plugin) must be available in buildscript classpath—check gradle/dependencies.gradle or top-level settings.gradle for plugin repositories. 4) ProGuard rules are strict (minifyEnabled=true); new components must add keep rules or they'll be stripped in release builds. 5) versionCode/versionName are hardcoded in build.gradle—CI automation likely updates these before publishing.

• Custom AttributeSet (Android XML attributes) — XUI's 40+ components use custom XML attributes in layout files to configure appearance/behavior without code; understanding AttributeSet and TypedArray is essential to customizing and extending XUI views.
• Material Design theme inheritance (android:theme) — XUI ships with predefined Material Design themes that apps inherit via theme overlays; mastering theme cascading, color palettes, and style inheritance is key to consistent UI across the app.
• Annotation Processing & APT (Annotation Processor Tool) — XUI uses xaop and xrouter plugins which rely on Java annotations and compile-time code generation to reduce boilerplate; understanding @Annotation + annotationProcessorOptions is required to extend routing or AOP features.
• ProGuard obfuscation and minification — XUI libraries must survive ProGuard shrinking (minifyEnabled=true in release builds); improper keep rules cause stripped methods and crashes in production—critical for safe release builds.
• Multi-architecture NDK native libraries — The Baidu LBS library is packaged for 4 ARM/x86 architectures; understanding ABI filtering (abiFilters) and architecture-specific .so files is needed to support device families and avoid APK bloat.
• WebView bridge (JavaScript-Java interop) — XUI includes WebView-based components (e.g., chart/ with ECharts.js, SMS form in sms/sms.html); understanding addJavascriptInterface() and evaluateJavascript() is necessary to build hybrid UI features.
• Gradle plugin development & plugin classpath — XUI uses custom Gradle plugins (xaop, xrouter-plugin, booster); understanding buildscript dependencies and plugin application order is essential for adding new build-time code generation.

• material-components/material-components-android — Official Material Design components library for Android; XUI can be compared or integrated alongside MDC for advanced patterns.
• xuexiangjys/XPageRoute — Companion router library by the same author; likely integrates with XUI's xrouter-plugin for navigation between screens.
• xuexiangjys/XAOP — Aspect-Oriented Programming library by the same author; XUI uses xaop plugin for annotation-driven cross-cutting concerns (logging, permissions, etc.).
• alibaba/Tangram-Android — Alternative card/container-based UI framework for Android; different design philosophy but solves same problem of rapid component composition.
• xuexiangjys/TemplateAppProject — Official starter template repo for XUI integration; go-to reference for setting up a new project with XUI and all companion libraries.

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 instrumented UI tests for core XUI components (TextView, Button, EditText, Dialog, PopupWindow)

The repo lacks automated UI testing for its main UI framework components. With multiple custom components and demos in app/src/main/java/com/xuexiang/xuidemo/activity/, there's no corresponding test directory structure. This is critical for a UI framework to ensure visual consistency and functionality across Android versions (API 17+). Adding Android instrumented tests would catch regressions early and make contributions safer.

• [ ] Create app/src/androidTest/java/com/xuexiang/xuidemo/ directory structure
• [ ] Write instrumented tests for core components: TextViewTest, ButtonTest, EditTextTest, DialogTest, PopupWindowTest using Espresso framework
• [ ] Add test assertions for component rendering, state changes, and user interactions
• [ ] Reference existing demo activities (LoginActivity.java, SearchViewActivity.java) for test scenarios
• [ ] Configure build.gradle with androidTestImplementation dependencies (androidx.test.espresso)

Add GitHub Actions CI workflow for automated APK builds and testing on multiple API levels

The repo supports API 17+ but lacks CI/CD automation. With app/build.gradle showing multiple NDK architectures (armeabi, armeabi-v7a, x86, x86_64) and release signing configs, a GitHub Actions workflow would validate builds across different Android versions. Currently, contributors cannot verify their changes work on the full API range without manual testing.

• [ ] Create .github/workflows/android-ci.yml with Android Gradle tasks
• [ ] Configure matrix strategy to test builds on multiple targetSdkVersion (minimum API 17, current target, and latest)
• [ ] Add Gradle build commands: ./gradlew build, ./gradlew connectedAndroidTest for emulator testing
• [ ] Include APK artifact upload step to validate release builds similar to apk/xuidemo.apk
• [ ] Add status badge to README.md linking to workflow results

Document XUI component API reference and add missing examples for complex components (FlowLayout, Banner, GuideView, StateLayout)

README.md lists 20+ UI components but provides no specific documentation or code examples. VersionAdapter.md exists but is about version compatibility, not component usage. Demo activities exist (MainActivity.java references components) but there's no dedicated documentation directory explaining each component's properties, methods, and customization. New contributors struggle to understand how to use StateLayout, FlowLayout, or GuideView.

• [ ] Create docs/ directory with component-specific markdown files: FlowLayout.md, Banner.md, GuideView.md, StateLayout.md
• [ ] Extract usage examples from corresponding demo activities and include code snippets in documentation
• [ ] Document key XML attributes, Java methods, and common customization patterns for each component
• [ ] Add links to component documentation in README.md under the components section
• [ ] Include before/after screenshots from app assets (app/src/main/assets/) or demo APK

• Add unit tests for core UI components (e.g., XUI TextView custom attributes, XUI Button state handling) in tests/ directory—currently no visible test/ folder suggests test coverage gap.
• Document theme customization: create a themes/THEMING.md file with step-by-step examples showing how to override default Material Design colors and typography in app/src/main/res/values/styles.xml.
• Implement accessibility (a11y) labels for all interactive components in the demo app (Button, EditText, Spinner) using android:contentDescription and android:labelFor attributes.

• High · Hardcoded Credentials in Build Configuration — app/build.gradle (release build type configuration). The app/build.gradle file contains references to signing credentials stored in local.properties (APP_ID_BUGLY, APP_ID_UMENG). While the actual values are in local.properties (which should be gitignored), the build configuration logic exposes the pattern of credential management. Additionally, if local.properties is accidentally committed, it could expose sensitive API keys and credentials. Fix: Ensure local.properties is in .gitignore (verify it is). Use Android Gradle Secrets Plugin or environment variables for sensitive credentials. Never commit API keys or tokens. Consider using Google Play App Signing and managed signing configurations.
• High · Insecure WebView Asset Files with Potential XSS Risk — app/src/main/assets/ (HTML and JS files). Multiple HTML and JavaScript files are present in assets (jsTest.html, sms.html, upload_file/jsuploadfile.html, upload_file/uploadfile.html, chart/src/index.html). If these files use WebView with JavaScript enabled and load user-controlled content, there's a significant XSS (Cross-Site Scripting) vulnerability risk. The chart integration using echarts-all.js and custom template.js increases this risk. Fix: Implement strict Content Security Policy (CSP) headers. Disable JavaScript in WebView if not needed. Validate and sanitize all user input before rendering in WebView. Use WebView's setWebContentsDebuggingEnabled(false) in production. Review echarts and template.js for potential injection vectors.
• High · Unencrypted Local File Storage — app/src/main/assets/ (JSON and TXT files). The presence of JSON data files (alibaba/data.json, eleme.json, province.json) and protocol text files (account_protocol.txt, privacy_protocol.txt) in the assets folder suggests potential storage of sensitive data in plaintext. If these are also stored in the app's local database or SharedPreferences, they're vulnerable to extraction on rooted devices. Fix: Encrypt sensitive data at rest using AndroidKeyStore. Store sensitive data in EncryptedSharedPreferences. Avoid including sensitive information in assets. If data must be included, encrypt it with app-specific encryption keys.
• Medium · Weak ABI Filter Configuration — app/build.gradle (ndk abiFilters configuration). The build.gradle specifies ndk abiFilters as 'armeabi', 'armeabi-v7a', 'x86'. The 'armeabi' architecture is deprecated and should not be used in modern Android apps. Additionally, x86 architecture support combined with the presence of native libraries (BaiduLBS_Android.jar and .so files) could be a vector for architecture-specific exploits. Fix: Remove 'armeabi' from abiFilters. Use only 'armeabi-v7a' and 'arm64-v8a' for most users, or 'arm64-v8a' alone if targeting modern devices. Review and update all native library dependencies (particularly BaiduLBS) to their latest secure versions.
• Medium · Third-Party Native Library with Uncertain Security Status — app/libs/ (BaiduLBS_Android.jar and liblocSDK7b.so files). The app includes BaiduLBS_Android.jar and corresponding .so files across multiple architectures. Baidu's location services library is a third-party dependency that may have outdated security patching or privacy concerns. No version information is visible in the file structure. Fix: Verify the version and security status of BaiduLBS library. Check Baidu's security advisories and update to the latest version. Consider using Google Play Services Location API as an alternative. Review privacy implications of location data collection.
• Medium · Debuggable Build Configuration in Debug Mode — app/build.gradle (debug buildType) and app/proguard-rules.pro. The debug build type has debuggable=true, which is appropriate for development. However, if the release APK (xuidemo.apk in /apk folder) was built with debuggable=true, it could allow attackers to inject code or inspect sensitive data at runtime. Fix: Ensure debuggable=false in release builds (verify current configuration). Never ship APKs with debuggable=true. Implement runtime integrity checks and certificate pinning to detect

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.