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/JakeWharton/ActionBarSherlock 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 10y ago

• 18 active contributors
• Apache-2.0 licensed
• CI configured
• ⚠ Stale — last commit 10y ago
• ⚠ Concentrated ownership — top contributor handles 71% of recent commits
• ⚠ No test directory 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 JakeWharton/ActionBarSherlock repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/JakeWharton/ActionBarSherlock.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "JakeWharton/ActionBarSherlock(\\.git)?\\b" \\
  && ok "origin remote is JakeWharton/ActionBarSherlock" \\
  || miss "origin remote is not JakeWharton/ActionBarSherlock (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 "actionbarsherlock-fest/build.gradle" \\
  && ok "actionbarsherlock-fest/build.gradle" \\
  || miss "missing critical file: actionbarsherlock-fest/build.gradle"
test -f "actionbarsherlock-i18n/build.gradle" \\
  && ok "actionbarsherlock-i18n/build.gradle" \\
  || miss "missing critical file: actionbarsherlock-i18n/build.gradle"
test -f ".travis.yml" \\
  && ok ".travis.yml" \\
  || miss "missing critical file: .travis.yml"
test -f "CHANGELOG.md" \\
  && ok "CHANGELOG.md" \\
  || miss "missing critical file: CHANGELOG.md"

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

ActionBarSherlock is a now-deprecated Android UI library that provided a unified action bar API across Android 2.x through 4.0+. On Android 4.0+ it delegated to the native ActionBar; on older versions it injected a custom Ice Cream Sandwich–based action bar implementation into the activity layout. This solved the critical pre-ICS problem where there was no built-in action bar, forcing developers to either maintain platform-specific code or use fragments only on newer devices. Monorepo structure: core library in actionbarsherlock/ contains the polyfill action bar (Java ~1.5M LOC), actionbarsherlock-i18n/ holds 40+ localized string resources (values-af, values-ar, values-de, etc.), actionbarsherlock-fest/ provides FEST assertion helpers for testing action bar and menu behaviors, and sample apps demonstrate usage. Build uses Gradle and Maven pom.xml files.

Android app developers circa 2011–2014 who needed to support older Android versions (2.1–3.2) while using the modern action bar pattern without code duplication. Also relevant to maintainers of legacy Android codebases still on ActionBarSherlock rather than migrated to AppCompat.

Mature but permanently deprecated as of October 2014. The project is complete and stable (no active development), with a working CI/CD pipeline (.travis.yml present), but the README explicitly directs users to AppCompat. This was intentional—the library accomplished its goal and reached end-of-life as Android's minimum SDK version rose.

High risk for new projects: this library is officially deprecated and unmaintained; Jake Wharton has moved on and no bug fixes or security updates will arrive. Single maintainer (JakeWharton). Dependency on fest-android (1.0.5) is likely stale. Only safe for legacy maintenance—do not use in new apps.

Nothing. This is a closed, archived repository. No active commits, no open PRs, no ongoing development. The CHANGELOG.md and RELEASING.md indicate this was last released around 2012–2013. This is a historical artifact preserved for reference.

Clone with git clone https://github.com/JakeWharton/ActionBarSherlock.git && cd ActionBarSherlock. Build using Gradle: ./gradlew build (gradle wrapper likely present, or gradle build if installed). For Maven users, run mvn clean install. Compiled SDK target is API level 14 (Android 4.0), buildTools 17.0.0 (requires Android SDK setup).

Daily commands: This is a library, not a runnable app. To test: run ./gradlew test or mvn test (Gradle/Maven handle unit tests). To integrate into another project, reference it as a library dependency or publish to local Maven repo via mvn install. Sample demo apps exist but are not listed in the top 60 files; check samples/ or similar if cloned.

• README.md — Clearly marks the library as DEPRECATED and directs users to AppCompat; essential context for any contributor understanding the project's lifecycle.
• actionbarsherlock-fest/build.gradle — Defines the test/assertion helper module's build configuration and dependency on the core actionbarsherlock library; essential for understanding the test infrastructure.
• actionbarsherlock-i18n/build.gradle — Configures the internationalization module with 40+ language resource files; critical for understanding i18n strategy and locale-specific string management.
• .travis.yml — Defines continuous integration pipeline; critical for understanding build validation and release processes.
• CHANGELOG.md — Documents all version history and API changes; essential reference for understanding what changed and when, especially for a deprecated library.
• CONTRIBUTING.md — Outlines contribution guidelines and development workflow; mandatory reading for any developer submitting changes.

