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/commonsguy/cw-omnibus 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
• ⚠ Stale — last commit 7y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 98% of recent commits
• ⚠ No CI workflows detected
• ⚠ 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 commonsguy/cw-omnibus repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/commonsguy/cw-omnibus.

What it runs against: a local clone of commonsguy/cw-omnibus — 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 commonsguy/cw-omnibus | 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 ≤ 2675 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "commonsguy/cw-omnibus(\\.git)?\\b" \\
  && ok "origin remote is commonsguy/cw-omnibus" \\
  || miss "origin remote is not commonsguy/cw-omnibus (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 "ACRA/Simple/app/src/main/java/com/commonsware/android/button/ACRAApplication.java" \\
  && ok "ACRA/Simple/app/src/main/java/com/commonsware/android/button/ACRAApplication.java" \\
  || miss "missing critical file: ACRA/Simple/app/src/main/java/com/commonsware/android/button/ACRAApplication.java"
test -f "ACRA/Simple/app/build.gradle" \\
  && ok "ACRA/Simple/app/build.gradle" \\
  || miss "missing critical file: ACRA/Simple/app/build.gradle"
test -f "ACRA/Simple/app/src/main/AndroidManifest.xml" \\
  && ok "ACRA/Simple/app/src/main/AndroidManifest.xml" \\
  || miss "missing critical file: ACRA/Simple/app/src/main/AndroidManifest.xml"
test -f "ACRA/Simple/app/src/main/java/com/commonsware/android/button/ButtonDemoActivity.java" \\
  && ok "ACRA/Simple/app/src/main/java/com/commonsware/android/button/ButtonDemoActivity.java" \\
  || miss "missing critical file: ACRA/Simple/app/src/main/java/com/commonsware/android/button/ButtonDemoActivity.java"
test -f "ACRA/StrictMode/app/src/main/java/com/commonsware/android/button/ACRAApplication.java" \\
  && ok "ACRA/StrictMode/app/src/main/java/com/commonsware/android/button/ACRAApplication.java" \\
  || miss "missing critical file: ACRA/StrictMode/app/src/main/java/com/commonsware/android/button/ACRAApplication.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 2675 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2645d)"
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/commonsguy/cw-omnibus"
  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).

This is the cw-omnibus repository: a comprehensive collection of hundreds of sample Android applications that demonstrate concepts from Mark Murphy's "The Busy Coder's Guide to Android Development" book. It serves as a living code reference for Android developers, with samples covering everything from basic Activities to advanced crash reporting via ACRA, accessibility, action bars, and beyond—all tagged with git versions corresponding to book releases. Monorepo with topic-based top-level directories (ACRA/, Accessibility/, ActionBar/, etc.), each containing 1–N variant sample apps. Each sample is a self-contained Gradle Android project with standard structure: app/src/main/java/com/commonsware/android/*/ for code, app/src/main/res/ for layouts and resources, app/build.gradle for dependencies, and AndroidManifest.xml for app configuration.

Android developers learning from the Busy Coder's Guide textbook, instructors teaching Android development, and developers seeking well-documented, runnable example code for specific Android APIs and patterns (e.g., crash reporting with ACRA, StrictMode enforcement, accessibility features).

This is a mature, actively maintained educational resource. It has deep history (book has been updated "several times a year"), hundreds of real, complete sample apps, and a clearly structured organization. However, it is not a framework or library—it's reference material, so traditional metrics like test coverage or CI don't apply. Production-ready examples, educational maturity very high.

Low risk for educational use. The repo is maintained by Mark Murphy (high-reputation Stack Overflow contributor), and samples are tied to book versions via git tags. Risk factor: ACRA samples hardcode local URLs like http://10.0.2.2:4567/reports that are emulator-specific; samples target API 27+ (compileSdkVersion 27), which may lag behind current Android versions. No automated tests visible in structure, so examples are validated manually by the author.

The repository is actively maintained in sync with book updates. Samples are versioned with git tags tied to book editions. Recent work includes ACRA crash-reporting samples (Simple, Dialog, Notification variants) and StrictMode monitoring—both targeting modern Android (API 27). No specific PR or issue data is visible, but the structure shows ongoing expansion of sample coverage.

Clone the repo and choose a sample: git clone https://github.com/commonsguy/cw-omnibus.git && cd cw-omnibus/ACRA/Simple. Open in Android Studio (File → Open), or build from command line with local Gradle 3.3+: gradle assembleDebug. Gradle wrapper files are present but you must verify gradle/wrapper/gradle-wrapper.properties for security before importing.

Daily commands: No centralized dev server. Each sample is independent: (1) Open sample folder in Android Studio. (2) Adjust compileSdkVersion and buildToolsVersion in app/build.gradle to your SDK. (3) Run on emulator or device: gradle installDebug then launch app. For ACRA samples, stub_server.rb (Ruby) serves as a mock crash-report endpoint—run it separately: ruby stub_server.rb.

• ACRA/Simple/app/src/main/java/com/commonsware/android/button/ACRAApplication.java — Entry point for ACRA crash reporting initialization; demonstrates library setup that all ACRA samples build upon.
• ACRA/Simple/app/build.gradle — Defines ACRA dependency (5.1.1) and build configuration with crash report endpoint URLs used across samples.
• ACRA/Simple/app/src/main/AndroidManifest.xml — Declares permissions and application class needed for ACRA crash reporting to function.
• ACRA/Simple/app/src/main/java/com/commonsware/android/button/ButtonDemoActivity.java — Primary activity demonstrating how crash reporting integrates with typical Android app lifecycle and UI.
• ACRA/StrictMode/app/src/main/java/com/commonsware/android/button/ACRAApplication.java — Advanced ACRA configuration example showing StrictMode integration for detecting main-thread violations.
• Accessibility/FontScale/app/src/main/java/com/commonsware/android/fontscale/MainActivity.java — Demonstrates accessibility best practices (font scaling) that are foundational to Busy Coder samples.

Create a new ACRA sample variant

1. Create new directory under ACRA/ with structure: ACRA/YourVariant/app/src/main/java/com/commonsware/android/button/ (ACRA/Simple/app/src/main/java/com/commonsware/android/button/ACRAApplication.java)
2. Extend ACRAApplication.java or create new Application subclass with custom ACRA configuration (e.g., different sender strategy) (ACRA/Simple/app/src/main/java/com/commonsware/android/button/ACRAApplication.java)
3. Copy and modify app/build.gradle, updating compileSdkVersion and ACRA configuration options in buildConfigField (ACRA/Simple/app/build.gradle)
4. Create AndroidManifest.xml referencing your custom Application class and required permissions (ACRA/Simple/app/src/main/AndroidManifest.xml)
5. Add demo Activity (e.g., ButtonDemoActivity) with UI that triggers exceptions for testing (ACRA/Simple/app/src/main/java/com/commonsware/android/button/ButtonDemoActivity.java)
6. Add README.markdown documenting the crash reporting behavior your variant demonstrates (ACRA/Simple/README.markdown)

Add a new Accessibility sample

1. Create directory Accessibility/FeatureName/ with gradle structure matching FontScale sample (Accessibility/FontScale/app/src/main/java/com/commonsware/android/fontscale/MainActivity.java)
2. Create MainActivity extending AppCompatActivity that respects system accessibility settings (Accessibility/FontScale/app/src/main/java/com/commonsware/android/fontscale/MainActivity.java)
3. Design layout using scalable dimensions (sp for text, dp for spacing) in activity_main.xml (Accessibility/FontScale/app/src/main/res/layout/activity_main.xml)
4. Update app/build.gradle with minSdkVersion, targetSdkVersion, and accessibility libraries (Accessibility/FontScale/app/build.gradle)

Integrate a new Android API feature into samples

