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/xxv/android-lifecycle 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 — Stale and unlicensed — last commit 5y ago

• 2 active contributors
• Tests present
• ⚠ Stale — last commit 5y ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 93% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ 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 xxv/android-lifecycle repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/xxv/android-lifecycle.

What it runs against: a local clone of xxv/android-lifecycle — 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 xxv/android-lifecycle | Confirms the artifact applies here, not a fork | | 2 | Default branch main exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 1753 days ago | Catches sudden abandonment since generation |

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

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

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "complete_android_fragment_lifecycle.svg" \\
  && ok "complete_android_fragment_lifecycle.svg" \\
  || miss "missing critical file: complete_android_fragment_lifecycle.svg"
test -f "android-lifecycle-activity-to-fragments.svg" \\
  && ok "android-lifecycle-activity-to-fragments.svg" \\
  || miss "missing critical file: android-lifecycle-activity-to-fragments.svg"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/MainActivity.java" \\
  && ok "tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/MainActivity.java" \\
  || miss "missing critical file: tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/MainActivity.java"
test -f "tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/TestFragment.java" \\
  && ok "tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/TestFragment.java" \\
  || miss "missing critical file: tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/TestFragment.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 1753 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1723d)"
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/xxv/android-lifecycle"
  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).

A comprehensive visual documentation project that maps the complete Android Activity and Fragment lifecycle events in sequence, showing how fragments interact with activities over time. It provides printable diagrams (SVG, PDF, PNG) and includes a reference Android app (LifecycleLog) that logs lifecycle callbacks in real-time to help developers understand the exact order of callback execution. Hybrid structure: root contains canonical Dia diagram files and exported vector/raster images (complete_android_fragment_lifecycle., android-lifecycle-activity-to-fragments.). tools/LifecycleLog/ is a standalone Android app demonstrating lifecycle with Java callback logging; app/src/main/java/com/example/lifecyclelog/ contains MainActivity, MainFragmentActivity, TestFragment, TestCompatFragment, and Util for real-time lifecycle event visualization.

Android developers building apps with Fragments who need to understand the precise sequencing of lifecycle callbacks (onCreate, onStart, onResume, etc.) across both Activities and Fragments. Specifically useful for developers struggling with Fragment transaction timing, state management, and avoiding lifecycle-related bugs.

Mature and stable reference material. The diagrams are well-established (canonical format in Dia, exported to multiple formats), and the supporting LifecycleLog app targets Android SDK 19 with support-v4 library. No recent commits visible in provided data, suggesting the project is feature-complete but not actively maintained—standard for reference documentation.

Low risk for a reference documentation repo. Single dependency on support-v4:20.+ (fairly stable library). Primary risk is Android API evolution—if Google significantly changes lifecycle behavior in newer Android versions (API 21+), diagrams may become outdated. No CI/testing infrastructure visible. Maintainer responsiveness unknown.

No active development visible from provided data. This is a static reference resource—the diagrams are complete, and the LifecycleLog tool is feature-complete. Updates would typically be triggered by major Android OS changes or diagram corrections via pull requests (maintainer mentions pull requests in README).

Clone the repo: git clone https://github.com/xxv/android-lifecycle.git. Open complete_android_fragment_lifecycle.svg or .pdf in a viewer for the diagrams. To build/run the LifecycleLog demo app: cd tools/LifecycleLog && ./gradlew build && ./gradlew installDebug (requires Android SDK).

Daily commands: Navigate to tools/LifecycleLog and run ./gradlew build to compile, or ./gradlew installDebug to deploy to connected emulator/device. Launch MainActivity or MainFragmentActivity to see lifecycle callbacks logged to logcat via the Util logging helper.

• complete_android_fragment_lifecycle.svg — Primary reference diagram showing complete Activity and Fragment lifecycle states and transitions in time-ordered vertical layout
• android-lifecycle-activity-to-fragments.svg — Integration diagram showing how FragmentManager coordinates Activity and Fragment lifecycles together
• README.md — Explains the diagram's purpose and usage; clarifies that lifecycle stages occur in vertical order across both Activities and Fragments
• tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/MainActivity.java — Practical reference implementation demonstrating Activity lifecycle callbacks and logging for verification
• tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/TestFragment.java — Practical reference implementation demonstrating Fragment lifecycle callbacks and their interaction with Activity
• tools/LifecycleLog/app/build.gradle — Defines project dependencies and Android SDK versions used for the lifecycle reference app

