Android streaming app development

The deadline you are already inside

From 31 August 2026, Google Play requires new apps and app updates to target Android 16 (API level 36) or higher. Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running an Android version above what the app targets.

Miss it and nothing dramatic happens on day one. Your app stays in the store. Your existing users keep it. What changes is that a new user on a newer phone can no longer install it — so the symptom is not an error, it is an install graph that flattens while everything on your dashboard looks healthy.

Google Play does allow an extension to 1 November 2026 if you need one. That is worth knowing about, and it is worth not needing.

Two things follow from this that shape how we scope Android work:

1. Plan for an annual compliance pass. Budget for one every year, not only for the build. A team that treats the launch as the end of spend discovers the cost in the month the app stops installing.
2. Targeting a new API level is not the same as supporting it. The target level is what you compile and declare against; the minimum level is how far down the device range you reach. They are separate numbers and they are decided by different things — the target by Google's calendar, the minimum by your DRM.

Your DRM decides your minimum version

This is the decision most quotes skip, and it is the one that moves the number.

Android's own DRM documentation is specific about which scheme arrives when:

DRM scheme	Android version	API level	Formats
Widevine "cenc"	4.4	19	DASH, HLS (FMP4 only)
Widevine "cbcs"	7.1	25	DASH, HLS (FMP4 only)
ClearKey "cenc"	5.0	21	DASH
PlayReady SL2000 "cenc"	Android TV	Android TV	DASH, SmoothStreaming, HLS (FMP4 only)

Read the second row carefully, because it is the expensive one. cbcs is listed from Android 7.1, API level 25. If your packaging pipeline standardised on cbcs — which is common, because it is what Apple's ecosystem uses and it lets you encrypt once for both — then your practical minimum on Android is API 25, not the API 19 the first row seems to promise.

And the column everyone misses: HLS is listed as FMP4 only. If your HLS ladder is MPEG-TS, protected playback does not work on Android, whichever Widevine mode you chose. The fix lives in your packager, not in the app, and it is the single most common late discovery on an Android build — usually found by a tester on a real device a fortnight before launch.

Android streaming app development for broadcasters tends to hit this hardest, because a broadcaster's existing HLS ladder was often built for a web player and a set-top box years before anyone asked for a phone app. It works everywhere it has always worked, and then it does not work here.

So the sequence that saves money is: confirm your encryption mode, confirm your container, and only then pick a minimum API level. Doing it in the other order is how a project acquires a re-packaging workstream nobody scoped.

Offline is its own project

Download-to-watch reads like a feature flag and behaves like a subsystem.

Media3 supports offline playback through stored key sets — you pass a key set ID when you build the media item and playback uses the keys held against it. But Android's documentation carries a known issue here: only one offline key set can be specified per playback, so offline playback of multi-key content only works when the licence server is configured to hand back a single set.

If your catalogue encrypts audio and video under separate keys, that constraint is about your licence server, and you want to know before the sprint that builds downloads rather than during it.

Android streaming app development for vod platforms usually includes downloads, because it is the feature a subscriber notices on a plane. It is worth scoping as its own slice of work rather than as a checkbox on the player.

Play review has no committed timeline either

Google does not publish a review SLA. Its guidance refers to review times of up to 7 days, or longer in exceptional cases, and it is explicit that some developer accounts get a more thorough review.

The practical read: if you are shipping under an established developer account with history, review is usually quick. If a broadcaster has just created a fresh account for a new brand, treat the first submission as the slow one and get it in early — ideally with a throwaway internal release, so the account has cleared review once before the release that has a marketing date attached to it.

Android streaming app development for fast channel operators runs into this most often, because a FAST channel launch tends to come with a date that was agreed with partners months earlier and is already fixed.

Get your first submission in before the build is final. An internal or closed testing track release costs you nothing and turns the unknown review duration into a known one, well before the release that actually matters.

What carries over from what you already have

The honest split, if you have a web player or another platform's app today:

Carries over. Your API layer and entitlement model. Your catalogue metadata and its taxonomy. Your DRM licence server, assuming the packaging above lines up. Your analytics contracts. Your design tokens.

Does not. The player integration, because the Android player stack has its own architecture rather than mirroring what your web player does. Lifecycle handling, because a phone call, a backgrounded app and a lost network are states a web player never had to survive gracefully. Download management and its storage rules. Cast, picture in picture, and notification-surface playback controls, each of which is a small project wearing a checkbox.

The phrase to be suspicious of is "we already have the player logic". What you have is the policy; the implementation is platform-specific.

What drives the cost

A range that fits everyone helps nobody, so here is what actually sets the number. Four things, and you already know three:

1. Your minimum API level, which your DRM and packaging decide before your designer does.
2. Whether downloads are in scope. This is the single biggest swing on a mobile streaming app, for the reasons above.
3. Your surfaces. Cast, Auto, picture in picture, widgets, notification controls. Each is real work and each is easy to leave out of an estimate.
4. What follows Android. If iOS ships next quarter and Android TV after that, the shared layer is worth building deliberately the first time.

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 the problem described here — that shipping to every platform means testing on every platform, and on Android "every platform" means a device matrix rather than a single phone. 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 your HLS ladder has to be fragmented MP4.

Where Android sits in the rest of your rollout

Android is usually the platform where the shared layer gets defined, because it is where the awkward questions surface first — offline, entitlement edge cases, the device matrix. Get it right here and Android TV becomes a new presentation layer rather than a new project, and iOS becomes a port of decisions rather than a rediscovery of them.

Which is why we would rather scope the whole rollout up front, even when we build it one platform at a time.

We build these, end to end

The app, the Media3 player integration, the DRM and packaging work that has to happen alongside it, downloads, Play Console submission, and the annual compliance pass that keeps the app installable.

If Android is your first platform, we will scope it so the next one reuses the player abstraction, the entitlement model and the API layer. If you already have an Android app that fails on protected content or has drifted out of target-API compliance, we will tell you straight whether it is worth fixing or worth rebuilding.

Send us your packaging setup — encryption mode and container — your download requirements, and the platforms you expect to be on in two years. You will get back a scope and a number rather than a brochure. If you are not sure what your packaging does today, start there: it decides more about this project than any choice we will make together.