The project
Create a reproducible terminal workflow that diagnoses an Android project, builds it, runs a targeted check and captures device evidence.
Prerequisites
Complete the six teaching modules and their exercises. Keep the design notes and failure cases: they form the starting evidence for this project.
Build in increments
1. What the Android CLI is for
Understand terminal-oriented Android workflows and their limits. Apply the module decision to this project. Your checkpoint: You can distinguish environment, build and device failures.
2. Environment and project diagnosis
Establish a reliable baseline before changing the workspace. Apply the module decision to this project. Your checkpoint: The report allows another engineer to reproduce the environment issue.
3. Building and selecting variants
Run explicit checks and interpret their results. Apply the module decision to this project. Your checkpoint: A failed check cannot be reported as a successful workflow.
4. Devices, deployment and observation
Make runtime verification reproducible. Apply the module decision to this project. Your checkpoint: Your report identifies the exact build, device and behavior verified.
5. Skills and agent-driven workflows
Use the CLI as a controlled execution surface. Apply the module decision to this project. Your checkpoint: Each operation has a known side effect and a reason to run.
6. Automation and team handoff
Package the terminal workflow without personal-machine assumptions. Apply the module decision to this project. Your checkpoint: The workflow either produces evidence or stops with an actionable explanation.
Acceptance criteria
- Record tool versions and selected device explicitly
- Stop on failed commands rather than reporting false success
- Keep installation and destructive operations separate from read-only diagnosis
Evidence to submit
- A repository or reproducible design artifact with setup instructions and tested tool versions.
- A diagram showing components, data flow, authority and failure boundaries.
- An evaluation table with inputs, expected results, actual results and explanations of failures.
- A demonstration of the normal path and at least two relevant failure paths.
- A short decision record covering alternatives, known limitations and the next improvement.
Review rubric
| Dimension | Ready to demonstrate | Revisit when |
|---|---|---|
| Understanding | Explain each boundary and why it exists | You can only repeat framework terminology |
| Implementation | Reproduce the core behavior from a clean setup | Hidden local state is required |
| Reliability | Show bounded failures and useful recovery | The demo only works on the happy path |
| Evidence | Present observed outcomes and limitations | Success is inferred from a generated answer |
| Ownership | Modify a requirement and explain the consequences | You cannot adapt the implementation independently |
Do not treat a completed reading checklist as proof of project readiness. Revisit any module whose checkpoint you cannot demonstrate.