Android TV app development

The toolkit under you changed

If your last TV estimate was written against Leanback, it is out of date.

Android's documentation now carries a plain warning on the Leanback page: the Leanback library is deprecated, and it directs you to Jetpack Compose for Android TV OS instead. The Compose for TV page is equally direct — it calls Compose the modern approach for building Android TV user interfaces.

The usual objection to Compose on TV was reach, and that objection has expired: Compose for TV works on Android TVs running Android 5.0, API level 21, or higher. That is further back than any streaming catalogue's device data realistically justifies supporting.

Two practical consequences:

1. A new build should not start on Leanback. Starting on a deprecated toolkit in 2026 buys you a migration you will pay for later, at a worse time.
2. An existing Leanback app is not an emergency. Deprecated is not removed. Google publishes a migration guide, and the workable path is screen by screen — replace whole fragments rather than attempting a rewrite while the app is live.

If a vendor's tech-stack page still lists Leanback as its Android TV toolkit, that tells you when their TV practice was last updated.

The checklist that actually decides acceptance

This is the part that separates a TV project from a phone project, and it is published, so there is no excuse for discovering it late. Google's TV app quality guidelines set named criteria, each with an ID. The ones that catch teams:

• TV-MT — the manifest must declare android.hardware.touchscreen, and the other TV hardware features, as not required. A phone build declares the opposite by default. This single line is the most common reason a "we already have an Android app" submission bounces.
• TV-ML — the manifest must set an intent of ACTION_MAIN with category CATEGORY_LEANBACK_LAUNCHER. Without it the app does not appear on the TV launcher at all. Note the irony: the launcher category keeps the Leanback name even though the UI toolkit of that name is deprecated.
• TV-LB — a 320x180 full-size banner and at least a 160x160 app icon at xhdpi.
• TV-BN — the banner must contain the name of the app. A logo mark alone fails.
• TV-DP — every function must be reachable with five-way D-pad controls.
• TV-DB — Back must lead to the Android TV home screen.
• TV-DM — the app must not depend on the remote having a Menu button.
• TV-LO — landscape, with no vertical letterboxing or pillarboxing, and only black bars on original-format video.
• TV-OV — nothing may be partially cut off by the screen edges. This is the overscan rule, and it is why a design that looks correct in a browser preview can lose its top navigation row on an actual television.
• TV-TR — the app fills the screen with a non-transparent background and does not partially obscure other apps.
• TV-G1 — Android App Bundles are mandatory for all new and existing TV apps in the Google Play Store.

Android TV app development for broadcasters tends to run into TV-DP and TV-OV hardest, because broadcast design language assumes a full-bleed image and a lot of simultaneous on-screen information — both of which have to be rethought once every element needs a focus state and a safe margin.

Design the focus states before the screens. On a touch device, focus is invisible and optional. On a TV it is the entire navigation model, and retrofitting it after the visual design is signed off means redoing the visual design.

The target API bar is lower here, and that is a trap

From 31 August 2026, Google Play requires new apps and app updates to target Android 16, API level 36. Android TV apps are excepted and need only Android 14, API level 34, or higher, and existing Android TV apps can target as low as Android 13, API level 33.

That sounds like a gift and behaves like one — until you are maintaining a phone app and a TV app from one codebase and one release process. Two different target levels on two different tracks with two different deadlines is a compliance calendar, not a footnote, and it is the sort of thing that quietly lapses when the person who knew about it changes team.

We track it as part of the build rather than leaving it to be remembered.

Where Android TV is genuinely easier than the phone

Two things go your way here, and it is worth knowing them before you scope.

PlayReady is available. Android's DRM documentation lists Widevine cenc and cbcs across Android, and additionally lists PlayReady SL2000 cenc for Android TV, covering DASH, SmoothStreaming and HLS in fragmented MP4. If your existing licence infrastructure was built around PlayReady — common where the OTT service grew out of a broadcast or operator stack — Android TV can consume it directly, while a phone build is limited to Widevine.

The device is predictable. A television is mains-powered, permanently landscape, on a fixed screen, and not competing with phone calls or a dying battery. The lifecycle edge cases that dominate a mobile player are largely absent.

Android TV app development for vod platforms benefits most from the second point: the playback session is long, uninterrupted, and rarely backgrounded, which makes buffering strategy and bitrate ladder tuning far more predictable than on a phone.

What carries over from your phone app

The honest split, if you have an Android app already:

Carries over. Your player layer and its DRM integration. Your API client. Your entitlement and authentication model. Your catalogue metadata. Your analytics contracts. Most of your Kotlin business logic.

Rebuilt from scratch. The entire UI layer, because Compose for TV is its own component set with its own focus semantics. Navigation, because D-pad traversal is a graph you design rather than a gesture the OS handles. Typography and spacing, because the reading distance is three metres. Onboarding and sign-in, because typing an email address on a remote is the worst experience in the product — which is why device-code pairing against a second screen is worth building rather than avoiding.

Android TV app development for telcos usually adds one more: an operator build often has to sit inside a launcher or a bundled channel line-up, which is a distribution conversation as much as an engineering one.

What drives the cost

A range that fits everyone helps nobody, so here is what actually sets the number.

1. Whether you have an Android app already. Sharing a player and API layer with an existing phone build is the single biggest saving available on this platform.
2. The size of your navigation graph. Every screen needs a defined focus order. Ten screens is a different project from forty.
3. Sign-in and entitlement. Device-code pairing, if you want it done properly, is its own slice.
4. Whether Fire TV follows. Fire TV is Android-based but is a separate store, a separate review and a separate remote. Scoping both together costs far less than discovering the second one later.

Tell us those four and you get a real number rather than a range that covers everyone.

Who builds it

Everything above is how we actually work rather than a checklist assembled for this page.

We build our own tooling. VibeView came out of exactly this problem — shipping to every platform means testing on every platform — and it drives TV interfaces with a native focus-walk rather than blind d-pad chaining, because a focus bug is the defect a TV app ships with most often. When a project needs middleware rather than only an app, MwareTV is a technology partner of ours, so both sides come from one conversation.

And the people who scope your project are the people who build it. There is no account layer between you and the engineer who knows why TV-MT is in your manifest.

Where Android TV sits in the rest of your rollout

Android TV is usually the second or third platform, and it is the one that proves whether your shared layer was actually shared. If the player and entitlement model were built with a second surface in mind, this is a UI project. If they were built for a phone and nothing else, this is where you find out.

Fire TV is the natural next step, and the two are close enough that scoping them together is almost always cheaper than sequencing them.

We build these, end to end

The Compose for TV interface, the focus and navigation model, the player and DRM integration, device-code sign-in, the App Bundle and Play submission, and the compliance pass that keeps both your TV and phone tracks inside their target API deadlines.

If you have a Leanback app today, we will tell you honestly whether it needs migrating now or whether it can wait — deprecated is not removed, and we would rather move it when there is a reason than bill you for a rewrite you did not need.

Send us your current stack, whether an Android phone app already exists, and the platforms you expect to be on in two years. You will get back a scope and a number rather than a brochure.