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

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "hugeterry/CoordinatorTabLayout(\\.git)?\\b" \\
  && ok "origin remote is hugeterry/CoordinatorTabLayout" \\
  || miss "origin remote is not hugeterry/CoordinatorTabLayout (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 "coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/CoordinatorTabLayout.java" \\
  && ok "coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/CoordinatorTabLayout.java" \\
  || miss "missing critical file: coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/CoordinatorTabLayout.java"
test -f "coordinatortablayout/src/main/res/layout/view_coordinatortablayout.xml" \\
  && ok "coordinatortablayout/src/main/res/layout/view_coordinatortablayout.xml" \\
  || miss "missing critical file: coordinatortablayout/src/main/res/layout/view_coordinatortablayout.xml"
test -f "coordinatortablayout/src/main/res/values/attrs.xml" \\
  && ok "coordinatortablayout/src/main/res/values/attrs.xml" \\
  || miss "missing critical file: coordinatortablayout/src/main/res/values/attrs.xml"
test -f "coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/listener/OnTabSelectedListener.java" \\
  && ok "coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/listener/OnTabSelectedListener.java" \\
  || miss "missing critical file: coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/listener/OnTabSelectedListener.java"
test -f "sample/src/main/java/cn/hugeterry/coordinatortablayoutdemo/MainActivity.java" \\
  && ok "sample/src/main/java/cn/hugeterry/coordinatortablayoutdemo/MainActivity.java" \\
  || miss "missing critical file: sample/src/main/java/cn/hugeterry/coordinatortablayoutdemo/MainActivity.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 2357 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2327d)"
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/hugeterry/CoordinatorTabLayout"
  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).

CoordinatorTabLayout is an Android custom composite control that unifies TabLayout and CoordinatorLayout to create a collapsible header UI pattern. It wraps a CollapsingToolbarLayout containing a TabLayout, allowing tabs to collapse as users scroll content in a ViewPager, with support for dynamic header images and color scrims per tab. Single-module library structure: coordinatortablayout/ contains src/main/java with core CoordinatorTabLayout.java, listener interfaces (LoadHeaderImagesListener, OnTabSelectedListener), utilities (SystemView), layout XMLs (view_coordinatortablayout.xml), and attrs.xml for custom attributes. Sample app in sample/ directory demonstrates usage.

Android developers building material-design apps with collapsible tab headers (e.g., news apps, social feeds, or multi-section content UIs) who want to avoid boilerplate layout composition and behavior coordination between AppBarLayout and TabLayout.

Mature and stable. The codebase is 13.6 KB of Java, published to Bintray (v1.2.2), includes sample app and resource files, but shows no recent commit timestamps in the file list and no CI configuration visible. It appears actively maintained for a single-purpose library but not under active development.

Low risk for the narrow use case. Single-maintainer library (hugeterry), no obvious external dependencies listed in build.gradle snippet, and focused scope reduce fragility. However, no visible unit tests (only ExampleUnitTest.java stub) and targeting older Support Library v4 may cause friction with modern AndroidX codebases.

No active development signals visible from file list alone (no timestamps, no CI logs, no .github/workflows). The library appears stable/dormant post-v1.2.2 release.

git clone https://github.com/hugeterry/CoordinatorTabLayout.git
cd CoordinatorTabLayout
./gradlew build
./gradlew :sample:installDebug

Daily commands: Open coordinatortablayout/ in Android Studio, run gradlew :sample:assembleDebug to build the demo app, or use ./gradlew :sample:installDebug to push to a connected emulator/device. No web dev server or external services required.

• coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/CoordinatorTabLayout.java — Core composite control that extends CoordinatorLayout and integrates TabLayout with CollapsingToolbarLayout—every contributor must understand this as it defines the primary public API and behavior.
• coordinatortablayout/src/main/res/layout/view_coordinatortablayout.xml — Defines the XML layout structure combining AppBarLayout, CollapsingToolbarLayout, TabLayout, and ViewPager—essential to understand the visual hierarchy and component relationships.
• coordinatortablayout/src/main/res/values/attrs.xml — Declares all custom XML attributes exposed by CoordinatorTabLayout—necessary reference for API customization options.
• coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/listener/OnTabSelectedListener.java — Callback interface for tab selection events—critical for understanding how consumers integrate with tab state changes.
• sample/src/main/java/cn/hugeterry/coordinatortablayoutdemo/MainActivity.java — Primary sample demonstrating full usage pattern including ViewPager setup and tab configuration—essential reference for integration.
• coordinatortablayout/build.gradle — Build configuration defining library's dependencies (Material Design, AppCompat, Support library versions)—critical for compatibility management.

