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/nisrulz/android-tips-tricks 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 — Slowing — last commit 11mo ago

• Last commit 11mo ago
• 6 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Slowing — last commit 11mo ago
• ⚠ Single-maintainer risk — top contributor 94% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live nisrulz/android-tips-tricks repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/nisrulz/android-tips-tricks.

What it runs against: a local clone of nisrulz/android-tips-tricks — 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 nisrulz/android-tips-tricks | 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 ≤ 364 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "nisrulz/android-tips-tricks(\\.git)?\\b" \\
  && ok "origin remote is nisrulz/android-tips-tricks" \\
  || miss "origin remote is not nisrulz/android-tips-tricks (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 "src/SUMMARY.md" \\
  && ok "src/SUMMARY.md" \\
  || miss "missing critical file: src/SUMMARY.md"
test -f "book.toml" \\
  && ok "book.toml" \\
  || miss "missing critical file: book.toml"
test -f "src/introduction.md" \\
  && ok "src/introduction.md" \\
  || miss "missing critical file: src/introduction.md"
test -f "code-files/Logger.java" \\
  && ok "code-files/Logger.java" \\
  || miss "missing critical file: code-files/Logger.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 364 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~334d)"
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/nisrulz/android-tips-tricks"
  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 curated cheatsheet/knowledge base documenting Android development tips, tricks, and best practices compiled as a searchable mdBook. It aggregates productivity hacks for Android Studio, ADB workflows, Gradle optimization, and common pitfalls—published as a static HTML book at nisrulz.com/android-tips-tricks rather than a runnable codebase. Flat mdBook structure: src/SUMMARY.md indexes all chapters (adb-shell.md, gradle-groovy-script-tips.md, helper-tools.md, etc.), src/img/ contains reference screenshots, code-files/ holds reusable snippets (Logger.java, gradle configs), and book.toml configures the mdBook build. No monorepo; single source of truth is markdown files compiled to HTML.

Android developers (junior to mid-level) seeking quick reference guides on Android Studio keyboard shortcuts, ADB shell commands, Gradle/Kotlin DSL tricks, debugging techniques, and ProGuard/build optimization—developers who want battle-tested workflows rather than learning from scratch.

Actively maintained and well-established: featured in Android Weekly #221 and Awesome Android Newsletter. Repo shows steady documentation updates in src/*.md files and uses mdBook (Rust-based, stable). No evidence of abandonment, but this is a reference guide rather than a code library, so 'mature' means complete coverage of documented topics rather than semantic versioning.

Minimal risk—this is a documentation/cheatsheet repo, not a dependency library. Single maintainer (nisrulz) is the core risk; content can become stale if Android tooling changes (e.g., Android Studio shortcuts, ADB behavior). No automated tests or CI pipeline visible (deploy-to-github-pages.sh is manual). Contributions welcome but review depends on maintainer availability.

Actively accepting contributions via PRs; the repo is used as a living document. Recent work likely includes Android Studio tips updates and Gradle best-practices refinement based on community feedback. No specific open issues or milestones visible in provided data, but deployment script suggests periodic publishing cycles.

Clone and build the book locally: git clone https://github.com/nisrulz/android-tips-tricks.git && cd android-tips-tricks && mdbook serve --open. Requires mdBook installed (Rust-based); no npm or gradle needed. To publish: run ./deploy-to-github-pages.sh.

