Onboarding: android/architecture-samples

Generated by RepoPilot · 2026-05-05 · Source

Verdict

GO — Healthy across the board

• Last commit 6d ago
• 5 active contributors
• Distributed ownership (top contributor 43%)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Small team — 5 top contributors

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

TL;DR

The Android Architecture Samples repository provides various sample Android applications illustrating different architectural patterns and tools to manage Android app development effectively. It specifically showcases a TODO app that utilizes Jetpack Compose, a single-activity architecture with Navigation Compose, and employs MVVM patterns with Hilt for dependency injection. The repository is structured as a monorepo with the app module containing the core application logic, divided into different source sets for main, androidTest, and debug implementations. It utilizes a modular approach to separate features and testing environments.

Who it's for

Intermediate and beginner Android developers who need a structured guide on implementing reactive UIs, ViewModels per feature, and testing strategies, along with advanced developers seeking to quickly reference architectural best practices in app development.

Maturity & risk

The repository has over 21,000 stars and is actively maintained as of October 2023. It includes comprehensive tests for UI and unit testing, automated CI setup through GitHub actions is in place, and the codebase sees regular commits, confirming that it is actively developed and production-ready.

The main risk factors include dependency quality management, as the repository employs various libraries like Room and Hilt. There may be multiple open issues, but overall contribution and maintenance are robust, with no indication of single-maintainer risks. The last commit was recently made, suggesting continued support.

Active areas of work

Active development includes refining tests for UI components and updating documentation for better onboarding processes. Recent changes reflect enhancements in the test organization structure and additions of more test cases for the TODO app functionalities.

Get running

Clone the repository using git clone git@github.com:android/architecture-samples.git, then open the architecture-samples/ directory in Android Studio to start working on the project.

Daily commands: To run the project, select the desired product flavor (mock/prod) and use the Android Studio 'Run' configurations to launch the TODO app.

Map of the codebase

• app/src/main/java/com/example/android/architecture/blueprints/todoapp/TodoApplication.kt — This is the entry point for the application and sets up the necessary components.
• app/src/main/java/com/example/android/architecture/blueprints/todoapp/TodoNavGraph.kt — Defines the navigation graph for the app using Navigation Compose.
• app/src/main/java/com/example/android/architecture/blueprints/todoapp/data/DefaultTaskRepository.kt — Implements the repository pattern for managing task data sources.
• app/src/main/java/com/example/android/architecture/blueprints/todoapp/addedittask/AddEditTaskViewModel.kt — Contains the ViewModel logic for adding and editing tasks.
• app/src/main/java/com/example/android/architecture/blueprints/todoapp/tasks/TasksViewModel.kt — Handles the business logic for displaying tasks and managing the task list.
• app/src/main/res/drawable/ic_add.xml — An essential drawable resource used throughout the application to signify addition functionality.

Components & responsibilities

• TodoApplication (Kotlin, Hilt) — Application setup and dependency management.
  • Failure mode: Application crash during initialization.
• ViewModels (Kotlin, Flow) — Business logic and data handling for UI components.
  • Failure mode: Incorrect UI state or data displayed.

Data flow

• Repository → Database — Fetches and stores task data.
• Activity → ViewModel — Requests UI data and state.

How to make changes

Add a new Task feature

1. Create a new screen in the UI layer for the Task feature. (app/src/main/java/com/example/android/architecture/blueprints/todoapp/tasks/NewTaskScreen.kt)
2. Implement corresponding ViewModel to handle UI logic. (app/src/main/java/com/example/android/architecture/blueprints/todoapp/tasks/NewTaskViewModel.kt)
3. Update the navigation graph to include the new screen. (app/src/main/java/com/example/android/architecture/blueprints/todoapp/TodoNavGraph.kt)
4. Add a method in the repository to manage new task data. (app/src/main/java/com/example/android/architecture/blueprints/todoapp/data/TaskRepository.kt)

Add a new Unit Test

1. Create a new test file for the component you are testing. (app/src/androidTest/java/com/example/android/architecture/blueprints/todoapp/tasks/NewTaskScreenTest.kt)
2. Implement test cases covering various scenarios for the new feature. (app/src/androidTest/java/com/example/android/architecture/blueprints/todoapp/tasks/NewTaskScreenTest.kt)

Why these technologies

• Jetpack Compose — Provides a modern declarative UI framework for building dynamic UIs in Android apps.
• Hilt — Simplifies dependency injection, making it easier to manage app components.

Trade-offs already made

• Use Flow for reactive data streams
  • Why: Enables efficient and responsive UIs that update based on data changes.
  • Consequence: Adds complexity due to asynchronous data management.

