Last updated: September 3, 2026
By Jennifer Burdick, Recruiting Manager, KORE1
An Android developer job description has to name the surface the app runs on, say whether the codebase contains native NDK code, describe the Compose or Views situation honestly, and state who owns the Play Console release. Skills lists are interchangeable. Those four facts are what decide whether the right forty people apply or the wrong two hundred do.
The req that taught me this got filled, on time, with a good engineer. It still went wrong.
A connected fitness company in Costa Mesa needed an Android engineer last year. Their posting was fine. Kotlin, Jetpack Compose, MVVM, coroutines, REST, three-plus years, the usual shape. Ninety-four applications, a decent slate, and a mid-senior app engineer who interviewed well and was genuinely good. She shipped a settings redesign in her first six weeks and the team liked her.
Their app talks to a piece of hardware. The signal processing for that lives in a C++ library a vendor built for them in 2019, wrapped in JNI, and nobody at the company had touched it in three years.
When the 16 KB page size rebuild came due, there was no one to do it.
She had never opened an Android.mk file. Why would she have. Nothing in the posting, the phone screen, or the loop had suggested the job involved native code, because the person who wrote the req thought of the C++ as infrastructure rather than as part of the app. It sat in a repo with its own owner, and that owner had left.
They are working through it now with a contractor. The fix is not exotic. It is just a completely different hire from the one they made, and the fork happened in the job description, months before anyone interviewed anybody.
Where I sit on this. I have been recruiting for fourteen years, almost thirteen of them at KORE1, and I run our delivery side across Android developer staffing and the rest of our tech desks. We get paid when you hire someone we sent. Most of this page is about writing a better posting, which is free, takes an afternoon, and does not require me at all.
Android Is Not One Job Market
“Android Developer” describes at least five different jobs, and the people who do them do not overlap much.
Phone and tablet apps are the big one, and that is what most hiring managers picture. Then there is Wear OS, which is a constrained-resource discipline where battery is the design constraint and nobody who has not done it appreciates how different that makes everything. Android TV is a leanback interface with a D-pad and no touch. Android Automotive OS, which is not Android Auto and I have watched that confusion cost people a month, is Android running as the vehicle’s actual operating system, on a supplier timeline, with functional safety people in the room. And then AOSP work, where the deliverable is a system image for a kiosk, a handheld scanner, a medical device, or a payment terminal.
A supplier in Irvine posted for an “Android Developer” for an Automotive OS program. Twenty-nine applications. Every one was a phone app developer. Not a single person had built a vehicle HMI or seen an SOP date. The role was reposted as “Android Automotive OS Engineer, AAOS/HMI” with two sentences describing the program, and the second run brought four people who had shipped in a vehicle. They hired one.
Same company. Same recruiter. Same comp. The title and the first paragraph did all of it.
Google’s own compliance calendar treats these as separate products too, which is a useful tell. Under the Google Play target API level requirements, as of August 31, 2026, new apps and updates have to target Android 16 (API level 36), while Wear OS and Android Automotive sit at API 35 and Android TV and Android XR sit at API 34. If the platform is willing to say these are different, your job posting can too.
Native Code Is a Yes or No Question, and It Has a Date on It
This is the section I would add to every Android req in the country if I could add only one.
Does your app contain C or C++ code, or ship a third-party SDK that does? Ad networks, media players, computer vision, BLE stacks, game engines, DRM, audio processing, anything from a hardware vendor. If the answer is yes, say so in the posting, in the requirements, in plain language.
Here is why it matters right now rather than in the abstract. Apps targeting Android 15 or higher have to support 16 KB memory page sizes on 64-bit devices, and per Google’s page size documentation, starting February 1, 2027, you cannot ship an update that does not. Apps written purely in Kotlin or Java are unaffected. Every library with native code has to be rebuilt and realigned.
Five months out. For a lot of teams that is one person, two weeks, and a vendor email. For teams whose native dependency came from a company that no longer supports it, or an engineer who left, it is considerably worse than that, and it is the kind of work that does not fit neatly into a sprint because most of the time is spent finding out who can even produce a new build.
Postings almost never mention any of this. So the applicant pool arrives sorted for the wrong thing.
Write the line. “This codebase includes a native C++ imaging library accessed through JNI, and this role owns it, including the 16 KB page size migration.” Some candidates will self-select out. Good. The ones who stay are the ones who can do the work, and you learn that in week one rather than in the release branch.
Say What Your Codebase Actually Is
On July 28, 2026, the Android team published a five-year retrospective on Jetpack Compose confirming that more than 68 percent of the top 1,000 Play Store apps run it in production, and that Google is now Compose-first with the Views toolkit in maintenance mode.
Every Android req in America added “Jetpack Compose required” within about six weeks.
Plenty of those codebases are still ninety percent XML. I understand why the line goes in. It signals modernity, it gets past candidates who screen for it, and nobody wants to publish a posting that admits the app looks like 2019. The cost shows up later, in the exit interview of the person who took the job expecting Compose work and spent seven months in Fragments.
Three honest versions, all of which are hireable:
- Greenfield or near-greenfield Compose. Say it, because it is a genuine draw and you should get credit for it.
- Mixed, with an interop boundary and a real migration underway. This is the most common state and it attracts a specific and underrated engineer, the kind who has done a migration and knows where the bodies are buried.
- Views, no migration funded. Also fine. There are engineers who prefer a stable mature codebase and would rather ship features than argue about architecture. Describe it as maintenance and modernization with a real product roadmap and you will find them.
What does not work is version two written as version one. Candidates find out on day four.
The other thing worth putting in the requirements is the target SDK jump, because targeting Android 16 is not a version bump. It is a behavior change. The Android 16 behavior changes remove the edge-to-edge opt-out entirely. Predictive back turns on by default, so onBackPressed() stops getting called. And on any display 600dp or wider, the platform now ignores your orientation and aspect ratio settings, which means the tablet layout somebody locked to portrait four years ago is going to rotate whether or not anyone designed for that. Our Android developer interview questions guide covers how to screen for the work. The posting only has to admit it exists.
Who Owns the Release
The single most common ambiguity in Android reqs is not technical. It is whether this person ships the app or writes features that someone else ships.
Those are different jobs and they pay differently. Release ownership means the Play Console, staged rollouts and when to halt one, the data safety form, permissions declarations, pre-launch reports, crash triage against ANR thresholds, signing keys, and the target API compliance calendar. A team with fifteen engineers usually has one or two people who actually hold this. A team with three engineers has one person who holds all of it and often does not know that is what they signed up for.
Ask who does it today. If the answer is a name, and that name is leaving, that is the job you are hiring for and the posting should say so in the first paragraph, not in a bullet buried under nice-to-have. Say it early. It is the most attractive part of the role for the right senior engineer, and the part that scares off the wrong one.
There is a live example this quarter. Teams that missed the August 31 target API deadline can request an extension into November through Play Console. Somebody at your company is doing that paperwork, or nobody is. Either answer tells you exactly how to word this section.
What the Public Salary Numbers Are Measuring
Built In reports a US average base of $113,383 for Android developers with about $20,030 in additional cash compensation. O*NET puts the median for software developers generally at $135,980 with roughly 115,200 annual openings projected through 2034.
Both are averaging a junior maintaining a Views app in a low-cost market together with a staff engineer running a release train for an app with forty million monthly users. Useful as a floor. Not useful as a band. Do not budget from either one.
What we actually place against, nationally, as of this quarter:
| Level | Base range | What the posting should signal |
|---|---|---|
| Junior, 0 to 2 years | $85,000 to $110,000 | Mentorship, and who reviews the code |
| Mid, 3 to 5 years | $110,000 to $140,000 | Feature ownership, shipped through a full OS cycle |
| Senior, 6 to 9 years | $140,000 to $180,000 | Architecture calls, release ownership, mentoring |
| Staff and principal | $175,000 to $225,000 | Platform strategy, multi-team scope, equity detail |
City-level numbers, contract rates, and the equity conversation are worked through in our Android developer salary guide, and you can pressure-test a band against your own market with the salary benchmark assistant before the req goes to finance.
Android Developer Job Description Template
Copy this. Everything in brackets is yours to replace, and the bracketed notes explain why a line exists so you can delete them once you have made the decision they are pointing at.
Job Title
[Senior Android Engineer, Kotlin and Compose / Android Automotive OS Engineer / Android Platform Engineer, AOSP] [Put the surface in the title if it is anything other than a phone app. This one edit changes your applicant pool more than the entire requirements section does.]
About the Role
[Company] is hiring an Android engineer in [city, state] to work on [name the actual product: our consumer subscription app, the in-vehicle HMI for a 2028 program, the handheld terminal firmware our warehouse team uses]. The app has [X] monthly active users and ships [weekly / biweekly / monthly]. Our codebase is [roughly 60% Jetpack Compose with an ongoing migration from Views / all Compose, built in 2024 / Views and XML, with modernization funded for next year]. [Say the real number. Candidates ask in round one anyway, and a straight answer here buys you goodwill you cannot buy later.] You will report to [role] and work directly with [design, backend, QA, firmware, or whoever this person will actually be in a room with].
What You Will Own
- Feature development in Kotlin against [Compose / Compose with Views interop], including the parts of the app that are older than the pattern you would prefer to use
- [If applicable: our native layer. This app includes [C++ library or third-party native SDK] accessed through JNI, and this role owns it, including the 16 KB page size migration due before February 1, 2027.] [Highest-signal line in the posting if it is true. Delete it if it is not, because it will cost you candidates you want.]
- [Release ownership: Play Console releases, staged rollouts, data safety declarations, and the target API level compliance calendar / Feature delivery, with releases owned by [team or person].] [Pick one. Do not leave this ambiguous.]
- Crash and ANR triage against [tooling], and the judgment about which regressions hold a release
- Testing that matches how this app actually breaks, [instrumented tests on [device matrix] / Compose UI tests / whatever is true], including the [Samsung One UI / low-RAM device / tablet] cases that only show up in the field
- [If applicable: Wear OS companion experience / Android TV leanback interface / Automotive HMI to [OEM] specification]
What We Need to See
- [3+] years of production Android in Kotlin, with apps you can point to in the Play Store or describe in detail if they were internal
- Coroutines and structured concurrency in an app that had real lifecycle problems, not in a tutorial
- [Jetpack Compose, including state management and recomposition performance / Views and XML with a clear view on what migrating would take]
- A target SDK migration you personally shipped. [The single best predictor we have found for the first ninety days. Ask what broke that they did not expect.]
- [If applicable: NDK, JNI, CMake, and comfort rebuilding third-party native dependencies]
- Debugging skill on physical devices, particularly background execution and process death on [manufacturer skins you actually support]
Nice to Have
- Kotlin Multiplatform, if there is any chance of shared logic with iOS in the next two years
- [Your domain.] Healthcare, payments, and automotive each carry a body of compliance knowledge that takes a year to absorb
- Gradle. Genuinely. The person who can fix a build is worth more than the org chart suggests
- Accessibility work, especially TalkBack, which almost nobody lists and an increasing number of enterprise buyers require
Schedule, Location, and Release Cadence
[Onsite [X] days in [city] / fully remote within [time zones] / hybrid.] [Release cadence and what a release week looks like. If there is an on-call rotation for production incidents, say the rotation and the honest frequency.] [If there is hardware involved and the person has to be near it, that is a hard constraint and it belongs here rather than at offer stage.]
Compensation
[$140,000 to $180,000] base, plus [bonus], [equity, with vesting terms], [benefits]. [Post the range. If the number moves for native or platform scope, say that too.]
What Hiring Managers Ask Us Before They Post
We want Compose but our app is mostly XML. What do we write?
Write the truth and frame the migration as the work. “Compose migration in progress, roughly 40% converted” is a stronger posting than “Compose required” on a Views codebase, and it filters for people who have done one.
The engineers who have lived through a migration are the ones you want and they are not screening you out for having XML. They are screening you out for pretending. If there is no migration funded, say that instead and sell the stability, because that is a real preference for a real group of people.
Does putting the salary range in actually change anything?
Yes, and more on Android than on most reqs, because the public averages are so scattered that candidates cannot guess your band. Built In says $113,383. Glassdoor puts the senior title at $160,285. Both are correct for someone.
Without a range, a senior engineer has to decide whether you are the $110,000 version of this job or the $175,000 version, and the good ones do not spend a first call finding out. Colorado, California, New York, and Washington require it now anyway. The compliance argument is the boring reason. The applicant volume is the real one.
Android Auto or Android Automotive. Which do we have?
Android Auto projects a phone app onto the car’s screen. Android Automotive OS runs as the vehicle’s operating system with no phone involved. Different SDKs, different candidates, different hiring timelines.
I have seen a req sit for five weeks because the posting said one and meant the other, and the applicants were all technically responsive to the words on the page. If the work involves an OEM, a vehicle program, and an SOP date, you want AAOS in the title. If it is a media or messaging app that needs a car-friendly projection, you want an experienced phone app engineer who has shipped an Auto integration, and that is a much larger pool.
How specific should the device matrix be?
Specific enough to name the hard cases. “Supports Android 10 through 16 across Samsung, Pixel, and a fleet of Zebra handhelds” tells an engineer more about the job than any framework list.
Fragmentation is where Android experience actually lives. An engineer who has shipped against a low-RAM device or a manufacturer skin with aggressive background killing has a skill that does not transfer from a Pixel-only codebase, and they cannot tell whether they have it unless you say what you support.
Our last posting pulled mostly React Native and Flutter people. Why?
Something in the wording read as cross-platform, usually the word “mobile” in the title or a bullet listing several frameworks with “or similar” attached.
Put “Android” in the title and Kotlin in the first two lines. If you genuinely would consider a strong React Native engineer who can go native, that is a legitimate decision, and it should be a sentence you wrote on purpose rather than an outcome you discovered in the pool. The framework question in general is worked through in our guide to hiring an Android developer.
Contract or direct hire for a migration crunch?
Contract for the migration, direct hire for the seat that owns the app afterward. Target SDK and native rebuild work has a defined end. Product ownership does not.
Most teams facing a compliance deadline need both and only open one req, which is why the second search starts in a panic. Bringing in a contract Android engineer for the migration window while a direct hire search runs in parallel gets the deadline handled and gives your permanent hire something better than a handover document, because they arrive while the work is still on someone’s screen.
The Short Version
Name the surface in the title. Say whether there is native code, and if there is, say who owns the February deadline. Describe the codebase you actually have rather than the one you want. State whether this person ships the app or writes features. Post the band.
Five decisions. None of them are about skills, and all of them are made before a single candidate sees the posting, which is why a bad req is so expensive and so cheap to fix.
If you want a second read on an Android posting before it goes live, or you are eight weeks into a search that keeps producing the wrong people, talk to our tech team. We run Kotlin, iOS, and broader mobile developer staffing searches alongside Android, our average IT time-to-hire is 17 days, and twelve-month retention on our placements is 92%.
