Android Engineering · Real-World Workflow
How Does Android Development Work in Real Companies Today
Quick summary — Android development in real companies
In a real company, Android development is a team sport, not a solo coding job. You own a module or feature area, write small pull requests, pass code review and CI, and ship through QA and a staged release. This guide shows the whole flow, step by step.
In this guide you will learn:
- Team structure & roles — who does what in an Android squad.
- Sprint workflow & code review — how a ticket becomes merged code.
- CI/CD, testing & release — how an app actually reaches users.
- Team workflow templates — standup, PR and release logs.
- How to prepare — what to learn before your first team.
SECTION 01Team structure & roles
The first thing that surprises developers joining a real company is that nobody owns the whole app. Here is how a typical Android squad is actually split:
| Role | What they own | Daily work | Output |
|---|---|---|---|
| Product Manager | Requirements and priority | Standups, spec reviews, user feedback | Clear ticket specs |
| Android Developer | Screens and feature logic | Feature work, PRs, bug fixes | Shipped features |
| Tech Lead / Senior | Architecture and code quality | Code reviews, design docs, unblocking | Approved PRs |
| QA Engineer | Test plans and regression | Device testing, bug reporting | Release sign-off |
| DevOps / Platform | CI/CD pipeline and builds | Build monitoring, tooling | Green pipelines |
Typical Android squad in a mid-size company:
1 Product Manager
1 Tech Lead / Senior Android Developer
2–4 Android Developers
1 QA Engineer (shared or dedicated)
1 Product Designer
1 DevOps / Platform Engineer (shared)
1 Engineering Manager (1:1s, roadmap, hiring)
A startup collapses this into 2–3 people.
A large product splits it into many squads by feature area.Real ownership is sliced, not whole-app:
Squad A → Onboarding, authentication, profile
Squad B → Payments and checkout
Squad C → Feed, search and recommendations
Platform team → shared design system, networking,
build tooling, CI/CD
You will usually own one slice.
That is normal — and it is how large apps stay shippable.SECTION 02Sprint workflow & code review
Android teams almost always work in two-week sprints. Here is the loop a ticket actually travels through:
| Stage | When | What happens | Outcome |
|---|---|---|---|
| Grooming | Week before sprint | Tickets clarified, acceptance criteria written | Ready backlog |
| Sprint planning | Day 1 | Tickets estimated and assigned | Sprint board |
| Daily standup | Every morning | Progress and blockers surfaced | Aligned team |
| Code review | On every PR | Two approvals plus a green pipeline | Merged code |
| Retro | Last day | What worked, what did not | Process tweaks |
Android sprint — realistic two-week rhythm:
Day 1 Sprint planning (1 hour)
Day 1–2 Branch off main: feature/JIRA-1234
Day 2–8 Build feature, open PR early (draft)
Day 3–9 Code review: 2 approvals + CI green
Day 8–9 QA regression pass on staging build
Day 10 Release candidate built and tagged
Day 10 Retro + grooming for next sprint
Rule of thumb: if a ticket is open longer than
a sprint, it was too big to estimate correctly.Before you hit "Ready for review":
☐ Branch named feature/JIRA-1234
☐ PR under 400 lines changed
☐ Description explains what changed and why
☐ Screenshots or a screen recording attached
☐ Unit tests added or updated
☐ CI pipeline is green
☐ 2 approvals from code owners
☐ No debug logs, no hardcoded strings
☐ Accessibility checked (content descriptions)
Small PRs with screenshots get merged in hours.
Huge PRs sit for days and block the sprint.SECTION 03CI/CD, testing & release
This is the part most tutorials skip. Here is how an Android build actually moves from a developer's laptop to real users:
| Environment | What runs there | Who touches it | Gate |
|---|---|---|---|
| Local | Unit tests, lint, debug builds | Developer | Pre-push hooks |
| CI | Build plus instrumented tests | Automated | Blocks merge |
| Staging | Full app against staging backend | QA and developers | Release sign-off |
| Internal track | Play Console internal testing | Team and testers | Crash-free check |
| Production | Staged rollout to real users | Release owner | Monitoring |
On every pull request:
1. Lint + static analysis (detekt / ktlint)
2. Unit tests (JUnit) — must pass
3. Instrumented tests on an emulator matrix
4. Build debug APK
5. Report status back to GitHub / GitLab
On merge to main:
1. Build release AAB
2. Sign with the release keystore
3. Upload to Play Console internal track
4. Tag the release in Git
5. Post the changelog in the team channel
If any step fails, the merge is blocked.Android release checklist:
☐ All PRs for the milestone merged
☐ versionCode bumped, versionName set
☐ Release notes written for users
☐ Internal changelog added to the wiki
☐ QA sign-off on the staging build
☐ Crash-free rate above target on internal track
☐ Staged rollout plan agreed (5% → 20% → 100%)
☐ Rollback plan and previous build documented
☐ Support and marketing informed of the release
Shipping is a team decision, not a single dev's call.SECTION 04Team workflow templates
Copy these three templates and use them from your first week on an Android team:
DAILY STANDUP — ____ (date)
Yesterday I finished:
1.
2.
Today I will work on:
1.
2.
Blockers:
1.
(if none, write "None")
PRs waiting on review:
- PR #____ — ___________
Keep it under 2 minutes. Details go in the PR.RELEASE LOG — version ______
Date: ____________
versionName: ______
versionCode: ______
Changes in this release:
1.
2.
Rollout plan: ____% → ____% → 100%
Rollback trigger: crash-free below ____%
Release owner: ____________
QA sign-off: ☐ Yes ☐ No
Post-release check (48 hours):
☐ Crash-free rate stable
☐ ANR rate stable
☐ Play Store rating unchanged
☐ Support tickets reviewedFIRST WEEK ON AN ANDROID TEAM
☐ Get repo access and clone the project
☐ Read the architecture doc and README
☐ Run the app locally on an emulator
☐ Learn the module structure and naming rules
☐ Pick a "good first issue" ticket
☐ Open one small PR (under 200 lines)
☐ Get it reviewed and merged
☐ Attend standup, planning and retro
☐ Understand the CI pipeline and release process
☐ Ask your buddy how releases are cut
The goal of week one is to learn the workflow,
not to ship a big feature.SECTION 05How to prepare for an Android team
Six things that make the difference between struggling for weeks and contributing in your first sprint:
- Learn the standard stack — Kotlin, Jetpack Compose, coroutines and Flow, Retrofit, Room, Hilt and MVVM.
- Practise small pull requests — keep changes under 400 lines and always attach a screenshot or recording.
- Write tests as you code — unit tests with JUnit and MockK, and know what a flaky test looks like.
- Learn Git properly — branch per ticket, rebase cleanly, resolve conflicts, write meaningful commit messages.
- Read other people's code — review open PRs in sample projects and leave specific, kind comments.
- Understand the release basics — versioning, signing, Play Console tracks and staged rollouts.
SECTION 06Android Q&A — real company workflow
Q1Do I really need to know CI/CD to get an Android job?
You need to understand it, not build it from scratch. Know what a green pipeline means, how to read a failed build log, and why a PR cannot merge without passing tests.
Q2How big should my pull requests be?
Under 400 lines changed is the usual guideline. Small PRs get reviewed in hours; a 2,000-line PR sits for days and blocks your entire sprint.
Q3What if my code gets rejected in review?
Expect it on most first PRs — it is normal. Read the comment, ask a question if it is unclear, fix it and push. Review protects quality; it is not a judgement on you.
Q4How does the release process work day to day?
A release candidate is built from main, QA signs off on staging, it goes to the Play Console internal track, then a staged rollout of 5% → 20% → 100% while the team watches crash and ANR rates.
Q5What does an Android developer do in the first week?
Set up the environment, run the app locally, read the architecture docs, take one small "good first issue" ticket and land one tiny PR. Week one is about learning the workflow, not shipping a big feature.
SECTION 07Test yourself — Android real-world workflow quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
What is the standard tech stack in real Android teams?
Kotlin, Jetpack Compose, coroutines and Flow, Retrofit, Room, Hilt and MVVM, built with Gradle and shipped through a CI pipeline. Many teams are still migrating older screens from XML views to Compose.
Is Android development mostly solo or team work?
Team work. You own a slice — a module, a feature area or a screen flow — and ship it through code review, QA and a staged release.
Do freshers get to ship features in real companies?
Yes, usually small features and bug fixes under a senior's review. That is exactly how you grow — by shipping real code through the real workflow.
How much testing is actually expected?
Unit tests on your own PR plus a QA regression pass on staging. CI runs both automatically, so a red pipeline blocks your merge long before QA sees it.
Which tools do real Android teams use daily?
Android Studio, Git with GitHub or GitLab, Jira for tickets, Slack for communication, Firebase Crashlytics for crash reporting, and the Play Console for releases.
SECTION 09Related reads
Classroom & online · Delhi NCR
Learn Android the way real teams build it
Our Android Development Training Course is built around the real workflow — Kotlin, Compose, pull requests, code review, testing and release practice.
₹15,500 onwards- Kotlin & Jetpack Compose
- Real team workflow & code review
- Testing, CI/CD and releases
- Weekday & weekend batches