Daily commands: Run mdbook serve --open to start a local dev server (default: http://localhost:3000) with hot-reload. Run mdbook build to generate static HTML in the book/ directory. Deploy via ./deploy-to-github-pages.sh (requires git and GitHub Pages setup).

• Readme.md — Entry point and overview of all tips, tricks, and learning resources for Android development—every contributor must understand the scope and structure.
• src/SUMMARY.md — Table of contents that defines the book structure and organization of all documentation chapters—essential for navigation and adding new sections.
• book.toml — mdBook configuration file that controls the build, theme, and output format of the entire cheatsheet—critical for deployment and formatting.
• src/introduction.md — Introduction chapter that frames the purpose and audience of the cheatsheet—sets expectations for all subsequent content.
• code-files/Logger.java — Core Java utility code example demonstrating best practices—referenced by contributors as a pattern for inline code samples.
• deploy-to-github-pages.sh — Deployment script that builds and publishes the cheatsheet to GitHub Pages—essential for CI/CD pipeline and release workflow.
• code-files/mavencentral_push.gradle — Gradle configuration example for publishing to Maven Central—key reference file for the Gradle tips section.

• Markdown Content Files (Markdown, Git) — Store tips, tricks, examples, and learning resources as human-readable, version-controlled documentation.
  • Failure mode: Syntax errors or broken links prevent mdBook from building; contributors may not realize the issue until deployment.
• SUMMARY.md Navigation (Markdown metadata) — Define the hierarchical structure and chapter ordering for the book.
  • Failure mode: Incorrect or missing entries cause broken navigation or missing chapters in the final site.
• book.toml Configuration (TOML) — Configure mdBook build parameters, theme, output format, and preprocessing rules.
  • Failure mode: Invalid configuration prevents the build from completing or causes incorrect rendering.
• Deployment Script (Bash, Git, mdBook CLI) — Automate building and publishing the site to GitHub Pages.
  • Failure mode: Script errors or Git auth issues prevent deployment; manual recovery required.
• Code Examples (Java, Gradle, Groovy, Kotlin) — Provide working Java and Gradle code snippets referenced in documentation.
  • Failure mode: Outdated or broken examples mislead users; difficult to detect without syntax checking.
• Visual Assets (PNG, JPEG, GIF images) — Supply screenshots, diagrams, and GIFs to illustrate concepts and workflows.
  • Failure mode: Missing or broken image links create poor user experience; no alt text reduces accessibility.

• Developer → Git Repository — Contributor writes markdown, code examples, and commits changes to GitHub.
• Git Repository → Deploy Script — deploy-to-github-pages.sh checks out latest content and triggers the build process

Add a New Tips Category

1. Create a new markdown file in src/ directory with your topic name (e.g., src/my-new-tips.md) (src/my-new-tips.md)
2. Add an entry to src/SUMMARY.md under the appropriate section or create a new section heading (src/SUMMARY.md)
3. Write the tips content in markdown format following the existing style and structure (src/my-new-tips.md)
4. If adding images, place them in src/img/ and reference them in the markdown (src/img/)
5. Run deploy-to-github-pages.sh to build and verify the documentation renders correctly (deploy-to-github-pages.sh)

Add a Code Example

1. Create a new Java or Gradle file in code-files/ directory with your example (e.g., code-files/MyExample.java) (code-files/MyExample.java)
2. Reference the code file in the relevant markdown file using inline code blocks or links (src/android-examples.md)
3. Add explanation and context around the example in the markdown file (src/android-examples.md)

Add Learning Resources or External Links

1. Update the learning-resources.md file with new blogs, courses, videos, or podcasts (src/learning-resources.md)
2. Alternatively, add podcast links to podcasts.md if the resource is audio content (src/podcasts.md)
3. Organize resources by category and provide a brief description of each (src/learning-resources.md)

• mdBook — Lightweight static site generator for documentation with built-in search, theming, and GitHub Pages integration—perfect for a collaborative cheatsheet.
• Markdown — Human-readable, version-control-friendly format that enables easy contribution and collaborative editing via GitHub.
• Bash deployment script — Simple automation for building and deploying to GitHub Pages without requiring external CI/CD services.
• GitHub Pages — Free, integrated hosting for static sites directly from the repository—eliminates infrastructure overhead.

• Static documentation over interactive platform

  • Why: Reduces complexity and deployment cost
  • Consequence: Cannot dynamically filter or personalize content, but gains simplicity and discoverability via search.

• Markdown over database-backed CMS

  • Why: Enable contributions via pull requests and version control
  • Consequence: Limited rich media support and no server-side rendering, but maximum community contribution friction is low.

• Manual organization in SUMMARY.md over auto-generated navigation

  • Why: Explicit control over chapter ordering and structure
  • Consequence: Requires manual updates when adding chapters, but prevents accidentally breaking navigation.

• Real-time collaboration or editing
• Backend API or dynamic content serving
• User authentication or access control
• Interactive code execution or sandboxing
• Mobile app or native client
• Persistent storage of user progress or bookmarks

1. mdBook must be installed separately (cargo install mdbook); no npm/gradle fetch. 2. GitHub Pages deployment assumes ownership of the repo and push access; deploy script modifies git history. 3. Image paths in markdown are relative (src/img/); move files and paths break. 4. No build validation or link checking—broken internal markdown links won't surface until manual review. 5. Shell script (deploy-to-github-pages.sh) is hardcoded for nisrulz/android-tips-tricks repo name; forks need modification.

• mdBook static site generation — Understanding how markdown compiles to HTML and how book.toml controls themes and output is essential for maintaining and extending this documentation site
• Android activity lifecycle state diagrams — Referenced in src/img/activityStateDiagram.jpeg; grasping onCreate/onStart/onResume transitions is fundamental to understanding the tips about memory leaks and resource cleanup in this cheatsheet
• Gradle build system (Groovy vs. Kotlin DSL) — Two entire chapters (gradle-groovy-script-tips.md, gradle-kotlin-script-tips.md) dedicate to Gradle optimization; understanding task configuration and dependency resolution is key to applying these tips
• ADB (Android Debug Bridge) shell commands — adb-shell.md is a core reference; mastering ADB workflows (logcat filtering, device control, permission simulation) directly accelerates development velocity covered in this cheatsheet
• ProGuard/R8 code obfuscation and optimization — Multiple references to ProGuard rules (src/img/proguard_rules_apk_analyzer.gif, src/img/extract_native_libs.jpg); understanding minification configuration and APK analysis prevents runtime crashes in production
• Android manifest merging and variable injection — src/img/inject_vars_in_manifest.png and src/img/manifest-merged.png show manifest configuration strategies; understanding build-variant manifest merging prevents configuration errors
• Doze mode and power management — src/img/testing_doze_mode.jpg indicates coverage of battery optimization; understanding system sleep states and testing them is critical for background service tips in this guide

• google/android-architecture — Google's official architecture samples demonstrating recommended patterns (MVVM, MVI) that complement this tips cheatsheet with full working examples
• android/architecture-samples — Official Android samples repo showing best practices for fragments, navigation, and modern stack—pairs well with this cheatsheet's Gradle and Studio optimization tips
• JStumpp/awesome-android — Curated list of Android libraries and resources; this cheatsheet is featured in it and they cover complementary territory (tools vs. libraries)
• codepath/android_guides — CodePath's Android cliffnotes covering fundamentals and best practices—similar educational goal to this repo but broader scope
• nisrulz/Android-Debug-Database — A complementary tool by the same author for runtime Android database inspection—demonstrates practical implementation of tips covered in this cheatsheet

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.

Create a comprehensive Gradle tips index and migration guide from Groovy to Kotlin DSL

The repo has both src/gradle-groovy-script-tips.md and src/gradle-kotlin-script-tips.md as separate files, but lacks a comparison matrix and migration checklist. New contributors could create a structured guide mapping Groovy examples to their Kotlin DSL equivalents with side-by-side code samples, helping developers transition between the two build systems.

• [ ] Add a new src/gradle-migration-guide.md file
• [ ] Create a comparison table mapping Groovy syntax to Kotlin DSL for common tasks
• [ ] Reference specific sections from both gradle-groovy-script-tips.md and gradle-kotlin-script-tips.md
• [ ] Add code examples for: dependency declaration, task configuration, and custom extensions
• [ ] Update src/SUMMARY.md to include the new migration guide

Add missing ADB shell commands categorized by use case to src/adb-shell.md

The adb-shell.md file exists but is likely incomplete for a comprehensive cheatsheet. Contributors could systematically add categorized ADB commands organized by use case (debugging, performance profiling, device state, app management) with practical examples and expected outputs.

• [ ] Audit src/adb-shell.md for coverage gaps in common use cases
• [ ] Add sections for: memory analysis, battery/performance debugging, network simulation, and app installation
• [ ] Include real command examples with output samples for each section
• [ ] Add code snippets to code-files/ if complex ADB workflows warrant shell scripts
• [ ] Create visual workflow diagrams or screenshots showing command execution

Develop a testing tips and tricks guide specific to Android development

The repo is missing src/testing-android-best-practices.md or similar. Given the cheatsheet nature and the presence of testing-related tips scattered (e.g., 'making_methods_visible_for_testing.jpg' in img/), a dedicated testing guide covering unit tests, instrumentation tests, mocking, and test organization would be high-value for Android developers.

• [ ] Create src/testing-android-best-practices.md
• [ ] Add sections for: JUnit setup, Mockito/mock frameworks, Espresso UI testing, and AndroidX test libraries
• [ ] Reference the existing src/img/making_methods_visible_for_testing.jpg and create code examples
• [ ] Include testing-specific Gradle configurations from src/gradle-kotlin-script-tips.md and src/gradle-groovy-script-tips.md
• [ ] Add practical code samples to code-files/ for common testing patterns
• [ ] Update src/SUMMARY.md to include the testing guide

• Add a new chapter src/testing-best-practices.md covering JUnit4 patterns, Mockito setup, and Espresso tips with accompanying screenshots in src/img/; many Android devs ask but it's missing from the cheatsheet.
• Create src/room-database-tips.md documenting Room ORM patterns, migrations, and common pitfalls with code examples in code-files/; crucial for data layer but currently absent.
• Add validation to the deploy-to-github-pages.sh script to check for broken markdown links (using a tool like mdbook-linkcheck) and report them before publishing; prevents stale references in the live book.

This is a documentation/tips repository with low security risk. The codebase consists primarily of markdown documentation, configuration examples, and shell/gradle scripts. No actual application code with dynamic user input processing was identified. No hardcoded secrets, credentials, or API keys were discovered in the file structure. The main concerns are general best practices for script security. Dependencies are not explicitly managed in this repository as it's a documentation project. Overall security posture is strong for this type of repository.

• Low · External Image Resource in README — Readme.md. The README references an external image (github_banner.png) via GitHub raw content. While not a direct vulnerability, this could be subject to supply chain risks if the image source is compromised. Fix: Ensure the image source is trusted and consider hosting critical assets on a secure, controlled server.
• Low · Build Script Lacks Input Validation — deploy-to-github-pages.sh. The deploy-to-github-pages.sh script is present but typical shell scripts may lack proper input validation and error handling, potentially leading to command injection if parameters are user-controlled. Fix: Review the script for proper input validation, use shellcheck for linting, and ensure all variables are properly quoted and validated before use.

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.