Monetizing an Android app when you will not ship ads

The situation is common enough to be a genre. You have an Android app with real daily active users. You are not going to put ads in it, because you have seen what interstitials do to a retention curve. In-app purchases do not fit, because there is nothing in the product to sell. A subscription is out, because nobody subscribes to a utility they open twice a month.

So what is left?

Four things, honestly. Three of them are well covered elsewhere and one of them is what we build, so we will do the other three first and quickly.

The three you already know about

Sponsorship or a placement deal. Real money, and it scales with your audience's specificity rather than its size. A niche tool with 40,000 committed users is easier to sell than a general one with 400,000. It is also labour — you are now doing business development, every month, forever.

Selling anonymised, aggregated data. Legally live territory, reputationally expensive, and the disclosure required to do it properly usually costs more goodwill than the revenue is worth. We would not.

A paid companion or pro app. Works when there is a genuine power-user segment. Mostly it fragments your install base and doubles your release process for a conversion rate in the low single digits.

That is the honest short version. If you want the numbers behind each, what apps make per download has per-category ranges and conversion rates.

The fourth: bandwidth sharing

The user opts in, and a capped share of the bandwidth their device is not using gets relayed for public web data collection. No advertisement renders. No paywall appears. Their session is the session they already had.

It pays up to $0.50 per user per month. A user counts for a day once their device has been sharing for 60 minutes in that day, each qualifying day is worth one day's share of the monthly rate, and the month is the sum of its days. Devices on hosting, datacenter or VPN IPs are not counted.

That is not subscription money. What it is: revenue that arrives without you changing a screen, and it stacks on anything else you run.

The rest of this post is the Android-specific part — the things that decide whether this works on the platform, which the marketing pages tend not to cover.

The foreground service is the whole integration risk

Any SDK that maintains a network connection on modern Android runs in a foreground service, and foreground services on Android have a hard rule that breaks apps: once you start one, you have roughly five seconds to call startForeground() or the system kills your process.

This is not theoretical. We shipped a version where the SDK started its service, did its initialisation, and then foregrounded. On fast hardware that was fine. On a cold boot on slow hardware, initialisation ate the budget and the app crashed on every single boot.

Three things came out of that, and they are worth knowing whichever vendor you pick:

• startForeground() must be called first — before the SDK, before the network, before any early return. The notification has to be constructible before configuration has loaded.
• stopSelf() does not settle the debt. A service started that way still owes a startForeground() even if it stops immediately.
• An emulator will not reproduce this. Emulators finish cold init well inside the deadline. If your SDK vendor tells you they tested on an emulator, they did not test this.

Ask your vendor directly: what happens on a cold boot on a low-end device, and how do you test it? A vendor who has hit this will have a specific answer, because it is memorable.

Google Play, disclosure, and what nobody can promise you

Play's policies require that background network use is disclosed to the user and consented to. That is the requirement, and it is satisfiable.

What it means architecturally is that the SDK must be incapable of transmitting anything before the user has accepted an agreement they were actually shown. Not a toggle in settings defaulted on. Not a clause in a licence. A hard gate.

What no vendor can give you is a guarantee about your listing. The app is yours, the Data Safety declarations are yours, and any vendor promising a store outcome is promising something they do not control. Be suspicious of one who offers it.

The device mix decides your revenue, not your DAU

Two Android apps with identical daily active users can earn very different amounts, and the reasons are all about the device rather than the app:

• Connection type. Data caps are tighter on mobile data than on WiFi, so a user who is mostly on cellular contributes fewer qualifying days.
• Country. Rates are per country, and a rate card without your geo mix next to it is a number that misleads.
• Excluded IPs. Devices on hosting, datacenter or VPN IPs are not counted. If your audience skews technical, this will take a real bite.
• Session length. The 60-minute daily bar is a bar. An app people open for 90 seconds twice a day will not clear it on its own.

That last one is the one people miss. If your app is a quick-glance utility, the sharing has to continue while the app is backgrounded for a day to qualify at all, and whether that is acceptable is a product decision you should make deliberately rather than discover.

What this costs you in the APK

A native core ships per-ABI shared objects. Ask for the per-architecture figure rather than the total, and if you are size-sensitive, ask whether you can split by ABI in your bundle — which you can, and which most vendors will not mention.

Ask also what happens on the network transitions Android does constantly: WiFi to cellular mid-transfer, process death, doze. "It reconnects" is not an answer; "it stops and checks back later" is.

Doing this properly takes an afternoon

1. Read the consent screen the SDK will show. If you cannot see it before integrating, stop.
2. Ask which limits you can change. The correct number is zero.
3. Ask what happens under sustained load. "Opts out" beats "throttles".
4. Integrate behind a feature flag.
5. Ship to 1% of users. Watch crash-free rate, ANRs and retention for a week.
6. Widen only if all three are flat.

Step 5 is the one that catches the foreground-service class of bug, and it is the only step that cannot be undone cheaply.

The eight questions to put to any vendor covers the evaluation in more depth, and the Android page has our integration specifics.