• ActionBarSherlock Core Library (Java, Android SDK, custom ActionBar backport) — Provides unified API and version detection logic; delegates to native (API 14+) or custom (API <14) implementation.
  • Failure mode: If version detection fails, app may crash or use incorrect ActionBar implementation on target API level.
• Native ActionBar (API 14+) (Android Framework (android.app.ActionBar)) — Platform-provided action bar used transparently on Android 4.0 and later.
  • Failure mode: None expected; delegated to stable platform API. May behave differently across minor OS versions.
• Custom ActionBar Backport (API <14) (Java, custom Views, Android resource system) — Ice Cream Sandwich-based custom implementation for pre-4.0 devices; handles menu inflation, overflow, and action buttons.
  • Failure mode: Layout inflation errors, menu rendering issues, or performance degradation on lower-end devices.
• i18n Module (Android resources (values-*/strings.xml)) — Provides localized UI strings in 40+ languages; loaded at runtime based on device locale.
  • Failure mode: Missing locale variant falls back to default English; untranslated strings appear in English.
• FEST Test Helpers (Java, FEST Assertions, fest-android) — Fluent assertion library for unit/integration tests; simplifies verification of ActionBar state.
  • Failure mode: Test assertions fail if ActionBar component state does not match expectations; does not affect production code.

• Application Code → ActionBarSherlock API — App calls unified ActionBar methods (e.g., setTitle(), invalidateOptionsMenu()).
• ActionBarSherlock API → Version Detection Layer — Core library checks Build.VERSION to decide routing.
• Version Detection Layer → Native ActionBar or Custom Backport — Conditional delegation: API 14+ → native; API <14 → custom implementation.
• Custom Backport → i18n Resources — Custom ActionBar loads localized strings from device-appropriate locale variant.
• ActionBar Instance → UI Rendering — ActionBar renders menu items, titles, and action buttons on screen.
• Test Code → FEST Assertions — Unit/integration tests use fluent assertions to verify ActionBar

Add a new localized string resource

1. Create or navigate to the locale-specific directory in actionbarsherlock-i18n/res (e.g., values-fr/ for French) (actionbarsherlock-i18n/res/values-*/abs__strings.xml)
2. Add the new string key-value pair following the pattern in abs__strings.xml files (actionbarsherlock-i18n/res/values-en-rGB/abs__strings.xml)
3. Ensure the string ID matches the English default in actionbarsherlock-i18n/res/values/abs__strings.xml (actionbarsherlock-i18n/res/values/abs__strings.xml)

Add a new FEST fluent assertion helper

1. Create a new Assert class in actionbarsherlock-fest/src/main/java/org/fest/assertions/api/com/actionbarsherlock/ matching the ABS component type (actionbarsherlock-fest/src/main/java/org/fest/assertions/api/com/actionbarsherlock/app/ActionBarAssert.java)
2. Extend or implement fluent assertion methods using FEST patterns (e.g., isVisible(), hasTitle()) (actionbarsherlock-fest/src/main/java/org/fest/assertions/api/com/actionbarsherlock/view/MenuItemAssert.java)
3. Update build.gradle to include fest-android dependency if not already present (actionbarsherlock-fest/build.gradle)

Create a release and update changelog

1. Document all changes, fixes, and new features in a new version section (CHANGELOG.md)
2. Reference RELEASING.md for version numbering and release process (RELEASING.md)
3. Ensure .travis.yml CI passes before tagging the release (.travis.yml)

• Android Library Gradle Plugin — Standard toolchain for building Android libraries with multi-module support and resource management.
• FEST Assertions Framework — Provides fluent API for testing Android components with readable, chainable assertion syntax.
• Travis CI — Automated continuous integration to validate builds across commits and pull requests.
• Maven/Gradle Dual Build — Support for both Maven (pom.xml) and Gradle (build.gradle) build systems for broader compatibility.

• Unified API abstracting native vs custom ActionBar implementations

  • Why: Enables single codebase to target Android 2.x–4.0+ without fragmented logic.
  • Consequence: Adds abstraction layer overhead; developers must learn ABS API rather than direct platform API.

• Custom ActionBar backport based on Ice Cream Sandwich sources

  • Why: Ensures UI/UX consistency across Android versions by mimicking native 4.0+ behavior.
  • Consequence: Requires maintenance of custom implementation; risk of API drift if native implementation changes.

• Deprecated in favor of AppCompat

  • Why: AppCompat is now the official, actively maintained backport with Material Design support.
  • Consequence: No new features or bug fixes; existing projects must migrate to AppCompat.