• Activity (Android Framework (android.app.Activity)) — Container for Fragments; drives overall application lifecycle and responds to system events
  • Failure mode: If onCreate() or onResume() not implemented, app crashes or UI does not display
• FragmentManager (Android Framework or Support Library (android.app.FragmentManager / androidx.fragment.app.FragmentManager)) — Maintains Fragment backstack and ensures Fragments transition through states synchronized with parent Activity
  • Failure mode: If fragments are added/removed out of order or during invalid states, IllegalStateException or lifecycle mismatch occurs
• Fragment (Android Framework (android.app.Fragment) or Support Library) — Lightweight UI component managed by Activity; has its own lifecycle parallel to Activity's
  • Failure mode: If callbacks reference destroyed Activity, NullPointerException or IllegalStateException can occur
• Lifecycle Diagram — Educational reference showing temporal order and interleaving of Activity and Fragment callbacks

Update Lifecycle Diagram with New State/Transition

1. Open the editable source file in Dia (complete_android_fragment_lifecycle.dia)
2. Add or modify state boxes and transition arrows to reflect new lifecycle behavior (complete_android_fragment_lifecycle.dia)
3. Export updated diagram to SVG format (complete_android_fragment_lifecycle.svg)
4. Export to PNG for GitHub preview and PDF for printing (complete_android_fragment_lifecycle.png)
5. Update README.md with any notes about the changed lifecycle behavior (README.md)

Add New Lifecycle Callback Test to Reference App

1. Extend MainActivity or MainFragmentActivity with override of new lifecycle callback (e.g. onPause, onDestroy) (tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/MainActivity.java)
2. Use Util.log() to output callback name and timestamp to verify order matches diagram (tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/Util.java)
3. Add corresponding Fragment callback in TestFragment.java (tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/TestFragment.java)
4. Run the app on an Android 4.0+ device (API 14+) and observe log output to verify ordering (tools/LifecycleLog/app/src/main/AndroidManifest.xml)

Update Support Library Version and Test Compatibility

1. Update the Support Library v4 dependency version in app-level Gradle (tools/LifecycleLog/app/build.gradle)
2. Test with both TestFragment (native) and TestCompatFragment (support library) (tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/TestCompatFragment.java)
3. Verify callback order in MainFragmentActivity when both fragment types are used (tools/LifecycleLog/app/src/main/java/com/example/lifecyclelog/MainFragmentActivity.java)
4. Update README with any behavior changes or compatibility notes (README.md)

• Dia (diagram editor) — Produces editable vector diagrams that export to SVG, PDF, and PNG without quality loss; enables version control of diagram source
• Android Support Library v4 — Provides backward-compatible Fragment API for Android 2.2+ (API 8+), essential for demonstrating unified lifecycle across OS versions
• Android SDK 19 (KitKat) as compile target — Balance between modern APIs and broad device coverage; Fragment lifecycle was stable by this point
• Gradle build system — Standard modern Android build tool; enables reproducible builds and dependency management

• Reference app includes only core lifecycle callbacks, not edge cases

  • Why: Simplicity and clarity—focus on the happy path to match the diagram
  • Consequence: Developers must infer behavior for advanced scenarios (e.g., fragment backstack, state retention); pull requests encouraged for improvements

• Diagram is time-ordered vertical layout showing both Activity and Fragment in parallel

  • Why: Makes it visually obvious which callbacks happen in which order and how they interleave
  • Consequence: Less ideal for showing state machine transitions; readers must follow vertical progression carefully

• Repository is primarily documentation, not a reusable library

  • Why: Goal is education and reference, not production code
  • Consequence: No version guarantees; diagram may not reflect the latest Android versions without community updates

• Does not provide runnable lifecycle tracing or instrumentation—only static diagrams and a logging reference app
• Does not cover modern Lifecycle architecture components (androidx.lifecycle.*) introduced after API 26
• Does not address configuration changes, process death/restoration, or saved instance state persistence details
• Does not provide interactive or animated lifecycle visualizations
• Not a real-time debugger or profiling tool

LifecycleLog app targets Android 4.4 (API 19) but has minSdkVersion 8—ensure you're testing on compatible devices or emulators. Dia diagram editing requires Dia editor installed locally if you want to modify diagrams; the export-to-SVG-then-hand-tweak workflow (per README) is manual and error-prone. Logcat output from LifecycleLog may be noisy if other apps are running; filter by package name com.example.lifecyclelog or tag name used in Util.java.

• Activity Lifecycle States — Understanding onCreate → onStart → onResume → onPause → onStop → onDestroy transitions is fundamental to preventing memory leaks, losing unsaved data, and resource conflicts in Android apps
• Fragment Lifecycle States — Fragments have additional states (onAttach, onCreateView, onViewCreated) between Activity callbacks; misunderstanding Fragment lifecycle causes null pointer exceptions and UI state bugs
• Fragment Transactions and BackStack — Fragment add/replace/remove operations trigger different lifecycle callback sequences; understanding the backstack helps avoid 'blank screen' bugs when fragments are destroyed unexpectedly
• Configuration Changes and State Restoration — Lifecycle callbacks repeat on orientation changes and other config changes; savedInstanceState is the mechanism to preserve UI state across these lifecycle restarts
• Support Library Compatibility (v4 Fragments) — support-v4 Fragment implementation has subtle lifecycle differences from native Fragments; this repo includes TestCompatFragment to show those differences explicitly
• Fragment ViewLifecycle vs Fragment Lifecycle — Modern Fragments have separate view lifecycle (onCreateView/onDestroyView) that doesn't align 1:1 with Fragment lifecycle; this prevents accessing view after fragments are hidden but not destroyed

• android/architecture-samples — Official Google Android architecture patterns repo; shows how to use lifecycle-aware components correctly in modern apps
• android/sunflower — Google's sample Android app demonstrating Jetpack libraries including Lifecycle; complements this repo with modern lifecycle usage patterns
• square/leakcanary — Memory leak detection tool for Android; helps debug lifecycle-related memory leaks caused by incorrect callback handling
• google/android-architecture-components — Predecessor/companion repo showing lifecycle-aware architecture components that build on the fundamental lifecycle concepts shown here
• android/platform_frameworks_base — Android source code repository; contains the actual Framework implementation of Activity and Fragment lifecycle methods

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 LifecycleLog tool to target modern Android API levels

The LifecycleLog tool in tools/LifecycleLog is targeting compileSdkVersion 19 and buildToolsVersion 20.0.0 (from 2014). This is critically outdated and won't compile with modern Android toolchains. Updating it to a modern API level (33+) will make it a useful reference tool for contributors to verify lifecycle behavior on current Android versions and ensure the diagrams remain accurate.

• [ ] Update build.gradle: Change compileSdkVersion from 19 to 33+, buildToolsVersion to latest stable (34.0.0+)
• [ ] Update targetSdkVersion from 19 to 33+, minSdkVersion to 21+ (to avoid deprecated APIs)
• [ ] Update support-v4 dependency to androidx equivalents (androidx.fragment:fragment:1.6.0+, androidx.appcompat:appcompat:1.6.0+)
• [ ] Update AndroidManifest.xml to remove deprecated attributes and add required Android 12+ permissions if needed
• [ ] Test compilation and verify MainActivity, MainFragmentActivity, TestFragment, and TestCompatFragment run without errors
• [ ] Update README.md to mention this tool can be used to verify lifecycle behavior on modern Android

Add lifecycle diagrams for Jetpack Compose Navigation lifecycle integration

The repository currently documents Activity/Fragment lifecycles thoroughly, but Jetpack Compose has fundamentally different lifecycle behavior (no FragmentManager, composable recomposition lifecycle). A new diagram showing how Compose Navigation integrates with Activity lifecycle would be valuable for modern Android development. This should be a .dia (Dia) file that matches the existing diagram style.

• [ ] Research Compose Navigation lifecycle: when composables are created, recomposed, and disposed relative to Activity onCreate/onStart/onResume
• [ ] Create new complete_android_compose_navigation_lifecycle.dia documenting parallel lifecycles of Activity and Compose Navigation
• [ ] Export to PNG, SVG, and PDF formats matching the existing diagram naming convention
• [ ] Add reference and brief explanation to README.md linking to the new diagram
• [ ] Optionally extend LifecycleLog tool to include a ComposableTestScreen.kt that logs Compose lifecycle events

