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/hongyangAndroid/AndroidAutoLayout 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 7y ago

• 3 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 7y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 90% 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 hongyangAndroid/AndroidAutoLayout repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/hongyangAndroid/AndroidAutoLayout.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "hongyangAndroid/AndroidAutoLayout(\\.git)?\\b" \\
  && ok "origin remote is hongyangAndroid/AndroidAutoLayout" \\
  || miss "origin remote is not hongyangAndroid/AndroidAutoLayout (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 "autolayout/src/main/java/com/zhy/autolayout/AutoLayoutActivity.java" \\
  && ok "autolayout/src/main/java/com/zhy/autolayout/AutoLayoutActivity.java" \\
  || miss "missing critical file: autolayout/src/main/java/com/zhy/autolayout/AutoLayoutActivity.java"
test -f "autolayout/src/main/java/com/zhy/autolayout/AutoLayoutInfo.java" \\
  && ok "autolayout/src/main/java/com/zhy/autolayout/AutoLayoutInfo.java" \\
  || miss "missing critical file: autolayout/src/main/java/com/zhy/autolayout/AutoLayoutInfo.java"
test -f "autolayout/src/main/java/com/zhy/autolayout/utils/AutoLayoutHelper.java" \\
  && ok "autolayout/src/main/java/com/zhy/autolayout/utils/AutoLayoutHelper.java" \\
  || miss "missing critical file: autolayout/src/main/java/com/zhy/autolayout/utils/AutoLayoutHelper.java"
test -f "autolayout/src/main/java/com/zhy/autolayout/config/AutoLayoutConifg.java" \\
  && ok "autolayout/src/main/java/com/zhy/autolayout/config/AutoLayoutConifg.java" \\
  || miss "missing critical file: autolayout/src/main/java/com/zhy/autolayout/config/AutoLayoutConifg.java"
test -f "autolayout/src/main/java/com/zhy/autolayout/attr/Attrs.java" \\
  && ok "autolayout/src/main/java/com/zhy/autolayout/attr/Attrs.java" \\
  || miss "missing critical file: autolayout/src/main/java/com/zhy/autolayout/attr/Attrs.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 2750 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2720d)"
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/hongyangAndroid/AndroidAutoLayout"
  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).

AndroidAutoLayout is a screen adaptation framework for Android that allows developers to use design document pixel dimensions directly in XML layouts—the framework automatically scales them for different device resolutions. Instead of calculating dp values or maintaining multiple dimen files, you write the exact px from your design mockup (768×1280) and the library proportionally scales all layout_width, layout_height, margins, padding, and textSize across all screen sizes. Two-module Gradle project: app/ (sample demonstration with MainActivity showing adaption across resolutions) and autolayout-widget/ (the core library containing AutoLayoutActivity, AutoLinearLayout, AutoRelativeLayout, AutoFrameLayout, and supporting utilities). Core logic intercepts layout inflation and applies scaling based on design_width/design_height metadata from AndroidManifest.xml.

Android developers who receive fixed-size design mockups (typically 768×1280 or similar) and want to implement pixel-perfect layouts without manual scaling calculations. Especially valuable for teams with many screen sizes to support, where maintaining dimens.xml per configuration becomes unwieldy.

ABANDONED. The project is explicitly marked [停止维护] (stopped maintenance) in the title and README. Last significant activity appears to be around 2015–2016 era (compileSdkVersion 23, pre-AndroidX). The author explicitly recommends migrating to AndroidAutoSize instead. Not suitable for new projects.

HIGH RISK for production use. The codebase is unmaintained and uses deprecated Android APIs (pre-AndroidX, old support libraries). No CI/CD visible, minimal test coverage, and single-maintainer archival. The README explicitly warns: 'has no energy, stop maintenance—must understand code thoroughly before using.' Migration path exists to AndroidAutoSize but represents technical debt.

Nothing. Project is in maintenance-free state. README explicitly directs new users to AndroidAutoSize (JessYanCoding/AndroidAutoSize) which is actively maintained. No PRs, issues resolution, or updates expected.

Clone: git clone https://github.com/hongyangAndroid/AndroidAutoLayout.git && cd AndroidAutoLayout. Build: ./gradlew build (requires Android SDK 23, buildTools 23.0.1). Open in Android Studio and run app/ module on an emulator or device to see adaptation preview.

Daily commands: This is a library, not a runnable app. To test: open in Android Studio → Run app/ module → emulator/device displays layouts scaled to design_width/design_height. Preview precision requires selecting a device profile matching your design dimensions (e.g., 768×1280 tablet).