Add a Custom Attribute to CoordinatorTabLayout

1. Define the attribute in the custom declare-styleable block (coordinatortablayout/src/main/res/values/attrs.xml)
2. Read the attribute in CoordinatorTabLayout constructor using TypedArray.obtainStyledAttributes() (coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/CoordinatorTabLayout.java)
3. Apply the attribute value to relevant child components (AppBarLayout, TabLayout, etc.) in the layout inflation (coordinatortablayout/src/main/res/layout/view_coordinatortablayout.xml)

Handle a New Tab Selection Event

1. Create a new callback method or extend OnTabSelectedListener interface in the listener package (coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/listener/OnTabSelectedListener.java)
2. In CoordinatorTabLayout, add a setter method (e.g., setOnTabSelectedListener) and store the listener (coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/CoordinatorTabLayout.java)
3. Trigger the callback when TabLayout fires onTabSelected() or onTabUnselected() events (coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/CoordinatorTabLayout.java)
4. Test in sample app by implementing the listener in MainActivity (sample/src/main/java/cn/hugeterry/coordinatortablayoutdemo/MainActivity.java)

Integrate Async Header Image Loading

1. Implement the LoadHeaderImagesListener interface in your activity/fragment (coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/listener/LoadHeaderImagesListener.java)
2. Call coordinatorTabLayout.setLoadHeaderImagesListener() with your implementation in MainActivity or Fragment (sample/src/main/java/cn/hugeterry/coordinatortablayoutdemo/LoadHeaderImageFromNetworkActivity.java)
3. In the callback, fetch image URLs (network, local, etc.) and use an ImageLoader (Picasso, Glide) to populate the header ImageView (sample/src/main/java/cn/hugeterry/coordinatortablayoutdemo/LoadHeaderImageFromNetworkActivity.java)
4. Call the provided callback function when images load to update the CollapsingToolbarLayout (coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/CoordinatorTabLayout.java)

Add a New Sample Tab with Custom Fragment Content

1. Create a new Fragment class that extends Fragment and returns content from onCreateView() (sample/src/main/java/cn/hugeterry/coordinatortablayoutdemo/MainFragment.java)
2. Add the fragment to MyPagerAdapter.getItem() method with appropriate position-based logic (sample/src/main/java/cn/hugeterry/coordinatortablayoutdemo/MyPagerAdapter.java)
3. Define a RecyclerView or ListView in the fragment layout to display scrollable content (sample/src/main/res/layout/fragment_main.xml)
4. Update MainActivity to add a new TabLayout.Tab via addTab() and update the ViewPager page count in the adapter (sample/src/main/java/cn/hugeterry/coordinatortablayoutdemo/MainActivity.java)

• CoordinatorLayout (AndroidX/Support Library) — Provides coordinated scrolling and collapse behavior between AppBarLayout, CollapsingToolbarLayout, and content (ViewPager). Standard Material Design pattern for collapsing headers.
• CollapsingToolbarLayout — Manages title and header image collapse/expand animation synchronized with nested scroll content; core Material Design component.
• TabLayout — Provides scrollable tab UI with indicator and Material Design styling; integrates natively with ViewPager.
• ViewPager + FragmentPagerAdapter — Manages swipeable fragment-based tab content; standard Android pattern for tabbed navigation.
• AppBarLayout — Wraps CollapsingToolbarLayout and manages scroll flags to coordinate collapse behavior with nested scrolling.

• Use custom composite control (CoordinatorTabLayout) vs. inline XML composition

  • Why: Reduces boilerplate for developers and ensures consistent behavior; provides reusable encapsulation.
  • Consequence: Hides internal XML hierarchy from consumers; less flexible for advanced customization (must extend or add public methods).