Non-goals (don't propose these)

• Support multiple app modules related to different functionalities outside the TODO app.
• Implement complex server-side integrations.

Code metrics

• Avg cyclomatic complexity: ~5 — Use of multiple architectural components adds to complexity.
• Largest file: app/src/main/java/com/example/android/architecture/blueprints/todoapp/data/DefaultTaskRepository.kt (80 lines)
• Estimated quality issues: ~3 — Some files contain unoptimized logic or anti-patterns.

Anti-patterns to avoid

• Using global mutable state (High) — app/src/main/java/com/example/android/architecture/blueprints/todoapp/data/TaskRepository.kt: Leads to unpredictable state changes and difficult debugging.

Performance hotspots

• app/src/main/java/com/example/android/architecture/blueprints/todoapp/data/DefaultTaskRepository.kt (Data access) — Accessing data from multiple sources can slow down data retrieval.

Traps & gotchas

Ensure to install necessary Android SDK components and configure emulator settings correctly, as this project relies on Jetpack Compose and various architectural components that require specific versions to function properly.

Architecture

Concepts to learn

• Jetpack Compose — It's the UI toolkit for building native Android UIs using a declarative approach, which is critical for modern app development.
• Hilt — Hilt simplifies dependency injection in Android applications, making it easier to manage and test dependencies.
• MVVM — The Model-View-ViewModel architecture pattern promotes separation of concerns and enhances testability in app development.
• Navigation Compose — A component for managing app navigation in apps that use Jetpack Compose, crucial for user flow design.
• Flow — A reactive stream library for handling data asynchronously in Kotlin applications, essential for building responsive UIs.
• Room — An abstraction layer over SQLite that allows for a more manageable way to deal with databases in Android applications.

Related repos

• android/architecture-templates — Provides various template projects for developing Android applications with different architectural approaches.
• android/sunflower — A sample Android project showcasing modern Android development practices, including Jetpack libraries.
• android/nowinandroid — Demonstrates best practices in Android development, focusing on design patterns and architecture.

PR ideas

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 unit tests for TaskDao

Currently, the DAO layer lacks comprehensive unit tests to ensure the data access methods work as expected. Adding these tests will help catch any future regressions when changes are made to the database interactions.

• [ ] Create a new test file named TaskDaoTest.kt in app/src/main/java/com/example/android/architecture/blueprints/todoapp/data/source/local/
• [ ] Use an in-memory Room database for testing TaskDao methods.
• [ ] Test all CRUD operations for TaskDao, including inserting, updating, deleting, and querying tasks.

Add UI tests for TodoActivity

While there are tests for various screens, there are currently no UI tests specifically targeting the TodoActivity, which is the main entry point of the app. This could help ensure that the basic UI flow works as intended.

• [ ] Create a new test file named TodoActivityTest.kt in app/src/androidTest/java/com/example/android/architecture/blueprints/todoapp/
• [ ] Use Espresso for checking UI components and navigation within TodoActivity.
• [ ] Test the display of the task list and the functionality of adding a new task.

Refactor AddEditTaskScreen.kt into smaller components

The AddEditTaskScreen.kt file may have become too large and complex over time. Breaking it down into smaller composables will enhance readability and maintainability.

• [ ] Identify logical components in AddEditTaskScreen.kt that can be extracted, such as a specific input form for tasks.
• [ ] Create new composable files for extracted components under app/src/main/java/com/example/android/architecture/blueprints/todoapp/addedittask/
• [ ] Update AddEditTaskScreen.kt to use the new components, ensuring the functionality remains unchanged.

Good first issues

• Add missing unit tests for the classes in app/src/main/java/com/example/android/architecture/blueprints/todoapp/data/source/local.
• Improve the README.md to include additional examples for using significant features like Hilt and Navigation Compose.
• Refactor and enhance the current e2e tests located in app/src/androidTest/java/com/example/android/architecture/blueprints/todoapp to cover more scenarios or edge cases.

Top contributors

• @JoseAlcerreca — 40 commits
• @dturner — 28 commits
• @tunjid — 17 commits
• @renovate[bot] — 5 commits
• [@Manuel Vivo](https://github.com/Manuel Vivo) — 4 commits

Recent commits

• ee66e15 — Add CODEOWNERS (yrezgui)
• 9a02de6 — Merge pull request #1029 from cartland/workflow_dispathc (cartland)
• 58ac987 — Add workflow_dispatch trigger to workflows from GitHub (cartland)
• b3437ab — Merge pull request #1022 from android/renovate/kotlin (JoseAlcerreca)
• 5fd0ba3 — Update kotlin (renovate[bot])
• ff2046b — Merge pull request #920 from android/renovate/all (JoseAlcerreca)
• 47f82c3 — Update all dependencies (renovate[bot])
• 6093bc6 — Merge pull request #927 from android/renovate/kotlin (riggaroo)
• 190bb76 — Removes compiler from build.gradle.kts (JoseAlcerreca)
• e802b09 — Remove compose compiler from libs.versions.toml (JoseAlcerreca)

Security observations

The codebase exhibits a generally moderate security posture with some areas requiring improvements, particularly in dependency management and potential injection risks. Attention to detail in configuration files and layers can enhance overall security.

• Medium · Potential Insecure Dependency Usage — Dependencies/Package file content. The project's dependencies may include insecure or outdated packages that could have known vulnerabilities. Without explicit dependency information, it's essential to review the versions of libraries used and check for any reported security issues. Fix: Run a security audit tool or use dependency scanning tools like OWASP Dependency-Check or Snyk to analyze dependencies for known vulnerabilities.
• Low · Potential Risk of Hardcoded Secrets — Potentially in config files like .env, if they exist. The file structure does not explicitly indicate the presence of hardcoded secrets, but files related to configuration (if created) need to be monitored for hardcoded API keys or sensitive data. Fix: Use environment variables or a secure configuration management tool to manage sensitive information instead of hardcoding them.
• Medium · Injection Risks in Data Layer — app/src/main/java/com/example/android/architecture/blueprints/todoapp/data/source/local/TaskDao.kt. The app's data layer components like TaskDao and TaskDaoTest should be inspected for potential SQL injection vulnerabilities if raw SQL queries are used without proper sanitation. Fix: Always use parameterized queries or ORM features that help prevent SQL injection.
• Medium · Potential Missing Security Headers — Web components, applicable if any web server is set up. No review of web endpoints or related configurations to check for missing security HTTP headers. Fix: Ensure HTTP security headers like Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, etc. are set to protect against common web vulnerabilities.
• Low · Review of Docker Configuration — Docker/Infrastructure issues if visible. If Docker is being used, misconfigurations might expose services or sensitive information through default settings or unprotected endpoints. Fix: Review Docker configurations for exposed ports and ensure that services are only accessible internally unless otherwise necessary.

LLM-derived; treat as a starting point, not a security audit.

Where to read next

• 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.