Five Ways to Get an Android Games Catalogue. The Only Question That Separates Them Is Who Rebuilds It Next August.

Before you buy Android games for a catalogue app, price each sourcing route by who owns the next Google Play deadline, not by the cost per title.

Every comparison of Android game sourcing I have seen is a price table. Cost per title, minimum order, revenue share. That table tells you almost nothing, because an Android games catalogue is not a purchase — it is a maintenance obligation with a purchase at the front of it. Google Play moves its floor every year, on published dates, and when it moves, somebody has to open every project, rebuild every binary and resubmit. The five routes below differ enormously in who that somebody is. Two of them put it on you.

📅 The Deadline That Just Passed, and the One in February

Two dates decide the shape of this decision right now, and both are published by Google rather than inferred.

31 August 2026. Per Google's own target API level requirements, new apps and app updates must target Android 16 (API level 36) or higher to be submitted to Play. Existing apps must target at least Android 15 (API 35) to stay available to new users on devices running a newer Android than the app targets. Developers could request an extension to 1 November 2026. That deadline was four days ago. If your catalogue app is sitting on API 34, it is not gone — installed users keep it — but it has stopped reaching the new users you are paying to acquire, and nobody sent you an email about it.

1 February 2027. Android's 16 KB page size documentation states that from that date, updates that do not support 16 KB memory pages on 64-bit devices cannot be released for apps targeting Android 15 or higher. Note what the requirement actually catches: if an app is pure Java or Kotlin, including its libraries, it already complies. If it contains any native code — a C++ engine, a third-party ad SDK, a physics library — the binaries have to be rebuilt against NDK r28 or later.

That last point is where a games catalogue differs from an ordinary app portfolio. Games are the category most likely to ship native code. Worth saying plainly: this date has moved twice. It was first announced as 1 November 2025, then shifted, and Google's current documentation says 1 February 2027. Plan against the published date, and assume it can move again — in either direction.

🧭 Five Routes to the Same Shelf

Set aside price for a moment. Here is what each route actually hands you, and what it leaves in your lap.

1. Buy source code from an asset marketplace and reskin

You get a project folder. Genuinely good at: one title, cheap, fully yours to modify, and you can ship a bespoke reskin nobody else has. Where it stops: the maintenance obligation transfers to you completely and immediately. Fifty titles from an asset marketplace is fifty engine versions, fifty ad SDK integrations, fifty sets of native libraries and fifty separate rebuilds every time Play moves the floor. The unit cost looked like a bargain in January and became a headcount line by August.

2. License ready-built APKs from a games licensor

You get finished, signed-off builds against an agreed target API, delivered as a batch. Good at: volume, speed, and predictable compliance — provided the licence says who rebuilds and when. Where it stops: you are working inside somebody else's build pipeline, so deep customisation is limited to whatever the licence covers. This is the route that scales to hundreds of titles without scaling your engineering team, and it is the one where the contract does the heavy lifting rather than the code.

3. License HTML5 games and wrap them for Android

You get one app instead of a hundred, with the catalogue delivered inside it. Good at: a single binary to maintain, instant catalogue updates without a store release, and one code path across web and Android. Where it stops: Play's minimum functionality rules, discussed below, and the fact that hosting rights for the web builds must be explicit in the licence — you cannot cache or bundle a game somebody else is hosting for you.

4. Commission a studio to build originals

You get exactly the game in the brief, and usually you own it. Good at: one flagship title with a mechanic nobody else has. Where it stops: throughput and cost. If your need is "one branded game for a trade-show booth" or "the hero title for a product launch", this is the right answer and no catalogue licence substitutes for it. Say it plainly — a commissioned original beats a licensed one when the game itself is the differentiator.

5. Build in-house

You get a team. Good at: a single product you intend to run for years, iterate weekly and monetise deeply. Where it stops: catalogue economics. A team that can ship four good titles a year cannot fill a store shelf that needs eighty, and the compliance work still lands on that same team every August.