• Support library dependencies (AppCompat, Support v4) vs. AndroidX

  • Why: Broader device/API level support at time of development; backward compatibility with older projects.
  • Consequence: Legacy dependency tree; projects must manage support library versions; cannot use AndroidX APIs directly.

• Async image loading via listener callback vs. built-in ImageLoader

  • Why: Remains agnostic to image loading library (Picasso, Glide, Fresco); reduces dependencies and allows consumer choice.
  • Consequence: Developer must implement LoadHeaderImagesListener; no default image management provided.

Using old Support Library v4 (android.support.v4.view.ViewPager) instead of AndroidX may cause conflicts in newer projects—consider migrating to androidx.viewpager.widget.ViewPager if onboarding to a modern codebase. The library assumes a single TabLayout + ViewPager pairing; nesting multiple CoordinatorTabLayouts or mixing with custom behaviors may cause unexpected scroll interactions due to AppBarLayout's z-order and scroll flags.

• CoordinatorLayout & Behavior system — CoordinatorTabLayout leverages CoordinatorLayout's child Behavior system to coordinate AppBarLayout collapse with ViewPager scroll; understanding Behavior callbacks is essential to extending or debugging scroll synchronization
• CollapsingToolbarLayout scroll flags — The internal layout template uses scroll flags (e.g., SCROLL_FLAG_EXIT_UNTIL_COLLAPSED) to define how TabLayout collapses; tweaking these flags changes the visual behavior
• ViewPager adapter synchronization — setupWithViewPager() binds TabLayout to ViewPager; understanding ViewPager.OnPageChangeListener and TabLayout.OnTabSelectedListener is critical for handling tab/page mismatches and image/color array switching
• Custom ViewGroup inflation & composition — CoordinatorTabLayout is a custom ViewGroup that inflates view_coordinatortablayout.xml as its internal structure; understanding LayoutInflater and ViewGroup hierarchy is needed to modify the layout or add new internal views
• Content scrim & drawable transitions — The library supports swapping header images and color scrims per tab (via setImageArray() and colorArray); understanding CollapsingToolbarLayout's setContentScrim() and drawable tinting is needed for color customization
• Translucent status bar & system UI integration — setTranslucentStatusBar() adjusts system window insets and status bar appearance; this requires API 19+ awareness and FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS handling

• material-components/material-components-android — Official Material Design components library providing TabLayout, AppBarLayout, and CollapsingToolbarLayout that CoordinatorTabLayout composes
• chrisbanes/cheesecake — Similar collapsible header + ViewPager pattern example showing how to manually wire CoordinatorLayout behaviors (predecessor/inspiration)
• AndroidPublishingGuide/AndroidPublishingGuide — Reference for publishing Android libraries to Bintray (same distribution channel this project uses)
• google/architecture-components-samples — Companion reference for modern Android app patterns (ViewModel, LiveData) that could be integrated with CoordinatorTabLayout in sample apps

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 tests for CoordinatorTabLayout core functionality

The repo has placeholder ExampleInstrumentedTest.java files but lacks actual tests for the main CoordinatorTabLayout.java component. Given this is a UI library combining TabLayout and CoordinatorLayout, testing collapse/expand behavior, tab switching, header image loading, and scroll interactions would catch regressions and help contributors understand the intended behavior.

• [ ] Create coordinatortablayout/src/androidTest/java/cn/hugeterry/coordinatortablayout/CoordinatorTabLayoutTest.java with tests for collapse/expand state transitions
• [ ] Add tests in coordinatortablayout/src/androidTest for LoadHeaderImagesListener callback behavior and image loading edge cases
• [ ] Add instrumented tests for OnTabSelectedListener and tab selection coordination with scroll events
• [ ] Run tests on multiple API levels to ensure CoordinatorLayout/TabLayout compatibility

Add unit tests for SystemView utility class

The coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/utils/SystemView.java file exists but has no corresponding unit test. Utility classes benefit from isolated unit tests, especially ones dealing with system-level operations like status bar handling or system view calculations.

• [ ] Create coordinatortablayout/src/test/java/cn/hugeterry/coordinatortablayout/utils/SystemViewTest.java
• [ ] Add test cases for any public methods in SystemView.java that manipulate or calculate system view properties
• [ ] Mock Android system calls using Robolectric or Mockito as needed
• [ ] Replace placeholder ExampleUnitTest.java with actual SystemView tests

Add GitHub Actions CI workflow for Gradle builds and testing

The repo uses Gradle with dependencies pointing to jcenter() (deprecated) and no visible CI configuration. Adding a GitHub Actions workflow would ensure builds pass on new PRs, catch compatibility issues early, and provide confidence for contributors. This is critical since the build.gradle shows outdated Android Gradle plugin (3.0.1) that should be validated.

• [ ] Create .github/workflows/android-build.yml that runs 'gradlew build' on push/PR
• [ ] Configure the workflow to run instrumented tests on an Android emulator using reactivecircus/android-emulator-runner
• [ ] Add a separate linting step to check for Android lint warnings in coordinatortablayout/ module
• [ ] Document in README.md that CI checks must pass before PR merge

• Add unit tests for CoordinatorTabLayout.java (currently only an ExampleUnitTest.java stub exists): test setupWithViewPager(), setImageArray() behavior, and tab selection callbacks to cover core functionality.
• Migrate from android.support.v4 to androidx.* dependencies in coordinatortablayout/build.gradle and update imports throughout the library, then test compatibility with modern Android projects.
• Add javadoc comments to public methods in CoordinatorTabLayout.java and listener interfaces (LoadHeaderImagesListener, OnTabSelectedListener) to clarify parameter types, return values, and threading constraints for library users.

The CoordinatorTabLayout project has significant security concerns primarily related to outdated build tools and dependencies. The use of Gradle 3.0.1 (7+ years old), deprecated Bintray infrastructure, and outdated plugin versions poses substantial risks. The JCenter repository shutdown further complicates dependency resolution. While the Android library code itself appears to follow standard practices without obvious code-level vulnerabilities (SQLi, XSS are less applicable to Android UI libraries), the build infrastructure requires immediate attention. Urgent actions: upgrade Gradle to 7.x or 8.x, migrate from JCenter to modern repositories, and update all plugin dependencies to current versions.

• High · Outdated Gradle Build Tools — build.gradle - classpath 'com.android.tools.build:gradle:3.0.1'. The project uses Android Gradle Plugin version 3.0.1, released in October 2017. This version is significantly outdated and contains known security vulnerabilities. Modern versions include critical security patches and improvements. Fix: Update to the latest stable Android Gradle Plugin (currently 8.x). Regularly update build tools to receive security patches and improvements.
• High · Outdated Gradle Dependencies — build.gradle - classpath declarations for bintray, build-info, and android-maven plugins. Multiple Gradle plugin dependencies are severely outdated: gradle-bintray-plugin (1.6 from 2016), build-info-extractor-gradle (4.0.0), and android-maven-gradle-plugin (1.5 from 2016). These contain known vulnerabilities and security issues. Fix: Update or replace deprecated plugins. Consider using modern alternatives: gradle-plugin-publish for Gradle Plugin Portal, or jitpack for dependency distribution. Remove Bintray integration if no longer in use.
• Medium · Deprecated JCenter Repository — build.gradle - repositories { jcenter() }. The project relies on JCenter repository which was shut down by Bintray/JFrog in May 2021. Dependencies may no longer resolve, and using deprecated repositories poses security risks as packages may become unavailable or compromised. Fix: Replace JCenter with Google Maven and Maven Central repositories: google() and mavenCentral()
• Medium · Missing Dependency Version Pinning — build.gradle - dependency declarations. The project does not explicitly specify versions for Android framework dependencies (android-maven-gradle-plugin, gradle-bintray-plugin). This can lead to unpredictable builds with potentially vulnerable transitive dependencies. Fix: Use explicit version constraints for all dependencies. Consider using dependency lock files or Gradle version catalogs to ensure reproducible builds.
• Low · Missing Security Best Practices in Build Configuration — build.gradle and sample/build.gradle. The build.gradle lacks security-focused configurations such as minSdkVersion requirements, ProGuard/R8 configuration verification, and dependency resolution strategies to prevent dependency confusion attacks. Fix: Add explicit minSdkVersion targeting a supported Android version, verify ProGuard rules are properly configured, and implement dependency resolution strategies with preference for RELEASE over SNAPSHOT versions.

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.