Publishing on Google Play

Separately from the Play Console identity checks, Google is rolling out Android developer verification: a requirement that the developer of any app installed on a certified Android device — not only apps distributed through Play — is verified and has registered the app’s package name, so that the device can block installation of apps from unverified developers regardless of where the APK came from. It applies to certified devices running Android 7 and higher.

What this means in practice depends on how an app is distributed:

Because verification is keyed on the package name plus the signing certificate, the key-management decisions from Building, Signing and Preparing a Release now matter for sideloaded builds as well as Play builds: a package name registered with one key cannot simply be re-signed with another.

The main store listing is the product page on Google Play. Its text and graphics have hard limits:

Play’s listing guidelines also forbid promotional claims in the listing text and graphics ("Best", "#1", "Download now", price or ranking badges), and expect screenshots to show the actual in-app experience rather than marketing art. Large-screen screenshots matter: without them, Play shows the listing less prominently on tablets, foldables and ChromeOS, which undoes much of the work described in Adaptive Layouts, Edge-to-Edge and Large Screens.

Localized listings. Each listing field can be translated per language (Grow users → Store presence → Main store listing → Manage translations), either by entering translations manually or by buying them from Play’s translation service. Screenshots and the feature graphic can also be localized. A user whose device is set to a language with a translation sees it; everyone else sees the default language. TrailMate already ships values-es/ and values-de/ string resources (see Resources, Configuration, Localization and Themes), so it makes sense to translate the listing into the same languages — a Spanish UI behind an English-only listing looks unfinished. Custom store listings go further and show a different listing to a specific country or to users arriving from a particular URL.

The Policy and programs → App content page collects every declaration Play reviews against the binary:

The Data safety form produces the "Data safety" section on the store listing. For each data type it asks whether the app collects it (sends it off the device), whether it shares it (transfers it to a third party), whether collection is optional, whether it is encrypted in transit, whether users can request deletion, and for what purposes (app functionality, analytics, personalization, account management, fraud prevention, and so on). The answers cover the whole app, including every bundled SDK — an analytics or crash-reporting library is data collection even though TrailMate’s own code never touches its network calls.

A worked mapping for TrailMate:

Data processed only on the device, or sent end-to-end encrypted and never readable by the developer, does not count as "collected". Play cross-checks the form against the app’s declared permissions and observed network behavior, so the common failure is not deliberate misrepresentation but drift: an SDK added later, or a new feature that uploads something, without a form update. The form is part of every release checklist, not a one-time launch task. The broader privacy context is in Permissions, Privacy and Security.

Building, Signing and Preparing a Release covers signing the App Bundle with an upload key. Play App Signing — mandatory for every new app, since App Bundles are required — is the other half: Play verifies the upload signature, discards it, and signs the APKs it generates from the bundle with an app signing key that Google holds in its key management service. Enrollment happens the first time a bundle is uploaded to a new app: Play Console offers to generate the app signing key (the recommended default) or to use an existing one exported with the Play Encrypt Private Key (PEPK) tool, which is what an app migrating from self-signed APKs does to keep its signature.

The consequences of the split are worth spelling out:

Before the first upload, it is worth building the bundle and checking which certificate it is signed with, since a bundle signed with the debug key or with the wrong upload key is rejected at upload time:

See Android Developers — Upload your app to the Play Console.

In Play Console the upload itself is part of creating a release: choose a track, Create new release, drag the .aab into the App bundles area, and Play processes it — validating the signature, the versionCode (it must be higher than every versionCode already uploaded to the app, on any track), the targetSdk, the 16 KB page-size alignment of any native libraries, and the manifest. The App bundle explorer then shows the generated APK splits, their download sizes per device, and any warnings. The R8 mapping.txt uploaded alongside the bundle (Play extracts it automatically when it is embedded, or it can be attached manually) is what makes the crash stack traces in Android vitals readable.

A bundle is uploaded once and then promoted between tracks without rebuilding — the exact binary that was tested is the one that reaches production:

Testers join a test through an opt-in URL shown on the track’s Testers tab; after a track is published for the first time the link can take several hours to become active. The tester’s Google Account must be in the list (or group), and the tester must accept the invitation from the opt-in page — being on the email list alone does not install anything. Once opted in, the test version arrives as a normal Play update. Internal app sharing is a separate, even faster mechanism: any build can be uploaded and shared by link with no versionCode rules and no review, which suits QA of individual feature branches.