🔁 The Real Criterion: Titles Per Deadline, Not Cost Per Title

Here is the arithmetic nobody puts in the business case. Take your catalogue size, multiply by the number of published Play deadlines in a rolling twelve months, and you have the number of rebuilds your operation must absorb. At two catalogue-wide events a year — the target API bump plus something like the 16 KB requirement — a 200-title reskin portfolio is 400 rebuild-and-resubmit cycles a year. Each one is a project open, a dependency bump, a regression test on real hardware and a store submission that can be rejected.

This is why route 3 keeps winning for operators who did the maths. One app, one binary, two rebuilds a year, and the catalogue behind it changes without touching the store at all. It is also why route 2 lives or dies on a single clause: does the licensor rebuild and redeliver on platform deadlines, at whose cost, and within how many days? A licence that hands you APKs and goes quiet on that question has sold you a depreciating asset.

🏪 Repetitive Content Is the Reskin Route's Real Ceiling

Play's Developer Program Policy on spam and minimum functionality does not allow apps that merely replicate the experience of apps already on the store, and it names apps built from templates or automated wizards specifically. It also advises developers with several thin apps offering the same functionality to consolidate into one.

Read that against a plan to publish sixty reskinned puzzle games as sixty separate listings from one account. That is precisely the shape the policy describes. It is not a hypothetical risk, either: TechCrunch reported in April 2025, citing Appfigures data, that Google Play's app count fell roughly 47% — from about 3.4 million to around 1.8 million — between the start of 2024 and April 2025, which Google attributed to tougher policies against apps with minimal content or functionality. Over the same window Apple's App Store count was roughly flat.

The operational read: a licensed catalogue delivered as one app with many games inside it is structurally safer on Play than the same catalogue published as many apps. If your plan needs individual listings — for search coverage, or because a carrier requires them — then each listing needs to be genuinely differentiated, and you should budget approval risk into the schedule rather than assuming a clean run.

🌐 The Wrapper Route Meets Policy 4.3

The obvious objection to route 3 is that Play rejects WebView wrappers. That is half right, and the half that is wrong is the half that matters.

Play's minimum functionality policy targets apps that provide no more than a website already does — a browser window with a fixed URL. A games catalogue app is not that, provided it behaves like an app. In practice that means: native navigation and category browsing rather than a web page's own menu, offline handling that does something sensible when the connection drops, local favourites and recently-played state, push notifications if you have earned the right to send them, and correct back-button and lifecycle behaviour. A Trusted Web Activity over a proper PWA, or a Capacitor-style build, is the conventional compliant construction.

The licence has to support it. If the games are hosted on the licensor's origin and embedded cross-origin, your app cannot cache them for offline play — a service worker cannot reach across an origin boundary it does not control. That is a licensing question about hosting rights, and it has to be settled before the build is scoped, not after the rejection.

🔑 The Developer Account Is the Asset Nobody Negotiates

Whose Play account publishes the app determines who carries the policy record, who receives the enforcement notices, and who can still ship on a bad week. Two facts worth knowing before that conversation.

First, per Google's app testing requirements, personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access. (That threshold was 20 testers when the policy launched; Google reduced it to 12, which is why older write-ups — including the TechCrunch piece above — cite the higher number.) Organisation accounts are not subject to it. If your route depends on spinning up a fresh account for a client campaign, that is a fortnight you have not budgeted.

Second, an account carries its history. A repetitive-content strike against a reskin portfolio published from your account is a mark on your account, not the asset seller's. If you are an agency publishing on behalf of clients, decide deliberately whether each client publishes from their own organisation account or you concentrate the risk in yours.

🧾 Four Scenarios, Decided