• autolayout/src/main/java/com/zhy/autolayout/AutoLayoutActivity.java — Base activity class that all screen-adapted activities must extend; core entry point for applying auto-layout transformations
• autolayout/src/main/java/com/zhy/autolayout/AutoLayoutInfo.java — Data model storing dimension metadata and scale factors; central to converting design px to device-specific dimensions
• autolayout/src/main/java/com/zhy/autolayout/utils/AutoLayoutHelper.java — Core helper orchestrating layout traversal and attribute application; bridges configuration and individual view adaptation
• autolayout/src/main/java/com/zhy/autolayout/config/AutoLayoutConifg.java — Global configuration singleton defining design canvas dimensions and orientation; essential for all scale calculations
• autolayout/src/main/java/com/zhy/autolayout/attr/Attrs.java — Registry mapping attribute types (width, height, margin, padding, textSize) to handler classes; enables extensible attribute system
• autolayout/src/main/java/com/zhy/autolayout/AutoLinearLayout.java — Auto-adapting LinearLayout subclass demonstrating pattern for custom layout containers
• autolayout/src/main/java/com/zhy/autolayout/AutoRelativeLayout.java — Auto-adapting RelativeLayout subclass; commonly used container in adaptation hierarchy

Add Support for a New Dimension Attribute

1. Create a new class extending AutoAttr in autolayout/src/main/java/com/zhy/autolayout/attr/ (autolayout/src/main/java/com/zhy/autolayout/attr/AutoAttr.java)
2. Implement apply() method to convert px value and set on LayoutParams or View (autolayout/src/main/java/com/zhy/autolayout/attr/WidthAttr.java)
3. Register new attribute in Attrs.getAutuAttrs() map (autolayout/src/main/java/com/zhy/autolayout/attr/Attrs.java)
4. Use new attribute in layout XML with px values: android:attr_name="100px" (app/src/main/res/layout/activity_main.xml)

Create an Auto-Adapting Custom View

1. Extend a base auto-layout container (AutoLinearLayout, AutoFrameLayout, etc.) (autolayout/src/main/java/com/zhy/autolayout/AutoLinearLayout.java)
2. Override onMeasure() if custom sizing logic needed; call super first (autolayout/src/main/java/com/zhy/autolayout/AutoFrameLayout.java)
3. In layout XML, use your custom view and specify px dimensions directly (app/src/main/res/layout/activity_main.xml)

Configure Design Canvas Size & Orientation Mode

1. Initialize AutoLayoutConifg in Application or Activity onCreate() (autolayout/src/main/java/com/zhy/autolayout/config/AutoLayoutConifg.java)
2. Call AutoLayoutConifg.getInstance().setDesignWidth(px) and setDesignHeight(px) from design mockup (app/src/main/java/zhy/com/autolayout/MainActivity.java)
3. Optionally annotate activity with @UseLandscape if using landscape orientation (autolayout/src/main/java/com/zhy/autolayout/config/UseLandscape.java)

Adapt Layouts Without Extending AutoLayoutActivity

1. Use AutoUtils convenience methods instead of extending base activity (autolayout/src/main/java/com/zhy/autolayout/utils/AutoUtils.java)
2. Call AutoUtils.setAutoScaledPx() or AutoUtils.setAutoScaledDip() on individual views (app/src/main/java/zhy/com/autolayout/MainActivity.java)

• Custom LayoutParams + View Subclasses — Allows intercepting measure/layout phases to apply design-driven scaling without layout XML modification
• Pluggable Attribute System (AutoAttr registry) — Decouples attribute parsing from application logic; enables adding new dimensions (e.g., borderRadius) without core changes
• DPI-based Scaling Ratio — Normalizes design px to device DPI; works across all screen sizes and densities via single formula
• Activity-level Base Class (AutoLayoutActivity) — Simplest integration path: one inheritance replaces manual dp/dimen calculations throughout codebase
• Orientation Annotation (@UseLandscape) — Allows separate design canvas dimensions per activity orientation without runtime branching

• Direct px values in layout XML rather than dp

  • Why: Eliminates designer-to-developer translation; px maps directly to design mockup
  • Consequence: Requires developer discipline to input values correctly; no IDE validation that px match design mockup

• Static global AutoLayoutConifg singleton

  • Why: Simplifies API; one-time setup for entire app
  • Consequence: Cannot support multiple design canvases per app; orientation changes require annotation workaround