• This library does not support real-time UI updates or data binding.
• Does not handle authentication, networking, or persistence.
• Not designed for Honeycomb (API 11-13) optimization beyond basic backport coverage.
• Does not provide Material Design components—this is a pre-Material Design library.

Build tool version pinning: buildToolsVersion '17.0.0' and compileSdkVersion 14 are ancient; modern Android Studio will need manual override or project migration. Reflection-heavy code: the polyfill uses introspection to detect Android version and dynamically bind to native ActionBar; debugging requires reading bytecode or running with verbose reflection logging. Manifest merging: the custom action bar wrapping modifies activity layouts at runtime, which can conflict with modern AndroidX manifest merging—legacy projects may need ProGuard/R8 rule adjustments. No Gradle plugin update: uses old apply plugin: 'android-library' syntax (pre-3.0 Gradle for Android).

• Polyfill (Android version compatibility layer) — ActionBarSherlock is fundamentally a polyfill—it detects the Android version at runtime and either delegates to native ActionBar (4.0+) or provides a backport. Understanding this pattern is essential for maintaining legacy code.
• Activity wrapping / view injection — On pre-4.0 Android, ActionBarSherlock injects its custom action bar view into the activity's layout tree at runtime—this is a form of composition-over-inheritance that avoids modifying base Activity class.
• Reflection-based API detection — The library uses Java reflection to check for the existence of native ActionBar class and methods at runtime, enabling graceful fallback without runtime errors on old Android versions.
• Android resource qualifiers (localization) — ActionBarSherlock uses 40+ values-xx/ directories for locale-specific strings (values-de, values-ja, etc.)—this is the standard Android i18n pattern still used today.
• Theme inheritance and style overlays — The custom action bar is styled via Android themes and style resources; understanding how ActionBar themes layer on top of base themes is critical for customizing colors and appearance.
• FEST Fluent Assertions for Android Testing — The actionbarsherlock-fest module provides domain-specific assertion methods (e.g., asserting menu item visibility)—this is an early example of fluent testing DSLs in Android, predating modern truth/hamcrest patterns.
• Monorepo with multi-module Gradle/Maven build — ActionBarSherlock is organized as a multi-module project (core library, i18n, FEST assertions, samples)—understanding how to depend on local modules and coordinate releases across them is key to navigating the build.

• androidx/androidx — Modern AppCompat (the official successor) provides the same action bar backport but actively maintained and integrated into Jetpack
• JakeWharton/NineOldAndroids — By the same author; provides animation backports for pre-3.0 Android—often used alongside ActionBarSherlock in legacy apps
• android/platform_frameworks_support — Official Android support library (now AndroidX); represents the ecosystem shift away from third-party backports toward first-party solutions
• JakeWharton/butterknife — Also by Jake Wharton; contemporaneous view binding library often paired with ActionBarSherlock in pre-data-binding era Android development
• android-studio/gradle-plugin — The build system used by this repo; understanding Gradle Android plugin evolution explains why ActionBarSherlock's android-library plugin syntax is outdated

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.

Migrate actionbarsherlock-fest assertions to use modern testing APIs

