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/GrenderG/Toasty 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 4y ago

• 17 active contributors
• LGPL-3.0 licensed
• Tests present
• ⚠ Stale — last commit 4y ago
• ⚠ Concentrated ownership — top contributor handles 65% of recent commits
• ⚠ LGPL-3.0 is copyleft — check downstream compatibility
• ⚠ 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 GrenderG/Toasty repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/GrenderG/Toasty.

What it runs against: a local clone of GrenderG/Toasty — 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 GrenderG/Toasty | Confirms the artifact applies here, not a fork | | 2 | License is still LGPL-3.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 ≤ 1347 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "GrenderG/Toasty(\\.git)?\\b" \\
  && ok "origin remote is GrenderG/Toasty" \\
  || miss "origin remote is not GrenderG/Toasty (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(LGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"LGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is LGPL-3.0" \\
  || miss "license drift — was LGPL-3.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 "toasty/src/main/java/es/dmoral/toasty/Toasty.java" \\
  && ok "toasty/src/main/java/es/dmoral/toasty/Toasty.java" \\
  || miss "missing critical file: toasty/src/main/java/es/dmoral/toasty/Toasty.java"
test -f "toasty/src/main/java/es/dmoral/toasty/ToastyUtils.java" \\
  && ok "toasty/src/main/java/es/dmoral/toasty/ToastyUtils.java" \\
  || miss "missing critical file: toasty/src/main/java/es/dmoral/toasty/ToastyUtils.java"
test -f "toasty/src/main/res/layout/toast_layout.xml" \\
  && ok "toasty/src/main/res/layout/toast_layout.xml" \\
  || miss "missing critical file: toasty/src/main/res/layout/toast_layout.xml"
test -f "toasty/build.gradle" \\
  && ok "toasty/build.gradle" \\
  || miss "missing critical file: toasty/build.gradle"
test -f "app/src/main/java/es/dmoral/toastysample/MainActivity.java" \\
  && ok "app/src/main/java/es/dmoral/toastysample/MainActivity.java" \\
  || miss "missing critical file: app/src/main/java/es/dmoral/toastysample/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 1347 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1317d)"
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/GrenderG/Toasty"
  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).

Toasty is an Android library that extends the native Toast notification system with styled, colored, and icon-enhanced notifications. It wraps Android's Toast API to provide predefined toast types (error, success, info, warning) with consistent theming, custom icons, and configurable typography—all while maintaining a single-line API that returns a Toast object for further customization. Simple single-module library architecture: the toasty/ directory contains the core Toast wrapper (likely es.dmoral.toasty.Toasty main class), a Config singleton for global styling, and type-specific helper methods (error(), success(), info(), warning(), normal(), custom()). The app/ subdirectory is a standalone sample application (AndroidManifest.xml, MainActivity.java, resources) that demonstrates all Toasty features.

Android developers building user-facing applications who need polished, branded toast notifications without manually styling ViewGroups and managing Toast lifecycles. Specifically useful for apps targeting API 14+ that want consistent error/success/warning feedback without Material Design Snackbar overhead.

Production-ready: the library has 5k+ GitHub stars, is distributed via JitPack at version 1.5.2, targets API 14+ for broad compatibility, and is integrated into the example app (app/src/main). However, the Git commit history is not visible in the provided data, so recency cannot be confirmed. The presence of ProGuard rules (app/proguard-rules.pro) and androidx.appcompat dependencies indicates active maintenance.

Low risk for a well-scoped UI library: single-module design (toasty/) with minimal external dependencies (only androidx.appcompat), no visible breaking changes in versioning, and a stable API surface. Risk is mitigated by age and adoption, though single-author maintenance (GrenderG) creates long-term sustainability dependency. No CI/CD pipeline metadata visible in provided files.

No active development signals are visible in the provided file list. Version 1.5.2 is the latest release on JitPack. The app/src/main structure is complete with MainActivity demonstrating all toast types, and ProGuard configuration is present. Without commit logs or issue tracker access, active work status cannot be determined.

Check README for instructions.

Daily commands: Open the project in Android Studio (Android Studio 4.0+, SDK 14+ for runtime). Run ./gradlew installDebug to deploy the app/ sample to an attached device/emulator. Or use Android Studio's Run button after sync. The MainActivity will display interactive toast-generation buttons for each toast type.

