How to Publish an App on the Play Store

"It works on my phone" is not a launch. Publishing your final-year app on the Google Play Store — a real listing, installable by anyone — is the difference between a project that runs and a project that ships. It also happens to be one of the strongest lines you can put on a resume: it proves you handled signing keys, store policy, content ratings, and review feedback, which is exactly the vocabulary Android interviews use.

The process looks bureaucratic from the outside, but it is a linear checklist: developer account → signed AAB → store listing assets → questionnaires → testing track → review. This guide walks through each step with the concrete requirements (fees, image sizes, character limits) so you do it once, correctly.

Prerequisite: a finished, tested Android app. If it still crashes on the walkthrough, fix that first — the guide on testing and debugging before submission is the pre-flight check for everything below.

Step 0 — The developer account ($25, one time)

Publishing requires a Google Play developer account:

Go to the Google Play Console and sign up. The one-time registration fee is $25 (roughly Rs. 2,100; Google bills in USD). There is no annual renewal — pay once, publish forever.
Choose the account type carefully. A personal account is right for a student project: simpler verification (a government ID like Aadhaar, PAN, or passport), and your name appears as the developer. An organization account needs a D-U-N-S number and is meant for companies — skip it unless your college incubator asks otherwise.
Verify your identity. Google verifies the ID document and may take a few days. Start this early — you cannot publish anything until verification completes.
New personal accounts face a testing requirement: before your first app can go to production, Google requires it to run in closed testing with at least 12 testers for the last 14 days. This policy exists to stop spam, and it means your timeline needs a two-week testing buffer. Plan for it (Step 5 covers the mechanics).

Use an email address you will keep — ideally a personal Gmail, not your college address, which you may lose after graduation. The account, the apps, and the signing keys are tied to it.

Step 1 — Prepare the app for release

A debug build and a store build are different artifacts. Work through this list in Android Studio before generating anything:

Application ID. The applicationId in your app-level build.gradle (e.g. com.aarav.attendanceapp) is your app's permanent identity on the Play Store. It can never be changed after the first upload, and it must be unique across the entire Play Store. The default com.example.* will be rejected — rename it now if you scaffolded with the default.

Versioning. Two fields, two jobs:

versionCode — an integer that must increase with every upload (1, 2, 3…). Google uses it to decide which build is newer.
versionName — the human string users see ("1.0", "1.1"). Any format, but keep it sane.

android {
    namespace 'com.aarav.attendanceapp'
    defaultConfig {
        applicationId 'com.aarav.attendanceapp'
        versionCode 1
        versionName "1.0"
        minSdk 24
        targetSdk 34
    }
}

Target API level. Google requires new apps to target a recent Android API level — roughly within a year of the latest Android release. Targeting an old API is the fastest way to get a rejection at upload time, so set targetSdk to a current value and test on it.

Release hygiene. Debug builds tolerate sloppiness that the store does not:

Remove or gate debug logging. Verbose Log.d calls in a release build leak internals; strip them or guard behind BuildConfig.DEBUG.
Delete test API keys, hardcoded demo credentials, and "TODO" screens. Reviewers will tap everything.
Confirm the app requests only the permissions it uses. Every permission is declared in the manifest and justified in the Data Safety form (Step 4) — an unused ACCESS_FINE_LOCATION is a red flag.
Test the release build type locally first (Build → Generate Signed Bundle produces it; install the resulting APK/AAB on a real device). Release builds enable minification (R8) which can break reflection-based libraries — catching that now saves a review cycle.

App icon. The Play Store requires a 512×512 px high-res icon (PNG or JPEG). Use Android Studio's Image Asset Studio to generate adaptive icons (foreground + background layers) so the icon renders correctly on every OEM's mask shape.

Step 2 — Build a signed AAB (not an APK)

Google Play now requires the Android App Bundle (.aab) format for new apps — not the APK. The bundle lets Google generate optimised APKs per device (smaller downloads for users); you upload one artifact.

Create the signing key. In Android Studio: Build → Generate Signed Bundle / APK → Android App Bundle → Create new… This generates a keystore file (.jks) containing your private key. Three things about this key:

Back it up in at least two places (and not only on the laptop you might format). Losing it historically meant losing the ability to update your app forever.
Enroll in Play App Signing when the console offers it (it is the default now): Google holds the upload key relationship and can reset your upload key if you lose it — this removes the historic catastrophe case.
Record the key alias and both passwords in a password manager. "android" as the password is how keys get compromised.

Automate signing in Gradle so release builds are reproducible (passwords via environment variables or local.properties, never committed):

android {
    signingConfigs {
        release {
            storeFile file(System.getenv("KEYSTORE_PATH") ?: "release.keystore")
            storePassword System.getenv("KEYSTORE_PASSWORD")
            keyAlias System.getenv("KEY_ALIAS")
            keyPassword System.getenv("KEY_PASSWORD")
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

Then Build → Generate Signed Bundle / APK → release produces app-release.aab under app/release/. Sanity checks before upload: the AAB installs and runs on a real device, versionCode is higher than any previous upload, and the app behaves identically to the debug build (minus the logs).

Step 3 — Create the app in the Play Console and fill the store listing

In the Play Console: Create app, enter the app name, default language, and declare whether it is an app or game and whether it is free or paid. Then work through the dashboard tasks — every one must be green before production release.

Store listing fields (the ones users see):

Field	Limit	How to write it
App name	30 characters	Your project name, exactly. Not "Attendance App Final Year Project 2026 Free Download" — keyword stuffing in the title is a policy violation
Short description	80 characters	One compelling sentence: what it does and for whom
Full description	4,000 characters	Features, how it works, tech highlights, contact email. Front-load the first 2–3 lines — most users never expand
App icon	512×512 px	From Step 1
Feature graphic	1024×500 px	The banner at the top of your listing; simple, readable at small sizes, no tiny text
Screenshots	At least 2; phone screenshots at natural resolution	Show real app screens in logical order (onboarding → main flow → result). No mockups of features that do not exist
Category	One	Pick the closest honest fit
Contact email	Required	An address you actually read — users will email about bugs

Write the full description the way you would explain the project to a smart friend: what problem it solves, the 3–4 headline features, and what is inside (especially if it is a student project — honesty about scope reads as confidence, not weakness). If you need help structuring the pitch, the presentation deck guide covers the same narrative compressed into slides.

Categorisation and tags affect discovery more than most students expect: a gym workout tracker belongs in Health & Fitness, an expense splitter in Finance, a medicine reminder in Medical. Miscategorised apps get poor recommendations and confused users.

Step 4 — The questionnaires: content rating, target audience, data safety

These are mandatory and where most student rejections originate. Answer honestly — Google verifies, and inconsistencies are treated as deception.

Content rating (IARC questionnaire). A ~10-minute questionnaire about violence, sexual content, language, gambling, and user-generated content. Most student apps land at Everyone or Everyone 10+. The rating must match reality: an app with unmoderated chat between strangers is not "Everyone".

Target audience and content. Declare whether the app targets children. If your app is genuinely for all ages including children (a learning app, for instance), additional Families-policy requirements apply — stricter ad and data rules. Most final-year apps declare 13+ or 18+ and avoid this entirely.

Data safety form. For each data type (location, contacts, photos, app activity…), declare whether you collect it, why, and whether it is shared with third parties. The form generates the "Data safety" section users see on your listing. Rules of thumb:

Firebase Analytics/Crashlytics count as data collection — declare them.
If you collect it, you must also have a privacy policy URL. Host one free on GitHub Pages or your project site; it must describe what you collect and why. A missing or placeholder privacy policy is one of the most common rejection reasons.
"We do not collect data" while Crashlytics runs is a false declaration — the review team checks.

App access. If any part of the app sits behind a login, you must provide Google a demo account (username + password) so reviewers can reach every screen. Reviewers will not create accounts. No demo credentials → rejection.

Step 5 — Testing tracks: internal → closed → production

Do not upload straight to production. The tracks exist to catch exactly the crashes your test phones missed:

Internal testing — up to 100 testers via email list or link. Builds available in minutes. Use this for your own devices and the first friend test.
Closed testing — the track that satisfies the new-account requirement: at least 12 testers, running the app for the last 14 days, before production is unlocked for a first app. Recruit classmates early — this is a calendar constraint, not a technical one. Run your full test pass here.
Open testing — optional public beta; anyone can join. Useful if you want pre-launch feedback at scale.
Production — the public listing. Roll out with a staged rollout (start at 10–20%) so a crash affecting one device model hits a fraction of users, not all of them. Monitor for 48 hours, then expand to 100%.

Each track upload needs a higher versionCode than the last — version management from Step 1 pays off here.

Step 6 — Review: timelines and the rejection loop

After you submit for production, Google reviews the app. Honest expectations:

First review for a new account: typically 3–7 days, sometimes longer. Updates to existing apps are usually hours.
Reviews are part automated, part human. The automated checks catch policy text matches (permissions, SDK lists); humans check the actual app behaviour against your declarations.
Rejections come with a reason and a policy reference. Read it fully before resubmitting — the most common student rejections are: missing privacy policy, demo login not provided, permission declared but unused, and data safety form contradicting actual behaviour. Fix the root cause, bump versionCode, re-upload, and reply in the console explaining the fix.

Treat the first rejection (if it happens) as free QA: the review team found something your testing missed. Teams that argue instead of fixing burn weeks.

Step 7 — After launch: vitals, updates, and the resume line

Android vitals (Play Console → Android vitals) track crash rate and ANR (app-not-responding) rate across your real user base. Google publishes "bad behaviour" thresholds (roughly: crash rate above ~1% of daily sessions, ANR rate above ~0.5%) — cross them and your store visibility suffers. With Crashlytics from the Firebase setup already in the app, you will see the same crashes with full stack traces; fix, bump versionCode, and push an update.

Update discipline: every update is a new AAB with a higher versionCode. Keep release notes honest and specific ("Fix crash when location permission is denied on Android 12") — users read them, and so do interviewers who look up your app.

The resume line writes itself: "Published [App Name] on the Google Play Store — [X] installs, 4.6★ rating. Handled signed AAB builds, Play App Signing, content rating, and data safety compliance." That single line signals more real-world engineering than most project descriptions three times its length. If you are still shaping the project's written narrative, the project synopsis guide helps compress the same story into the format examiners expect.

Cost summary

Item	Cost
Developer account registration	$25 one-time
App Bundle builds, signing, Play App Signing	Free
Internal / closed / open testing tracks	Free
Store listing, review, vitals	Free
Privacy policy hosting (GitHub Pages / project site)	Free

Total to go from finished app to public listing: $25 and roughly two weeks (identity verification + the 14-day closed testing window for new accounts). Budget both before promising a launch date.

The pre-launch report: Google's free robo-tester

Every AAB uploaded to the internal or closed track is automatically exercised by Firebase Test Lab: physical and virtual devices across models and OS versions, driven by a robo script that taps through your app like a monkey with a plan. Hours later you get the pre-launch report: crash stack traces per device, screenshots of every screen the robo visited, performance numbers, and accessibility warnings (tap targets too small, missing content descriptions).

Read it before promoting to production. Student apps commonly discover here: a crash on Android 12+ from an unhandled notification-permission result, an ANR on low-RAM devices caused by network calls on the main thread, and layouts that overflow on small screens. Each finding links to the exact device model and the robo's screenshot — the closest thing to free QA labour in the industry, and it runs without you asking.

Policy pitfalls that catch student apps

Pitfall	The rule	The safe approach
App is a WebView wrapper around a website	The "webviews and affiliate spam" policy: the app must offer native functionality beyond the site	Add genuine native features (FCM push, offline caching) or reconsider publishing
Requesting SMS / Call Log permissions	Restricted permission group: needs a declaration form and approval, granted only when core to the functionality	Do not request them. Use the SMS Retriever API or plain intents instead
Chat or comments with no moderation	The user-generated-content policy requires in-app reporting and blocking	Add report and block controls before shipping any social feature
Copied branding	Impersonation policy	Original name, icon, and screenshots — even "inspired by" a popular app is a rejection risk
Data safety form omitting an SDK's collection	Declared behaviour must match actual behaviour	Audit every SDK (analytics, crash reporting) against the form before submitting

Release train: a versionCode strategy across tracks

With four tracks and frequent uploads, version bookkeeping matters. A simple spaced scheme:

Track	versionCode example	Purpose
Internal	11, 12, 13…	Your own devices; iterate freely
Closed	21, 22, 23…	Tester group; the 14-day qualification builds live here
Open (optional)	31, 32…	Public beta
Production	101, 102…	Public listing

The only hard rule is monotonic increase within each track — Google rejects an upload whose versionCode is not higher than the track's previous one. Spaced numbering leaves room to promote a closed-testing build straight to production without renumbering anything.

After launch: reviews, vitals, and the update loop

Respond to reviews in the Play Console — especially the one-star ones. A calm, specific reply ("Fixed in version 1.2 — the crash occurred when location permission was denied; please update and tell us if it persists") converts angry users into updated reviews and signals to prospective downloaders that the app is maintained. Silence signals abandonment.

Watch vitals weekly for the first month: crash rate and ANR rate against the thresholds from Step 7. A spike after an update means halting the staged rollout — the console has a Halt rollout button for exactly this — then fixing and re-releasing. This loop (ship → monitor → fix → re-ship) is release engineering in miniature, and being able to describe it in your viva ("we halted the 20% rollout when vitals showed…") demonstrates a maturity most student projects never reach.

Launch checklist

Developer account created, identity verified, $25 fee paid.
applicationId final and unique (not com.example.*); versionCode/versionName set.
targetSdk current; release build tested on a real device with R8 minification on.
Debug logs gated; test keys and demo screens removed; only used permissions declared.
512×512 icon, 1024×500 feature graphic, ≥2 real screenshots prepared.
Keystore created, backed up in two places, passwords in a password manager; Play App Signing enrolled.
Signed release AAB built and smoke-tested.
Store listing complete: 30-char name, 80-char short description, full description, category, contact email.
Content rating questionnaire answered honestly; target audience declared.
Data safety form matches reality (Analytics/Crashlytics declared); privacy policy URL live.
Demo login credentials provided if the app has accounts.
Closed testing running with 12+ testers for 14 days (new personal accounts).
Staged rollout plan ready (10–20% → monitor 48h → 100%); vitals dashboard bookmarked.

Putting it together

The Play Store launch is a project-management exercise disguised as a technical one: the code is the easy part, the calendar is the hard part. Start the developer account and the closed-testing clock the week your app becomes testable — not the week before the viva. Teams that do this walk into their final demo able to say "it is on the Play Store, here is the listing", and no slide deck competes with a live install link.

How to Publish an App on the Play Store: Signed AAB Builds, Store Listing and Review