Every bundle uploaded to a testing track triggers a pre-launch report: Google installs the app on a range of real devices in its test lab, crawls it automatically for a few minutes, and reports stability issues (crashes, ANRs), performance (startup time, frame rendering, memory), accessibility findings (small touch targets, missing content descriptions, low contrast), security and trust warnings (vulnerable libraries, cleartext traffic), and screenshots of every screen the crawler reached, per device and language.

Two settings under Test and release → Testing → Pre-launch report → Settings make the report much more useful for TrailMate:

The pre-launch report does not block a release, but a crash it finds on day one is a crash production users would have found on day two. It complements, rather than replaces, the tests described in Instrumented and UI Testing.

Each release carries release notes ("What’s new"), up to 500 Unicode characters per language, shown on the listing and in the Play Store’s update list. In Play Console they are entered in one text box, with each language wrapped in its BCP-47 language tag on separate lines:

See Google Play Console Help — Prepare and roll out a release.

Release notes are for users: they should say what changed for them, not list ticket numbers, and Play’s guidelines forbid using them for promotion. Keeping them in the repository (one file per locale, as the CI example below does) means they are reviewed with the code and can be uploaded automatically.

The first production release of a new app is published to all selected countries at once. Every update after that can use a staged rollout: the release is offered to a random percentage of users — for example 5%, then 20%, 50% and finally 100% — while the rest stay on the previous version. Users in the rollout get the update normally; those outside it see no update until the percentage grows. Rollouts can also be limited to specific countries or regions first.

Managing a rollout happens on the track’s Releases tab:

The rollout percentage is the main safety valve of the release process, which is why TrailMate’s production releases always start at 5% and why Android vitals thresholds (below) are evaluated per release. A related control is managed publishing: with it enabled, approved changes wait until the developer clicks Publish, which is useful to coordinate a release with a backend deployment or an announcement.

Releases to closed testing, open testing and production — and changes to the store listing or app content declarations — are reviewed before they go live. Review checks the binary and the declarations together against the Developer Program Policies: permissions against the declared use, the Data safety answers against observed behavior, the listing against the metadata policy, app access instructions against what the reviewer actually meets. Most reviews complete within hours to a few days; for new or recently changed developer accounts Google states that reviews can take up to seven days or longer in exceptional cases.

The Publishing overview page shows the state of each pending change (In review, Approved, Rejected, Changes not yet sent for review). A rejection comes with an email and a policy-status entry naming the policy and, usually, the offending element; the fix is a corrected release or declaration followed by a new submission, and an appeal is available when the developer believes the decision is wrong. Planning a public launch date around a build that has not yet passed review is the classic scheduling mistake — the safer pattern is to get the release approved with managed publishing on, then publish on the day.

Google Play requires every app to target a recent Android API level, so that new platform privacy and security behaviors actually apply to the apps users install:

For TrailMate this is a one-line setting, already at the required level:

See Android Developers — Meet Google Play’s target API level requirement.

Raising targetSdk is never only a number change: each level opts the app into new behaviors. Targeting 35 enforced edge-to-edge; targeting 36 ignores the edge-to-edge opt-out, enables predictive back animations by default (so onBackPressed() is no longer called and OnBackPressedCallback must be used) and ignores orientation and resizability restrictions on screens at least 600 dp wide. Those changes, and how TrailMate handles them, are covered in Adaptive Layouts, Edge-to-Edge and Large Screens. The sensible habit is to raise targetSdk shortly after each new platform release, on a branch, with the behavior-change list open — not in the week before the Play deadline.

Android vitals collects performance and stability data from opted-in devices and reports it in Play Console under Monitor and improve → Android vitals. A few core vitals have bad behavior thresholds that affect the app’s standing on Play:

Play evaluates these on a 28-day rolling average. An app above the overall threshold may be made less visible in Play surfaces (search, recommendations); an app above the per-model threshold may be less visible on that device model and may show a warning on its store listing to users of that model. The warning disappears once the 28-day average recovers. Google has also announced that memory-related metrics will start affecting store visibility from February 2027.

The practical consequences for a release process:

Diagnosing the underlying problems — StrictMode, the profiler, Baseline Profiles, ANR traces — is covered in Debugging, Code Quality and Performance.