• View tree traversal at inflate/measure time

  • Why: Real-time adaptation without post-processing or layout XML generation
  • Consequence: Overhead on every view creation; no compile-time optimization or code generation

• Supports only LinearLayout, RelativeLayout, FrameLayout (+ widgets)

  • Why: Covers majority of real-world
  • Consequence: undefined

1. Design dimensions (design_width/design_height) MUST be set in app AndroidManifest.xml meta-data or scaling silently fails. 2) Preview accuracy requires selecting a device profile matching your design resolution; generic previews won't show real scaling. 3) By default uses available height (excludes status/nav bars)—call AutoLayoutConfig.useDeviceSize() in Application.onCreate() to use physical screen height instead. 4) Only works if Activity extends AutoLayoutActivity OR you manually replace layout classes with Auto* variants; third-party layouts (CardView) require manual wrapping per issue#21 pattern. 5) No AndroidX support—will fail on modern Android projects.

• Design-based pixel scaling (px → dp conversion on per-device basis) — This repo's core innovation—understanding how onMeasure() intercepts dimension values and applies ratio scaling (design_width/device_width) to maintain proportional layouts across vastly different screen sizes
• Layout inflation interception (LayoutInflater.Factory) — AutoLayoutActivity uses setContentView() override to wrap inflated layout objects; learning this pattern is essential to understanding how the framework gains control over all child views
• ViewGroup measurement and layout pass (onMeasure, onLayout) — Core Auto*Layout classes override these to apply scaled dimensions before Android's standard measurement; essential to grasp how custom ViewGroups enforce pixel constraints
• AndroidManifest meta-data for runtime configuration — design_width and design_height are declared as meta-data tags and read at runtime via ApplicationInfo.metaData; demonstrates app-level config pattern without code changes
• Density-independent pixels (dp) vs raw pixels (px) — This library redefines 'px' in layout files to mean 'design document pixels' rather than raw screen pixels; critical distinction since Google discourages raw px usage in layouts
• Aspect ratio preservation in responsive design — The library scales width and height proportionally based on device size, ensuring UI elements maintain relative spacing and proportions across resolutions without manual calculation

• JessYanCoding/AndroidAutoSize — Direct successor—maintained alternative by author who used AndroidAutoLayout for 3 years; recommended migration target with low cost per official README
• hongyangAndroid/AndroidSuperTextView — Same author's custom TextView supporting advanced text styling; often paired with auto-layout solutions for text-heavy UIs
• google/flexbox-layout — Modern alternative for responsive layout without fixed design dimensions; uses flex ratios instead of pixel mapping

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 AndroidUnit Tests for AutoLayout Core Calculation Logic

The autolayout/src/androidTest directory exists but appears empty. Add comprehensive unit tests for the core pixel-to-dp conversion logic that is central to this library's functionality. This is critical since the entire value proposition depends on accurate layout calculations across different screen densities. Tests should verify conversion accuracy for common screen densities (mdpi, hdpi, xhdpi, xxhdpi) and edge cases.

• [ ] Create test files in autolayout/src/androidTest/java/zhy/com/autolayout/ for core conversion utilities
• [ ] Add tests verifying px-to-dp conversion accuracy across different screen densities
• [ ] Add tests for AutoLayoutParams and layout measurement logic with various dimension inputs
• [ ] Add tests for edge cases (zero dimensions, very large dimensions, unusual aspect ratios)
• [ ] Verify tests pass on multiple Android API levels (minSdkVersion 10 through targetSdkVersion 23)

Create Migration Guide Documentation from AndroidAutoLayout to AndroidAutoSize

