Android Architecture Samples: A Branch-Based Tour of App Structure, Not a Template

What This Repo Actually Solves

The repository addresses a recurring problem for Android developers: how to structure an app so that it is testable and maintainable. It does this by taking a single TODO app and reimplementing it across multiple branches, each with a different architectural approach. The README is explicit about the target audience: intermediate developers and beginners who want a structure to follow, and advanced developers who need a quick reference. The value is not in the app itself, which is deliberately simple, but in the comparison between architectural patterns. If you have ever wondered how a repository layer differs from a ViewModel-only setup, or how Flow fits into a UI, this repo gives you a working example to study.

The Compose Branch: A Specific Architecture Stack

The default branch, which is the one described in the README, builds the UI with Jetpack Compose and uses a single-activity architecture with Navigation Compose. Each screen or feature gets its own ViewModel. The presentation layer is separated from the data layer, which contains a repository and two data sources: a local Room database and a fake remote source. Asynchronous work uses Flow and coroutines. Dependency injection is handled by Hilt. This is a coherent stack, and the README lists each component with a link to its official documentation. The design choice is clear: keep the UI simple and focus on how the layers communicate. The trade-off is that you see one specific way of doing things, not a range of options within the same branch. To see alternatives, you have to switch branches.

Why a TODO App Is the Right Vehicle

The README explains the choice of a TODO app: it is simple enough to understand quickly, but complex enough to showcase difficult design decisions and testing scenarios. A TODO app has CRUD operations, list and detail views, and state that changes over time. That is enough to demonstrate how a repository abstracts data sources, how a ViewModel survives configuration changes, and how tests can cover different layers. The README links to the app's specification on the googlesamples/android-architecture wiki. This is a deliberate constraint. The app does not pretend to be a real product. That is both its strength and its limit. You can grasp the architecture in an afternoon, but you will not see how to handle authentication or network failures.

Getting It Running: Clone and Open in Android Studio

The README gives a single command to get started: `git clone [email protected]:android/architecture-samples.git`. After cloning, you open the `architecture-samples/` directory in Android Studio. The instructions assume you have Android Studio installed and that you are comfortable with Gradle. There is no mention of a specific Android Studio version or a Gradle wrapper command, so you may need to let Android Studio sync the project on first open. The repo uses product flavors named `mock` and `prod`. The README links to an Android Developers blog post about leveraging product flavors. You will need to select a build variant in Android Studio to run the app.

Testing: Unit, Integration, and Shared Tests

The README states that the project includes a collection of unit, integration, and e2e tests, including shared tests that can run on an emulator or device. This is a significant part of the value proposition. The tests are not an afterthought; they are part of the architecture demonstration. The README says the shared tests can be run on an emulator or device. However, the README does not list the specific test frameworks or libraries used. You would need to inspect the build files to see if it uses JUnit, Espresso, or Compose testing. That is a gap in the documentation, but it does not diminish the usefulness of the tests as examples.

What This Repo Is Not: Boundaries and Alternatives

The README is unusually clear about what the repo is not. It is not a template; for that, the README points to `android/architecture-templates`. It is not a UI or Material Design sample; for that, it points to `android/compose-samples`. It is not a production app with network access or authentication; for that, it points to `android/nowinandroid`. These boundaries are important. If you need a starting point for a new app, the templates repo is a better fit because it provides a scaffold you can copy. If you need to see how to implement a specific Compose UI pattern, the Compose samples repo is more focused. The architecture-samples repo sits in between: it shows a complete, testable app structure, but it does not give you a reusable project skeleton. This is a deliberate choice, and it means you should not expect to clone this repo and rename it for your own app.

Licence and Maintenance Considerations

The repository is licensed under Apache-2.0, according to the repository metadata and the README's license notice. The README includes a copyright notice for Google, Inc. and the standard Apache license text. This means you can use the code in your own projects, including commercial ones, as long as you include the license notice and state changes. The repository has a CONTRIBUTING.md at the top level. The last push was on 2026-10-30 and the repository has no GitHub releases. The default branch is `main` and the repository is not archived, but you should check the commit history before relying on it.

Editorial conclusion

Adopt this repository if you are an intermediate Android developer who wants a concrete, testable example of a single-activity Compose app with a repository layer, Room and a fake remote source, Hilt DI, and product flavors. Do not use it as a template for a production app, because it intentionally lacks network access, authentication, and real UI polish. Before relying on it, verify which branch matches your target architecture, since each branch demonstrates a different pattern, and check the branch's README for its specific dependencies and build setup. The Compose branch is a solid starting point for learning, but treat it as a study aid, not a foundation to copy.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases