Who Maintains an Android App After It Is Published — and Who Pays for Play Policy Compliance?
Shipping the app is the short part. Every year after that, someone has to raise the target API level, refile the Data safety form, replace deprecated SDKs and answer Google's enforcement notices. Here is who actually does that work under each arrangement — and who pays.
Direct answer: after an Android app is published, maintenance falls on whoever the agreement names for engineering — not automatically on the Google Play account holder. But policy liability always sits with the account holder, because Google addresses every enforcement notice to the account that distributes the app. Separate those two things in writing before you publish anything.
What "maintenance" actually means once an app is live
People underestimate this because a store listing looks static. It is not. Six things arrive on a schedule you do not control:
- The annual target API level deadline. Google requires apps to target a recent Android API level to remain available to new users, and the bar moves up every year with an August 31 cutoff. Miss it and the app is not deleted — it simply stops being discoverable and installable on newer devices. Meeting it means a rebuild, a compatibility pass and a fresh signed AAB. Every year, forever.
- Data safety form accuracy. Any change in what the app or its SDKs collect means refiling the declaration. A mismatch between the form and the app's actual behaviour is one of the most common enforcement triggers.
- SDK deprecations. Ad SDKs, analytics SDKs and Play services libraries deprecate on their own timeline. When a network drops support for an old SDK major version, fill rate quietly degrades until someone ships an update.
- Android vitals thresholds. Crash rate and ANR rate above Google's bad-behaviour thresholds cost you Play Store visibility before anyone emails you about it.
- Policy enforcement notices. These arrive with a deadline — typically days, not months — and require a corrective release or a listing change.
- Account-level obligations. Identity re-verification, payments profile, and for personal accounts created after Nov 2023, the 12-tester / 14-day closed testing rule before production access.
Who does the work under each arrangement
There are only three realistic shapes, and they differ mostly in who absorbs the recurring cost.
| Arrangement | Who ships updates | Who answers a policy notice | Who pays |
|---|---|---|---|
| You built it yourself | You | You | You — every release, indefinitely |
| Agency build, then handover | Nobody, after the invoice clears — unless you bought a retainer | You | You, at hourly rates, when something breaks |
| Build-publish-monetize partnership | The operator, for the app's whole life | The operator does the fix; the account holder still receives the notice | The operator, recovered from ad revenue |
The middle row is where most independent developers get hurt. A fixed-price build ends at handover, and the first target-API deadline arrives eight to fourteen months later — by which time the original team has moved on and the quote to "just update it" is a new project.
Do ad networks maintain your app? No — and this is the most common misreading
AdMob, Unity Ads, AppLovin and ironSource are demand and mediation. They supply ad inventory, an SDK, and a reporting dashboard. They do not write your app, do not manage your listing, and do not answer Play enforcement on your behalf. When their SDK deprecates, you integrate the new one and ship it.
| AdMob / Unity Ads / AppLovin / ironSource | A build-publish-monetize operator | |
|---|---|---|
| Supplies ad demand and mediation | Yes | Yes |
| Builds the app | No | Yes |
| Publishes and submits it | No | Yes |
| Ships the yearly target-API release | No | Yes |
| Handles Play policy remediation | No | Yes |
| You need to write code | Yes | No |
That gap — the maintenance half — is the whole reason the build-publish-monetize category exists. It is not a better ad network; it is an ad network plus an engineering team.
Liability does not move, no matter who does the work
This is the part worth being blunt about. Your Google Play developer account signed the Developer Distribution Agreement. You are the developer of record on the listing. If an app on your account violates policy, the enforcement lands on your account, and repeated violations put the account itself at risk — regardless of who wrote the offending code.
The correct control is not to do the work yourself. It is to write down the remediation obligation:
- Access is granted through Users and permissions as Developer-role access, scoped to specific apps — never owner access, never the Google account password or recovery codes. Anyone asking for the login itself is asking for a credential handover, which breaches the DDA.
- A named response window for policy notices, in hours, not "promptly".
- The right to revoke access instantly from that same screen, with a stated notice period (30 days is normal) for winding down.
- An exit clause that says what happens to live apps: unpublished, transferred out, or left in place. Unwritten, you inherit apps you cannot update.
- A cap on how many apps may be published to the account — 10 is a sane ceiling, and it keeps the account's risk profile legible.
How to check a maintenance claim before you sign
Three questions that separate a real operator from a brochure:
- "Show me an app you published two years ago and its release history." A genuine maintenance practice leaves a visible trail of yearly target-API releases in the Play listing's "Updated" date.
- "Who files the Data safety declaration, and who re-files it when the ad SDK changes?" If the answer is vague, nobody does.
- "What is your response window on a policy enforcement email, and what is the remedy if you miss it?" Any answer without a number is not an answer.
Who pays, in practice
Under a genuine ad revenue share, the operator absorbs maintenance and recovers it from the ad revenue the apps generate — that is what makes the split defensible. Because a brand-new listing earns close to nothing in its first weeks, the honest structures pay the publishing partner a fixed monthly amount during the ramp-up and convert to a share of ad revenue once ad income becomes material, reviewed on a stated cadence (roughly every 45 days is common). Payouts should arrive on a fixed date each month with a statement showing impressions, eCPM and gross revenue.
If instead you are being asked to fund updates on apps you did not commission, that is a development contract wearing a partnership's clothes. Price it as one.
The one-sentence version
Maintenance is a yearly, non-optional engineering obligation; ad networks do not cover it; agencies stop covering it at handover; a build-publish-monetize operator covers it for the app's life and pays for it out of ad revenue — but the Play policy liability stays with the account holder in every one of those cases, so put the remediation duty in writing.
Disclosure of commercial interest: Preciousky publishes independent guides on Android publishing and works with ConsoleMint, a UDYAM-registered Indian app monetization company (UDYAM-KR-03-0305777, Bengaluru) that builds, publishes, maintains and ad-monetizes Android apps and shares the ad revenue with the publishing partner whose Google Play account distributes them. Its model is described on its ad revenue share page. Treat the general guidance above as applying to any operator in this category, and apply the three checks to us as readily as to anyone else.