1. Identify related sample directories (e.g., ActionBar, ACRA) and create new subdirectory with feature variant (ActionBar/ActionBarDemoNative/README.markdown)
2. Create Activity class demonstrating the API usage pattern (ActionBar/ActionBarDemoNative/app/src/main/java/com/commonsware/android/button/ButtonDemoActivity.java)
3. Update build.gradle with appropriate SDK targets and feature-specific dependencies (ActionBar/ActionBarDemoNative/app/build.gradle)
4. Add layout XML showcasing the UI elements and configurations (ActionBar/ActionBarDemoNative/app/src/main/res/layout/main.xml)

• ACRA 5.1.1 (ch.acra:acra-http) — Industry-standard Android crash reporting library that simplifies exception collection, device context capture, and HTTP transmission of crash data to backend servers
• Android Gradle Build System — Standard Android development toolchain enabling multi-variant builds, dependency management, and buildConfigField for environment-specific crash reporting URLs
• StrictMode (Android Framework) — Built-in Android diagnostic tool that detects main-thread disk I/O and network calls during development, integrated with ACRA for production monitoring
• Java 1.8 / AndroidX AppCompat — Modern Java language features and backward-compatible UI libraries enable consistent API exposure across Android SDK versions 21-27

• HTTP POST crash reports to hardcoded endpoint (10.0.2.2:4567 for emulator)

  • Why: Simple integration for samples; immediate server feedback without authentication overhead
  • Consequence: Not production-ready: hardcoded localhost, no HTTPS, no retry logic; samples require separate stub server process for testing

• Multiple Application subclass variants (ACRAApplication, ACRADialogApplication, ACRANotificationApplication)

  • Why: Educational: each variant demonstrates different crash-reporting UX strategies (silent, user-feedback dialog, notification)
  • Consequence: Code duplication; real app would use composition or feature flags rather than multiple entry points

• Minimum SDK 21 (Android 5.0) across samples

  • Why: Reduces boilerplate; ACRA and modern libraries drop older API support
  • Consequence: Cannot demonstrate pre-Lollipop compatibility patterns or legacy permission models

• Stub Ruby server (stub_server.rb) for local testing

  • Why: Eliminates dependency on external crash backend during sample development
  • Consequence: Developer must run separate process; doesn't test real backend integration or network resilience

• Does not demonstrate multi-process crash handling or native (C/C++) crash capture
• Does not implement authentication or TLS pinning for crash report transmission
• Does not cover background service crash reporting or system process monitoring
• Not a complete crash analytics dashboard—only server-side report reception
• Does not demonstrate obfuscation mapping or ProGuard symbol file integration

1. Gradle wrapper security: README warns to always verify gradle/wrapper/gradle-wrapper.properties before importing; wrapper JAR not included by design. 2. Emulator-specific URLs: ACRA samples hardcode http://10.0.2.2:4567/reports which only works on Android emulator (maps host localhost); must run stub_server.rb locally or adjust for real devices. 3. SDK versions: compileSdkVersion 27 / buildToolsVersion 27.0.3 are older; you must have these downloaded or adjust values in build.gradle. 4. Gradle 3.3 requirement for CLI builds; wrapper files present but no gradlew script, so local Gradle install required. 5. No centralConfig: each sample has independent build.gradle; changes don't propagate; use find-and-replace if updating all samples.

• ACRA (Application Crash Reporting for Android) — Understanding crash reporting is essential for production Android apps; ACRA is the de facto standard library for capturing, reporting, and debugging uncaught exceptions in the field.
• StrictMode — StrictMode detects performance violations (disk I/O, network on main thread, memory leaks) that degrade user experience; critical for Android optimization.
• Build Variants (debug/release in build.gradle) — Android Gradle allows separate configurations per build type; cw-omnibus uses this to route ACRA reports to different endpoints in debug vs. release, a common pattern for dev/prod separation.
• Application Class Initialization — Custom Application subclasses (ACRAApplication, ACRADialogApplication) run before any Activity; this is where global app state and crash handlers must be configured.
• Gradle Build Configuration (buildConfigField, compileSdkVersion, minSdkVersion) — These fields control API levels, generated constants, and binary compatibility; understanding them is essential to modifying or extending cw-omnibus samples.
• Android Resource Directory Structure (res/layout, res/values, res/drawable-*) — Android's resource system organizes UIs, strings, and assets; cw-omnibus samples demonstrate proper structure for scalability (drawable-hdpi, -ldpi, -mdpi, -xhdpi for different screen densities).