The README already recommends migrating to AndroidAutoSize due to this library being unmaintained, and mentions a migration guide exists (issue #90). However, no migration documentation is present in the repo itself. Create a MIGRATION.md file with concrete before/after code examples specific to the autolayout-widget module classes (AutoToolbar, AutoTabLayout, AutoTableLayout, etc.) to help users transition off this deprecated library.

• [ ] Create MIGRATION.md in repo root documenting step-by-step migration from AndroidAutoLayout to AndroidAutoSize
• [ ] Add specific code migration examples for autolayout-widget classes: AutoToolbar.java, AutoTabLayout.java, AutoCardView.java, AutoTableLayout.java
• [ ] Include dependency replacement instructions for build.gradle files in app/ and autolayout/ modules
• [ ] Add section explaining differences in attribute usage between the two libraries
• [ ] Include common pitfalls and troubleshooting tips based on the library's design

Add ProGuard/R8 Configuration Validation Tests for autolayout-widget Module

The autolayout-widget/proguard-rules.pro file exists but lacks verification that ProGuard rules are correct and comprehensive. Since this is a library providing custom Views (AutoActionMenuItemView, AutoCardView, etc.) that users will include in their apps, the ProGuard configuration must be validated. Add tests that verify the library's custom views remain intact after minification and that reflection-based layout inflation still works correctly.

• [ ] Create androidTest in autolayout-widget/src/androidTest for ProGuard rule validation
• [ ] Add test verifying custom View classes (AutoToolbar, AutoTabLayout, etc.) are accessible by name after minification
• [ ] Add test verifying layout inflation with custom attributes still works after ProGuard processing
• [ ] Add test validating that keep rules in proguard-rules.pro actually protect necessary classes
• [ ] Document any new required keep rules discovered during testing in autolayout-widget/proguard-rules.pro

• Add unit tests for dimension scaling math in autolayout-widget/src/androidTest/—currently no test coverage for core calculation logic (verify px→scaled px conversion on various design sizes)
• Document AutoLayoutHelper pattern for extending unsupported ViewGroups (CardView, BottomNavigationView, etc.)—README mentions issue#21 but provides no recipe; create a guide with runnable example in app/
• Migrate sample app from compileSdkVersion 23 to modern API level and AndroidX—allows verification that library still functions on current Android versions (currently untested on API 28+)

The codebase has CRITICAL security concerns. The project uses extremely outdated dependencies (from 2015) including Android SDK 23, support library 23.1.0, and supports API level 10. The project is explicitly unmaintained and deprecated. These factors collectively create significant security vulnerabilities through unpatched framework issues, deprecated APIs, and lack of ongoing security updates. Immediate migration to a maintained solution (such as AndroidAutoSize) and modernization of the entire dependency stack is strongly recommended before any production use.

• High · Outdated Android SDK and Build Tools — app/build.gradle, autolayout/build.gradle, autolayout-widget/build.gradle. The project uses compileSdkVersion 23 and buildToolsVersion 23.0.1, which are extremely outdated (released in 2015). This exposes the application to numerous known security vulnerabilities in the Android framework that have been patched in newer versions. Fix: Update compileSdkVersion to at least 33+ and buildToolsVersion to the latest stable version (34+). Update targetSdkVersion to match or be close to compileSdkVersion.
• High · Outdated Support Library Dependency — app/build.gradle. The project uses appcompat-v7:23.1.0, released in 2015. This version contains multiple known security vulnerabilities. The appcompat library is critical for security patches and compatibility. Fix: Update to androidx.appcompat:appcompat:1.6.1 or latest stable version. Consider migrating from legacy support library to AndroidX.
• High · Minimum SDK Version Too Low (API 10) — app/build.gradle. minSdkVersion is set to 10 (Android 2.3.3, released 2011). This requires the application to support devices with numerous unpatched security vulnerabilities and deprecated APIs. Fix: Increase minSdkVersion to at least 21 (Android 5.0, 2014) or higher. Most app stores now require API 26+ minimum.
• Medium · ProGuard Configuration May Be Incomplete — app/proguard-rules.pro, autolayout/proguard-rules.pro, autolayout-widget/proguard-rules.pro. The proguard-rules.pro file is referenced but not examined in this analysis. If not properly configured, sensitive code patterns and class/method names could be exposed through reverse engineering. Fix: Review and enhance proguard-rules.pro configuration to properly obfuscate sensitive code. Consider using R8/D8 instead of ProGuard for better optimization and security.
• Medium · Deprecated Project - Unmaintained Code — README.md. The project README explicitly states '[停止维护] (DEPRECATED)' and 'no longer maintained'. Using deprecated and unmaintained libraries/frameworks exposes the application to unpatched security vulnerabilities. Fix: Migrate to the actively maintained AndroidAutoSize library as recommended in the README. Ensure all dependencies are from projects with active maintenance.
• Low · Missing Manifest Hardening Attributes — app/src/main/AndroidManifest.xml, autolayout/src/main/AndroidManifest.xml. Without reviewing the AndroidManifest.xml content, common security attributes like android:usesCleartextTraffic and android:allowBackup cannot be verified. These are important for preventing unencrypted traffic and accidental backup of sensitive data. Fix: Ensure android:usesCleartextTraffic is set to false, android:allowBackup is set to false (or properly configured), and implement proper intent filters with proper protections.

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.