Add automated tests to LifecycleLog to capture and verify lifecycle call sequences

The LifecycleLog tool logs lifecycle events to the console but has no automated tests verifying the sequence is correct. Adding instrumented tests (AndroidJUnit4) that programmatically trigger lifecycle transitions and assert the correct callback order would ensure the diagrams remain accurate as Android versions evolve and serve as a reference test suite.

• [ ] Create tools/LifecycleLog/app/src/androidTest/java/com/example/lifecyclelog/ActivityLifecycleTest.java with @RunWith(AndroidJUnit4.class) tests
• [ ] Add test cases: testActivityCreationSequence(), testFragmentAdditionSequence(), testActivityDestructionSequence()
• [ ] Use ActivityScenario API to trigger lifecycle transitions and collect lifecycle callbacks via a mock/spy observer
• [ ] Assert callback order matches the documented diagrams (e.g., onCreate -> onStart -> onResume)
• [ ] Add tools/LifecycleLog/build.gradle dependencies: androidx.test:rules:1.5.0+, androidx.test.ext:junit:1.1.5+
• [ ] Update README.md with instructions: 'Run tests with: ./gradlew connectedAndroidTest' to verify lifecycle behavior

• Add lifecycle diagrams for Android Jetpack Compose and modern ViewModel/LiveData patterns—current diagrams only show Activity/Fragment callbacks and don't cover modern MVVM lifecycle awareness
• Create unit tests for LifecycleLog app's Util.java logging helper to ensure callback order assertions are correct across different Fragment transaction types (add, replace, remove)
• Document the exact differences between native Fragment lifecycle and support-v4 Fragment lifecycle in a new markdown file with concrete callback order examples extracted from logcat

This is a demonstration/educational project about Android lifecycle with significant security concerns. The codebase uses extremely outdated dependencies and SDK versions from 2013-2014, lacks code obfuscation, and does not meet modern Android security standards. While the project itself is a diagram/documentation repository with minimal attack surface, the sample LifecycleLog application should not be used as a production template. Critical updates needed: upgrade to modern Android SDK versions, migrate from deprecated support libraries to AndroidX, enable ProGuard/R8 minification, and increase minimum SDK version.

• High · Outdated Android SDK and Build Tools — tools/LifecycleLog/app/build.gradle. The project uses compileSdkVersion 19 and buildToolsVersion 20.0.0, which are extremely outdated (from 2013-2014). This means the application is missing security patches, modern security features, and vulnerability fixes that have been introduced in newer Android versions. Fix: Update compileSdkVersion to at least 33-34 (or latest stable), buildToolsVersion to match, and targetSdkVersion to the latest available. Ensure compatibility with modern Android security requirements.
• High · Outdated Support Library Dependency — tools/LifecycleLog/app/build.gradle. The dependency on 'com.android.support:support-v4:20.+' is from 2014 and is no longer maintained. The entire android.support library is deprecated in favor of AndroidX. This dependency likely contains known security vulnerabilities. Fix: Migrate to AndroidX libraries (androidx.appcompat:appcompat and androidx.fragment:fragment). Replace support-v4 with appropriate AndroidX equivalents and ensure all dependencies are up-to-date.
• Medium · ProGuard Obfuscation Disabled in Release Builds — tools/LifecycleLog/app/build.gradle. The release build configuration has 'runProguard false', which means code obfuscation and optimization are disabled. This makes the compiled APK easier to reverse-engineer and analyze for potential vulnerabilities. Fix: Set 'runProguard true' (or use minifyEnabled true for newer Gradle versions) and ensure appropriate ProGuard/R8 rules are configured to obfuscate and optimize release builds.
• Medium · Low Minimum SDK Version — tools/LifecycleLog/app/build.gradle. minSdkVersion is set to 8, which corresponds to Android 2.2 (Froyo, released 2010). Supporting such old API levels means the application cannot leverage modern security features and is forced to use deprecated, potentially vulnerable APIs. Fix: Increase minSdkVersion to at least 21 (Android 5.0) or higher. This allows use of modern security features like runtime permissions, hardware-backed keystore, and secure crypto APIs.

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.