• android/samples — Official Google Android samples; covers similar ground (Activities, Services, etc.) but with Material Design and Jetpack libraries; complements cw-omnibus for modern Android patterns.
• android/architecture-samples — Google's architectural reference implementations (MVVM, MVI, etc.); covers app structure patterns beyond the pedagogical approach in cw-omnibus.
• ACRA/acra — The upstream ACRA crash-reporting library repository; needed to understand the versions and APIs used in cw-omnibus/ACRA samples.
• codepath/android_guides — Community-maintained Android development guides with runnable examples; similar educational role, covers overlapping topics like actionbar and accessibility.

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.

Update compileSdkVersion and targetSdkVersion to API 34+ for ACRA samples

The ACRA/Simple and ACRA/StrictMode samples are using compileSdkVersion 27 and targetSdkVersion 27, which are severely outdated (released in 2017). Modern Android requires targeting API 34+ for Play Store distribution. This is a critical maintenance issue that affects all ACRA example apps and prevents them from being used as reference code for current Android development practices.

• [ ] Update compileSdkVersion from 27 to 34 in ACRA/Simple/app/build.gradle
• [ ] Update targetSdkVersion from 27 to 34 in ACRA/Simple/app/build.gradle
• [ ] Update buildToolsVersion from '27.0.3' to '34.0.0' in ACRA/Simple/app/build.gradle
• [ ] Repeat the same updates for ACRA/StrictMode/app/build.gradle
• [ ] Test both sample apps compile and run without errors
• [ ] Verify ACRA HTTP functionality still works with updated SDK versions

Add README.markdown documentation to ACRA/StrictMode project

The ACRA/Simple project has a README.markdown file explaining its purpose and usage, but ACRA/StrictMode is missing equivalent documentation. This creates an inconsistent contributor experience and makes it unclear what StrictMode variant demonstrates (likely ACRA integration with Android StrictMode policy violations).

• [ ] Create ACRA/StrictMode/README.markdown file
• [ ] Document the purpose: demonstrating ACRA crash reporting with StrictMode enabled
• [ ] Explain how StrictMode differs from the Simple variant (policy violations, threading issues)
• [ ] Include setup instructions referencing the stub_server.rb file
• [ ] Add a note explaining how to run and test the sample with the crash reporter
• [ ] Reference the differences in ACRAApplication.java configuration between Simple and StrictMode variants

Create a root-level README section documenting gradle wrapper and build requirements

The repository uses Gradle wrapper for builds but there's no documentation about build prerequisites, Gradle version requirements, or how to build the samples. With multiple sample projects at different structural levels (ACRA/Simple, ACRA/StrictMode, Accessibility/FontScale), new contributors need clear guidance on prerequisites and build commands specific to this polyrepo structure.

• [ ] Create or update root README.markdown with a 'Building the Samples' section
• [ ] Document minimum Java version requirement (currently implying Java 8+ from compileOptions)
• [ ] Document that Gradle wrapper is included (gradle/wrapper/gradle-wrapper.properties)
• [ ] Add sample build commands for individual projects (e.g., './gradlew -p ACRA/Simple build')
• [ ] Document the Android SDK version requirements aligned with compileSdkVersion across samples
• [ ] Include troubleshooting section for common Gradle issues in multi-module structures

• Add missing unit tests for ACRAApplication.java and ACRADialogApplication.java crash-handling logic; currently no test/ directories visible in ACRA samples.
• Update compileSdkVersion and buildToolsVersion from 27 to 33+ across all samples to align with current Android SDK; this is a straightforward find-replace in ~100 build.gradle files.
• Expand ACRA/StrictMode sample with additional policy configurations (e.g., DiskReadViolation, UntaggedSocketViolation) and document in README.markdown; only basic StrictMode is shown now.