The actionbarsherlock-fest module provides FEST assertions for ActionBarSherlock components (ActionBarAssert.java, MenuAssert.java, MenuItemAssert.java, ActionModeAssert.java). FEST is deprecated and no longer maintained. This module could be modernized by migrating to Truth (Google's assertion library) or AssertJ, which are actively maintained and more feature-rich. This would make the testing utilities useful for contributors and users still maintaining ActionBarSherlock forks.

• [ ] Review current assertions in actionbarsherlock-fest/src/main/java/org/fest/assertions/api/com/actionbarsherlock/
• [ ] Migrate ActionBarAssert.java to use Truth or AssertJ equivalents
• [ ] Migrate MenuAssert.java, MenuItemAssert.java, ActionModeAssert.java with same pattern
• [ ] Update build.gradle to replace fest-android dependency with truth or assertj-android
• [ ] Add tests demonstrating the new assertions work correctly

Add comprehensive internationalization validation tests for actionbarsherlock-i18n

The actionbarsherlock-i18n module contains string translations for 30+ locales (af, am, ar, be, bg, ca, cs, da, de, el, en-rGB, es, es-rUS, et, fa, fi, fr, he, hi, hr, hu, in, it, etc.), but there are no visible tests validating that: (1) all translations have the same keys, (2) no translations are missing across locales, (3) string formatting placeholders match the base language. This PR would add lint/validation tests to catch translation regressions.

• [ ] Create actionbarsherlock-i18n/src/test/java/com/actionbarsherlock/i18n/TranslationValidationTest.java
• [ ] Parse all values-*/abs__strings.xml files and extract key sets
• [ ] Assert all locales contain identical key sets to values/abs__strings.xml
• [ ] Validate string formatting placeholders (%s, %d, etc.) match across locales
• [ ] Add test to detect missing or extraneous translation files

Add GitHub Actions CI workflow to validate deprecation status and prevent accidental regressions

The README clearly marks ActionBarSherlock as DEPRECATED with no further development planned. However, there's no automated CI (see .travis.yml is present but GitHub Actions is standard now). A minimal GitHub Actions workflow should: (1) validate the DEPRECATED notice is present in README, (2) run basic lint checks on i18n XML files, (3) verify Gradle builds without errors. This prevents accidental commits that might contradict the deprecation status or break the build for users maintaining forks.

• [ ] Create .github/workflows/validate-deprecated.yml
• [ ] Add step to grep for 'DEPRECATED' in README.md and fail if missing
• [ ] Add step to validate all actionbarsherlock-i18n/res/values-*/abs__strings.xml files are well-formed
• [ ] Add step to run 'gradle build' for both main library and test modules
• [ ] Document in CONTRIBUTING.md that CI must pass before PRs are merged

• Add missing unit tests for the version detection logic in ActionBarSherlock.java or equivalent—currently no dedicated test files visible in the top 60, suggesting core polyfill logic lacks direct JVM-side tests.
• Expand localization coverage: check which major locales are missing from actionbarsherlock-i18n/res/values-xx/ (e.g., values-ja, values-ko, values-ru, values-zh) and add translation keys from abs__strings.xml.
• Document the reflection hooks and version-gating strategy in a ARCHITECTURE.md file—the polyfill's core mechanism (how it detects 4.0+ vs. older and swaps implementations) is not explained anywhere.

The ActionBarSherlock codebase presents significant security concerns due to its deprecated status and extremely outdated dependencies. The project is no longer maintained, meaning it will not receive security patches for vulnerabilities. The build configuration targets very old Android API levels (14) and uses build tools from 2013, missing all modern security features and hardening mechanisms introduced in recent Android versions. The transitive dependencies are also outdated and unmaintained. This project should not be used in production. Immediate migration to actively maintained alternatives (AppCompat/AndroidX) is strongly recommended.

• High · Deprecated Project - No Active Maintenance — README.md, project root. ActionBarSherlock is explicitly marked as deprecated with no further development. This means no security patches, bug fixes, or vulnerability updates will be released. Using deprecated libraries exposes the application to known and unknown vulnerabilities. Fix: Migrate to AppCompat v7 or AndroidX AppCompat library, which are actively maintained and receive security updates. These libraries provide the same functionality with modern API levels support.
• High · Outdated Build Tools and Target SDK — actionbarsherlock-fest/build.gradle. The build configuration uses compileSdkVersion 14 and buildToolsVersion 17.0.0, which are extremely outdated (from 2012-2013 era). This means missing modern security features, permission models, and security hardening available in recent Android versions. Fix: Update compileSdkVersion to at least 33+ and buildToolsVersion to latest available (34.0.0+). Update targetSdkVersion to meet current Google Play Store requirements (currently 34+).
• Medium · Potentially Outdated Transitive Dependencies — actionbarsherlock-fest/build.gradle. The dependency 'com.squareup:fest-android:1.0.5' is from 2013-2014 era. FEST (Fluent Easy STesting) is no longer actively maintained. While this is a test/assertion library, outdated testing dependencies may contain vulnerabilities or compatibility issues. Fix: Replace FEST with modern assertion libraries like AssertJ, Truth, or Hamcrest. Update dependency versions to current releases and verify compatibility with modern Android testing frameworks.
• Medium · Missing Gradle Dependency Configuration Best Practices — actionbarsherlock-fest/build.gradle. The build.gradle file does not specify explicit versions for the gradle plugin itself or use dependency constraints. This can lead to non-reproducible builds and potential inclusion of vulnerable transitive dependencies. Fix: Specify explicit gradle plugin version (classpath 'com.android.tools.build:gradle:X.X.X'), use gradle-wrapper.properties for reproducibility, and consider implementing dependency constraints or bill of materials (BOM) for transitive dependency management.
• Low · Missing Security-Related Gradle Properties — actionbarsherlock-fest/build.gradle. The build configuration lacks security-focused settings such as lint security checks, ProGuard/R8 configuration for code obfuscation, and manifest hardening options. Fix: Add lint checks configuration to enable security linting, configure R8/ProGuard for release builds, implement manifest hardening (e.g., android:usesCleartextTraffic='false'), and enable other relevant security configurations.

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.