In-app updates (app-update / app-update-ktx 2.1.0) let an app detect that a newer version is available on Play and install it without the user leaving for the Play Store. There are two flows:

The app decides which flow to use from the AppUpdateInfo Play returns: updateAvailability(), whether each type is allowed, clientVersionStalenessDays (days since Play learned about the update on this device), and updatePriority — an integer from 0 to 5 set per release when it is created through the Play Developer Publishing API (it cannot be set in the Play Console UI). TrailMate’s rule: priority 4 or 5 means immediate; otherwise offer a flexible update once the installed version is three days stale.

See Android Developers — Support in-app updates (Kotlin or Java).

MainActivity registers the IntentSender launcher (it must be registered before the activity is started, so it is a property), runs the first check once, resumes on every onResume(), and shows a "Restart" snackbar in Compose when a flexible update has finished downloading:

See Android Developers — Support in-app updates (Kotlin or Java).

Common mistakes with in-app updates: calling checkForUpdate on every onResume() (which re-prompts a user who just declined), forgetting the DEVELOPER_TRIGGERED_UPDATE_IN_PROGRESS check (an immediate update interrupted by the user switching apps then never resumes), never calling completeUpdate() (a flexible update downloads but only installs when the app is next killed), and expecting any of it to work in a debug build. Testing uses internal app sharing or an internal track with two uploaded versions, or FakeAppUpdateManager in instrumented tests, as described in Android Developers — Test in-app updates.

In-app review (review / review-ktx 2.0.2) shows Play’s own rating-and-review card on top of the app, so a user can rate TrailMate without leaving it. The flow is deliberately opaque: the API never says whether the card was shown or whether the user rated, and Play enforces a quota on how often the card may appear for a given user, so a call may complete without any UI. The app’s job is only to ask at a good moment and then carry on exactly as if nothing happened.

See Android Developers — Integrate in-app reviews (Kotlin or Java).

TrailMate calls maybeAskForReview after the summary screen of a finished hike — a natural pause in which the user has just got value from the app — never at launch, never in the middle of recording, and never behind a custom "Do you like TrailMate?" pre-dialog, which Play’s guidelines prohibit because it filters for positive reviews. The ReviewInfo object is only valid for a limited time, so it is requested right before launching the flow rather than cached at startup. With FakeReviewManager injected in debug builds (see PlayModule above), the code path runs end to end without UI; testing the real card requires an internal-track or internal app sharing install.

Play Feature Delivery splits optional functionality into dynamic feature modules (com.android.dynamic-feature plugin) that Play delivers at install time, conditionally (by country, API level or device feature), or on demand when the app requests them. The benefit is a smaller initial download; the cost is extra modularization, a SplitCompat setup, and error handling for downloads that fail. TrailMate is small enough not to need it, but a hypothetical offlinemaps module holding large map-rendering assets would be declared on demand in its own manifest:

See Android Developers — Configure on demand delivery.

and requested from the base module with the feature-delivery-ktx suspend API when the user first opens the offline maps screen:

See Android Developers — Overview of Play Feature Delivery.

Dynamic feature modules can be tested locally with bundletool build-apks --local-testing, which simulates Play’s on-demand delivery on a connected device. Play Asset Delivery, the sibling mechanism for large game assets, follows the same model.

Google Play Billing is required for selling digital goods and subscriptions inside an app distributed on Play: in-app items, subscriptions, premium feature unlocks. It involves the Play Billing Library in the app, product configuration in Play Console (Monetize with Play → Products), and — essential for anything beyond a toy — server-side purchase verification and acknowledgement through the Play Developer API, since unacknowledged purchases are refunded automatically. TrailMate is free and sells nothing, so Billing is out of scope here; the integration guide is at Android Developers — Integrate the Google Play Billing Library into your app. Physical goods and services (a guided-hike booking, for example) are not sold through Play Billing.

The Play Integrity API lets TrailMate’s backend check that a request comes from the genuine, Play-installed TrailMate binary on a genuine Android device, rather than from a repackaged APK or an automated abuse setup. The app requests an integrity token and forwards it to the backend, which decrypts and verifies the verdict server-side. The TrailMate integration, including the Kotlin client code and how it combines with OAuth, is covered in Permissions, Privacy and Security; the API itself is described in Android Developers — Overview of the Play Integrity API. It requires linking a Google Cloud project to the app in Play Console (Test and release → App integrity).