• An OEM or carrier wants a games app preloaded on a device fleet. One app, licensed catalogue inside, native shell. Route 3, or route 2 if the partner insists on native builds. Not the reskin route — a preload slot holds one app, and the maintenance burden of many is the thing that kills the relationship in year two.
• A publisher wants 150 Android titles live in eight weeks. Route 2, with a rebuild-on-deadline clause. No studio ships 150 originals in eight weeks, and 150 marketplace projects is a rebuild treadmill you will still be walking in 2028.
• A brand wants one game for a product launch, with its own characters. Route 4 — commission it — or a branded licence where the IP is already cleared. A generic catalogue does not solve this and pretending otherwise wastes the client's quarter.
• A studio wants a single title it will run for five years. Route 5. Build it. Own the roadmap. Licensing is the wrong instrument when the product is the game.

📋 Nine Questions for Any APK Supplier

1. What target API level do the builds currently ship against, and what is your commitment when Play moves it?
2. Do the builds contain native code, and are they already 16 KB page aligned?
3. Who rebuilds on a platform deadline, at whose cost, and within how many days of the announcement?
4. Who signs the APKs, and whose Play account publishes them?
5. Does the licence cover alternative Android stores and OEM preloads, or Play only?
6. Are HTML5 and APK builds of the same titles available under one licence conversation, or two?
7. What age ratings and content declarations come with each title, and are they per-territory?
8. Can I bundle the games for offline play, or must they load from your origin?
9. What happens to my live app if you stop delivering — do I keep shippable builds?

Ask these of every route, including the in-house one. Question 3 alone reorders most shortlists.

🚫 Five Ways an Android Catalogue Plan Goes Wrong

• Budgeting acquisition and not maintenance. The catalogue is bought once and rebuilt indefinitely. Model the second year.
• Publishing many thin apps because the spreadsheet says more listings equals more installs. Play's policy on repetitive content says otherwise, and enforcement has been real.
• Assuming a web build wraps cleanly. Hosting rights, offline caching and minimum-functionality all have to be settled in the licence first.
• Treating the developer account as plumbing. It is the thing that can be taken away, and the 14-day testing gate on new personal accounts is not skippable.
• Ordering titles by count instead of by rebuild cost. Two hundred titles from one pipeline is a smaller operation than forty from twelve.

🎯 What You Get When You Buy Android Games From a Direct Licensor

Licensing direct means the scope conversation happens once, across formats. Forestry Games has operated since 2017 and licenses a catalogue of 1,049 titles spanning HTML5 games and Android APK games, with titles also published on Google Play and the Apple App Store — so the HTML5-versus-APK question above is a delivery decision inside one licence discussion rather than two separate procurements. A licence typically covers HTML5 builds, APK builds, source where applicable, branding options and hosting arrangements, scoped to your platforms and territories. For a portal or catalogue app, the practical work is agreeing which slice of the 1,049 fits your audience and which formats you need it in. You can browse the Android games catalogue, look at the HTML5 titles for the wrapper route, or review what is available on a source-code basis if you intend to reskin. Ask for a licence scope in writing, and make question 3 above one of its clauses.

🧸 Licensing Branded Games for Apps, Portals and Campaigns

Some catalogues need a recognisable character rather than another puzzle title. Forestry Games works with branded IP and has brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros, and businesses can license branded game content through it for campaigns, portals, events and apps. Branded titles carry approval and compliance steps that generic titles do not, so raise them at scoping rather than at launch — the calendar is the thing that bites, not the fee. If a branded title is part of the plan, ask for the scope and the approval path in the same conversation as the base catalogue.

✅ Do the Rebuild Count This Week

Open your roadmap and write down two numbers: how many separate Android binaries you will own twelve months from now, and how many people can rebuild and resubmit one. If the first number is bigger than the second can absorb across two platform deadlines a year, the sourcing route is wrong regardless of the price per title — and the fix is structural, not commercial. Route 3 collapses the first number to one. Route 2 moves it onto somebody whose job it is. Both are cheaper in year two than the option that looked cheapest in year one.

If you are at that decision now, the useful next step is a scope, not a quote: name your platforms, your territories, your target API commitment and whether you need offline play, then ask a licensor to price that scope against the catalogue. The price you get back will mean something.