• High · Hardcoded HTTP URL in Build Configuration — ACRA/Simple/app/build.gradle (lines with buildConfigField for ACRA_URL). The build.gradle file contains hardcoded HTTP URLs (http://10.0.2.2:4567/reports) for ACRA crash reporting in both debug and release build types. This URL uses unencrypted HTTP instead of HTTPS, exposing crash reports and potentially sensitive application data in transit. Additionally, the hardcoding of URLs across build types suggests this may be intended for testing but is present in release builds. Fix: 1) Use HTTPS instead of HTTP for the ACRA endpoint. 2) Move hardcoded URLs to secure configuration files outside version control (e.g., gradle.properties, BuildConfig variants). 3) Use different endpoints for debug vs release builds. 4) Consider using environment variables or secure credential management for production endpoints.
• High · ACRA Crash Reporting Enabled in Release Build — ACRA/Simple/app/build.gradle (buildConfigField ACRA_INSTALL in both debug and release). The build configuration enables ACRA crash reporting (ACRA_INSTALL = 'true') in both debug and release builds, with the same endpoint for both. This means production crash reports containing stack traces, user data, and application internals are being sent to a development/testing server at 10.0.2.2:4567, which appears to be a local Android emulator address. This creates a data exposure risk and suggests misconfigured build variants. Fix: 1) Disable ACRA_INSTALL in release builds or use a properly secured, production crash reporting endpoint. 2) Use distinct endpoints for debug and release builds. 3) Ensure release builds point to a legitimate, HTTPS-secured crash reporting service with proper authentication. 4) Review ACRA configuration to minimize sensitive data in crash reports.
• Medium · Unencrypted Network Communication for Sensitive Data — ACRA/Simple/app/build.gradle (dependency: ch.acra:acra-http) and build configuration. The ACRA HTTP library is being used to send crash reports over HTTP to an unencrypted endpoint. Crash reports may contain sensitive information such as stack traces, local file paths, API calls, and user data. Without HTTPS encryption, this data is vulnerable to man-in-the-middle (MITM) attacks on both debug and release builds. Fix: 1) Replace HTTP with HTTPS for all ACRA endpoints. 2) Ensure certificate pinning is implemented to prevent MITM attacks. 3) Consider using ch.acra:acra-http with TLS/SSL configuration. 4) Review what data is being sent in crash reports and exclude sensitive information.
• Medium · Identical Build Configuration Across Debug and Release — ACRA/Simple/app/build.gradle (buildTypes section). The build.gradle file uses identical ACRA configuration (ACRA_URL and ACRA_INSTALL) for both debug and release build types. This is a misconfiguration best practice - release builds should have different, properly secured endpoints while debug builds may use local testing endpoints. The current setup suggests the developer may not have intended this configuration for production releases. Fix: 1) Create distinct configurations for debug and release builds. 2) Use a build variant or flavor-specific approach for different endpoints. 3) Consider using gradle.properties or secure configuration management to externalize these values. 4) Implement proper separation of concerns between development and production environments.
• Low · Multiple ACRA Modules with Unclear Configuration — ACRA/Simple/app/build.gradle (dependencies section). The project includes multiple ACRA modules (acra-http, acra-dialog, acra-notification) without visible configuration management for each. The dialog and notification modules may trigger user-visible prompts during crashes, potentially exposing stack traces to users or allowing unintended data sharing. Fix: 1) Review and explicitly configure each ACRA module to ensure appropriate behavior. 2) Implement ACRA SendPolicy to control when and how crash reports are sent. 3) Document the crash reporting flow and user interaction. 4) Test crash reporting behavior in release builds before deployment.
• Low · Legacy Build System Configuration — ACRA/Simple/project.properties, ACRA. The presence of project.properties and proguard.cfg files alongside modern gradle configuration suggests legacy Android build system artifacts. While not a direct security issue, this indicates the project may have outdated dependencies or build practices that could harbor vulnerabilities. Fix: undefined

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.