• toasty/src/main/java/es/dmoral/toasty/Toasty.java — Core Toast wrapper library implementing the main API surface—all toast creation methods and styling options flow through this class
• toasty/src/main/java/es/dmoral/toasty/ToastyUtils.java — Utility methods for layout inflation and drawable creation—shared helpers used by Toasty to build custom toast views
• toasty/src/main/res/layout/toast_layout.xml — Custom toast layout definition—defines the UI structure and styling applied to all Toasty toast notifications
• toasty/build.gradle — Library module build configuration—defines how the Toasty library is compiled and packaged for distribution
• app/src/main/java/es/dmoral/toastysample/MainActivity.java — Sample app entry point demonstrating all Toasty API methods and use cases for developers
• build.gradle — Root project configuration defining SDK versions, shared dependencies, and build settings across all modules

• Toasty.java (Main Facade) — Exposes static convenience methods (success, error, info, warning,

Add a New Toast Type (e.g., 'debug' toast)

1. Add a new color constant for the debug toast in toasty/src/main/res/values/colors.xml (toasty/src/main/res/values/colors.xml)
2. Create or use an existing icon drawable (e.g., toasty/src/main/res/drawable/ic_debug_white_24dp.xml) (toasty/src/main/res/drawable/ic_debug_white_24dp.xml)
3. Add a public static method debug() in Toasty.java that calls makeText() with the debug color and icon, following the pattern of success(), error(), info() (toasty/src/main/java/es/dmoral/toasty/Toasty.java)
4. Test the new toast type by calling Toasty.debug(context, message).show() from MainActivity.java (app/src/main/java/es/dmoral/toastysample/MainActivity.java)

Customize Toast Appearance Globally

1. Access Toasty.Config.getInstance() in your Application class or early in MainActivity to configure text size, typeface, and other defaults (app/src/main/java/es/dmoral/toastysample/MainActivity.java)
2. Chain Config methods like setTextSize(), setToastTypeface(), setTint() to customize all future toast instances (toasty/src/main/java/es/dmoral/toasty/Toasty.java)
3. Modify toasty/src/main/res/layout/toast_layout.xml if you need to change the underlying layout structure (e.g., add more UI elements) (toasty/src/main/res/layout/toast_layout.xml)

Create a Custom Toast with Your Own Styling

1. Call Toasty.custom(context, message, drawable, tintColor, duration, withIcon, showIcon) or use the makeText() builder pattern (toasty/src/main/java/es/dmoral/toasty/Toasty.java)
2. Provide your own drawable resource (e.g., a custom PNG or VectorDrawable) and tint color (app/src/main/res/drawable/laptop512.png)
3. Call .show() on the returned Toast object to display it (app/src/main/java/es/dmoral/toastysample/MainActivity.java)

Add a Custom Font to Toasts

1. Place your .ttf or .otf font file in app/src/main/assets/ (e.g., app/src/main/assets/MyFont.otf) (app/src/main/assets/PCap Terminal.otf)
2. In MainActivity or Application, call Toasty.Config.getInstance().setToastTypeface(Typeface.createFromAsset(getAssets(), "MyFont.otf")) (app/src/main/java/es/dmoral/toastysample/MainActivity.java)
3. All subsequent toasts will use the custom font (toasty/src/main/java/es/dmoral/toasty/Toasty.java)

• Android Support Library / AndroidX — Provides backwards compatibility for Toast and UI components across API 14+ devices
• Gradle & JitPack Distribution — Enables easy dependency management and distribution of the library via Maven Central / JitPack
• Vector Drawables (VectorDrawable XML) — Provides scalable, size-independent icons for toast notifications across all device densities
• Custom TypeFace loading — Allows developers to apply custom fonts (TTF/OTF) to toast text for branded styling

• Static factory methods (Toasty.success(), error(), etc.) instead of builder pattern for simple cases

  • Why: Reduces boilerplate for 80% of use cases while still offering Config for advanced customization
  • Consequence: Less flexible than a full builder pattern, but significantly simpler API surface

• Global Config singleton for customization instead of per-toast instance styling

  • Why: Reduces memory overhead and ensures consistent styling across the app
  • Consequence: All toasts must share the same typeface and text size; no per-toast overrides without creating custom toasts

• Wraps Android's native Toast class rather than replacing it entirely

  • Why: Leverages system-level toast queue management and avoid reimplementing complex OS-level behavior
  • Consequence: Inherits OS limitations (e.g., toast stacking, system-enforced timeout caps)

• Real-time toast notifications or push integration
• Toast persistence or logging to disk
• Animation customization beyond standard Android Toast behavior
• Multiple simultaneous toasts or custom queue management
• Accessibility features beyond standard Android views
• Support for older Android versions below API 14

No hidden traps are explicitly visible in the provided file list. However: (1) Config is a global Singleton—multiple threads calling Config.getInstance() simultaneously may cause race conditions if not synchronized; (2) Toast queue behavior (allowQueue flag in Config) may need testing on high-frequency toast calls; (3) ProGuard rules must be kept in sync if the toasty/ package structure changes; (4) supportDarkTheme() is mentioned but theme detection logic not shown—verify dark theme colors match your app's theme before release.

• Android Toast API and Looper — Toasty wraps android.widget.Toast which runs on the main/UI thread via Looper; understanding Toast's lifecycle and queue behavior is essential to use allowQueue() and duration settings correctly.
• Singleton Pattern with Configuration — Toasty.Config uses a global singleton to store app-wide toast styling (typeface, text size, gravity, theme); you must call .apply() to commit changes and reset() to clear, a non-obvious requirement.
• Android Resource Drawable Resolution — Toasty loads icon drawables (error/success/info/warning) via Context and applies tintColor via setTint() at runtime; understanding drawable density buckets (hdpi, mdpi, xhdpi) is needed when adding custom icons.
• Method Overloading for API Fluency — Toasty provides six public methods (error/success/info/warning/normal/custom) with multiple overloads to support optional parameters like icons and tint colors without requiring intermediate builders; this reduces boilerplate but increases method count.
• ProGuard/R8 Minification Rules — app/proguard-rules.pro preserves Toasty classes and custom View layouts from obfuscation; missing or incorrect rules break toast rendering in release builds, especially with custom typefaces.
• Android Context and Window Manager — All Toasty methods require a Context parameter to access LayoutInflater, Resources, and the WindowManager for positioning toasts; passing the wrong context (e.g., Application vs Activity) can cause memory leaks or crashes.
• Dark Theme Detection (supportDarkTheme flag) — Toasty.Config.supportDarkTheme() enables adaptive text/icon colors based on system theme; this requires understanding AppCompat's night mode and ThemeOverlay for proper contrast without manual color overrides.

• material-components/material-components-android — Official Material Design component library providing Snackbar as a modern alternative to Toast for in-app messaging, shares similar styling philosophy.
• adrielcafe/AndroidAds — Another lightweight Android UI enhancement library with similar single-module architecture and JitPack distribution pattern.
• chrisbanes/insetter — Companion utility for AndroidX apps that solves display inset challenges (notches, gestures), often used alongside Toast/Snackbar to position overlays correctly.
• square/okhttp — Common dependency in apps using Toasty for displaying network error/success toasts; demonstrates how UI libraries integrate with networking stacks.
• google/material-design-icons — Source of drawable assets (ic_pets_white_48dp.png shown in app/src/main/res/) used by Toasty for built-in toast icons.

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 Toasty core functionality in app/src/androidTest

The repo has a placeholder ExampleInstrumentedTest.java but no actual tests for the Toasty library's core features (success, error, info, warning toast types, custom styling, icon support, gravity settings). This would improve reliability and serve as regression tests for library updates. The test infrastructure (AndroidJUnitRunner) is already configured.

• [ ] Create ToastyInstrumentedTest.java in app/src/androidTest/java/es/dmoral/toastysample/
• [ ] Add tests for each toast type (success, error, info, warning) verifying visibility and text content
• [ ] Add tests for custom duration, gravity, and icon parameters
• [ ] Verify toast dismissal and multiple toast queueing behavior
• [ ] Run tests with ./gradlew connectedAndroidTest to validate

Add GitHub Actions CI/CD workflow for Android builds and tests

The repo lacks automated testing infrastructure. A GitHub Actions workflow would verify builds succeed on every PR, run instrumented tests, and catch regressions early. The gradle structure is already in place with proper SDK version management via rootProject.ext.

• [ ] Create .github/workflows/android-ci.yml
• [ ] Configure workflow to run on push and pull_request events
• [ ] Add steps for: setup Java, cache gradle, build debug APK (./gradlew build), and run instrumented tests
• [ ] Add status badge to README.md showing workflow status
• [ ] Test workflow by pushing to a branch and verifying it runs

Create unit tests for Toasty configuration and utility methods in app/src/test

The repo has ExampleUnitTest.java but no actual unit tests. Unit tests for any configuration methods, color utilities, or helper functions in the toasty library would improve code confidence and serve as documentation. The JUnit 4.12 dependency is already declared.

• [ ] Analyze the toasty library source (referenced in dependencies) to identify public utility/config methods
• [ ] Create ToastyUtilsTest.java in app/src/test/java/es/dmoral/toastysample/
• [ ] Write unit tests covering: color parsing, duration constants, gravity validation, and any builder pattern methods
• [ ] Run tests with ./gradlew test to validate
• [ ] Aim for >80% coverage of public API methods

• Add missing unit tests for Config singleton: create app/src/test/java/es/dmoral/toastysample/ToastyConfigTest.java to verify Config.getInstance(), tintIcon(), setTextSize(), and reset() behavior, since only ExampleInstrumentedTest.java exists and may not cover configuration logic.
• Document RTL layout support: the README mentions setRTL(boolean) but doesn't explain what visual changes occur or provide a before/after screenshot. Add RTL example to MainActivity.java and document in README.
• Add gravity offset validation: implement bounds checking in Config.setGravity() to warn developers if xOffset/yOffset exceed screen bounds, preventing toasts from being invisible on small devices.

The Toasty Android library project has moderate security concerns, primarily related to outdated dependencies (Espresso 3.1.0 and JUnit 4.12) that contain known vulnerabilities. The release build lacks code obfuscation, increasing reverse engineering risk. No hardcoded secrets detected in the provided file structure. The project should prioritize updating dependencies to latest stable versions and enabling ProGuard minification. AndroidManifest.xml details should be reviewed for proper permission and exported component configuration. Overall security posture is acceptable for a sample/demo library but production deployments should address the identified high-severity items.

• High · Outdated Espresso Testing Library — app/build.gradle - androidTestImplementation dependency. The project uses androidx.test.espresso:espresso-core:3.1.0, which is significantly outdated and may contain known security vulnerabilities. Current stable versions are 3.5.x or newer. Fix: Update to the latest stable version of espresso-core (3.5.1 or newer) to patch known vulnerabilities.
• High · Outdated JUnit Dependency — app/build.gradle - testImplementation 'junit:junit:4.12'. JUnit 4.12 is from 2014 and contains known vulnerabilities. Current version is 4.13.2 or newer. Fix: Update to junit:junit:4.13.2 or later to receive security patches.
• Medium · ProGuard Minification Disabled in Release Build — app/build.gradle - release buildType. The release build configuration has 'minifyEnabled false', which means the APK is not obfuscated. This makes reverse engineering easier and exposes implementation details. Fix: Set 'minifyEnabled true' and provide appropriate ProGuard/R8 rules in proguard-rules.pro to obfuscate code.
• Medium · Missing Security Metadata in AndroidManifest — app/src/main/AndroidManifest.xml. Without reviewing the actual AndroidManifest.xml content, common security issues may exist such as missing android:usesCleartextTraffic restriction, exported components without proper protection, or missing permission declarations. Fix: Review manifest for: 1) Set android:usesCleartextTraffic='false' (or handle properly), 2) Ensure exported components have appropriate permission checks, 3) Declare all used permissions explicitly.
• Low · Font File Inclusion Risk — app/src/main/assets/PCap Terminal.otf. Custom font file 'PCap Terminal.otf' is included in assets. While fonts are generally low-risk, any third-party binary should be verified for authenticity. Fix: Verify the font file source and integrity. Consider hosting from trusted sources or verifying checksums.
• Low · Unspecified Dependency Version — app/build.gradle - implementation 'androidx.appcompat:appcompat:$supportLibVersion'. The gradle configuration uses variables like '$supportLibVersion' which are inherited from rootProject.ext. If not properly pinned, this could lead to unexpected version updates. Fix: Review gradle.properties to ensure all version variables are explicitly defined with specific versions (not 'latest' or ranges).

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.