Publishing to Google Play Store: Indian Developer Guide

Open play.google.com/console. Here’s What You’ll See.

A big blue “Create app” button. A sidebar full of sections you haven’t touched. A dashboard that feels weirdly empty compared to the weeks you spent building your Android app.

I remember sitting in front of that screen in 2022, my first app ready to go, and just… freezing. Not because any single step was hard. Because nobody had walked me through what each screen actually wanted from me. The docs existed, sure, but they read like legal contracts translated through a committee.

So let me do what I wished someone had done for me. Walk you through every screen, every field, every “why is it asking me this?” moment — from creating your developer account all the way to watching your app go live on the Play Store. And since you’re probably an Indian developer (the INR pricing screen, GST headaches, and Aadhaar verification are all things I’ve dealt with personally), I’ll flag the India-specific stuff as we go.

Grab chai. We’re doing this together.

Screen One: Creating Your Google Play Developer Account

[Screenshot context: The Google Play Console sign-up page at play.google.com/console, showing the “Get Started” flow with the $25 fee prominently displayed.]

Head to play.google.com/console and sign in with whatever Google account you want tied to your developer identity. Could be your personal Gmail, could be a business one. Pick carefully — changing it later is a pain.

Here’s the first screen that matters:

Registration fee: $25 (roughly 2,100 INR as of early 2026). One-time. Not yearly like Apple’s program. But here’s the catch — UPI doesn’t work for paying it. You’ll need a credit card or debit card with international transactions enabled. My HDFC debit card worked fine, but a friend’s SBI card got declined twice before going through. If your card gives trouble, try a Kotak or ICICI one, or borrow a credit card for two minutes.

After payment, Google asks you to verify your identity. For Indian developers, they’ll accept:

• Aadhaar card
• PAN card
• Passport

Upload a clear photo or scan. Blurry images get rejected, and then you’re waiting another cycle. Verification typically takes 2-5 business days, though I’ve seen it happen overnight for some folks and drag out to 8 days for others. Google doesn’t really explain the variance.

Setting Up the Merchant Account (If You Plan to Earn Money)

Planning to sell your app, offer in-app purchases, or run subscriptions? You’ll need a merchant account. Skip this if your app is completely free with no monetization at all.

For the merchant setup, Google needs:

• Your PAN number
• Bank account details (account number, IFSC)
• A small verification deposit from Google — they’ll send a few rupees to your account, and you confirm the exact amount

[Screenshot context: Play Console > Settings > Payments profile, showing the tax information entry fields with a GSTIN field highlighted.]

Now, here’s something a lot of Indian developers miss early on. Google takes a 30% commission on Play Store sales. And you must add your GSTIN (GST Identification Number) to your payments profile. Without it, your tax invoicing gets messy, and you might face issues during ITR filing. Go to Settings → Payments profile → Tax information and enter your GSTIN there.

Screen Two: Preparing Your App for Release Mode

Before you upload anything, your app needs to be in release mode — not the debug build you’ve been testing with. Debug builds are bigger, slower, and contain logging code that has no business being on someone’s phone.

Open your build.gradle.kts (the app-level one, not the project-level) and set it up properly:

// app/build.gradle.kts
android {
    namespace = "com.yourcompany.yourapp"
    compileSdk = 35

    defaultConfig {
        applicationId = "com.yourcompany.yourapp"
        minSdk = 24
        targetSdk = 35
        versionCode = 1        // Increment for every upload
        versionName = "1.0.0"  // User-visible version
    }

    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

Two things to pay attention to here.

versionCode — a plain integer. Every single time you upload a new App Bundle to the Play Store, bump it by at least one. Forget to do it, and the upload gets rejected instantly. I’ve seen people waste 20 minutes wondering why their upload failed, only to realize the versionCode was the same as the last one.

versionName — what your users actually see. Follow semantic versioning: major.minor.patch. So 1.0.0 becomes 1.0.1 for a bug fix, 1.1.0 for a feature, 2.0.0 for a major overhaul. Nobody enforces this format, but it’ll save you confusion down the road.

Also notice isMinifyEnabled = true and isShrinkResources = true. These use R8 (formerly ProGuard) to strip unused code and resources from your release build. Your APK or bundle size drops significantly — sometimes by 40-60%. Worth it, but test your release build carefully. ProGuard can occasionally strip something it shouldn’t, especially if you use reflection or certain third-party libraries.

Screen Three: App Signing — The Part That Scares Everyone

Okay, signing. I won’t lie — app signing confused me for a solid month when I was starting out. Let me break it down as simply as I can.

Google Play App Signing is mandatory for all new apps. What does that actually mean? Two keys are involved:

1. App signing key — Google holds onto it. They use it to sign the final APK that goes to users’ devices.
2. Upload key — You create this. You sign your App Bundle with it before uploading. Google verifies it’s really you, then re-signs with the app signing key.

Why the two-key system? If you lose your upload key, Google can issue you a new one. Lose the app signing key, and you’d have to publish as an entirely new app. Google holding the signing key protects you from yourself, basically.

Generate your upload keystore:

# Generate an upload keystore
keytool -genkeypair -v \
  -keystore upload-keystore.jks \
  -keyalg RSA -keysize 2048 \
  -validity 10000 \
  -alias upload \
  -storepass YOUR_STORE_PASSWORD \
  -keypass YOUR_KEY_PASSWORD

# Verify the keystore
keytool -list -v -keystore upload-keystore.jks -alias upload

When you run that first command, it’ll ask you a bunch of questions — your name, organization, city, country code. For India, the country code is IN. Fill these honestly; they’re baked into the certificate.

Now wire the signing config into your build file:

// app/build.gradle.kts
android {
    signingConfigs {
        create("release") {
            storeFile = file("upload-keystore.jks")
            storePassword = System.getenv("STORE_PASSWORD")
            keyAlias = "upload"
            keyPassword = System.getenv("KEY_PASSWORD")
        }
    }

    buildTypes {
        release {
            signingConfig = signingConfigs.getByName("release")
            // ... minify settings
        }
    }
}

Building the Release Bundle

Google requires App Bundles (AAB format) for all new apps since 2021. APKs aren’t accepted anymore for new submissions. Bundles are better anyway — Google generates optimized APKs for each device configuration, so users download only what their phone needs.

# For a native Android app
./gradlew bundleRelease

# The output AAB will be at:
# app/build/outputs/bundle/release/app-release.aab

# For a Flutter app
flutter build appbundle --release

# Output: build/app/outputs/bundle/release/app-release.aab

Your release AAB will land in app/build/outputs/bundle/release/. Hang onto that path — you’ll need the file in a few minutes.

Screen Four: The Store Listing — Where Users Decide in Three Seconds

[Screenshot context: Play Console > Store presence > Main store listing, with fields for app name, short description, full description, and media assets.]

Head to Google Play Console → Your App → Store presence → Main store listing. My honest opinion? Spend more time here than on any other screen. Your store listing is quite literally the thing that converts a search result into a download. Or doesn’t.

Here’s what each field expects:

• App name: 30 characters max. Be specific. “Expense Tracker” is okay; “Expense Tracker – India, GST Bills, UPI” is better for discoverability. Stuff keywords in naturally — Google’s algorithm reads your title.
• Short description: 80 characters. Shows up in search results right below your app name. Make it count. Don’t waste it on “Best app ever” — tell people what it does.
• Full description: Up to 4,000 characters. Use keywords naturally. Explain features. Mention what makes yours different. And here’s a trick I wish I’d known earlier — if your target audience includes non-English speakers, sprinkle in Hindi or regional language keywords. Someone searching “खर्च ट्रैकर” (expense tracker in Hindi) might find your app if you’ve included those terms.
• Screenshots: Minimum 2, but aim for 8. Sizes differ by device type:
  • Phone: 1080 x 1920 pixels
  • 7-inch tablet: 1200 x 1920
  • 10-inch tablet: 1600 x 2560

  Use Figma, Canva, or a tool like screely to frame them nicely. Raw screenshots look amateurish.

• Feature graphic: 1024 x 500 pixels. The banner at the top of your listing. Design it like a movie poster — clear, bold, immediately communicative.
• App icon: 512 x 512 pixels, PNG format, 32-bit with alpha channel. This is your app’s face. Don’t rush it.

Translations for the Indian Market

Go to Store presence → Store listing translations. Adding your listing in Hindi, Tamil, Telugu, Kannada, or Bengali can boost your downloads significantly in tier-2 and tier-3 cities. India has something like 22 official languages, and English isn’t the first choice for hundreds of millions of smartphone users. I’d argue translations are probably more impactful in India than in almost any other market.

Screen Five: Content Rating and App Content Declarations

[Screenshot context: Play Console > Policy and programs > App content, showing the checklist of required declarations — privacy policy, ads, content rating, target audience, data safety.]

Open Policy and programs → App content. You’ll see a checklist of items Google won’t let you skip. Let me walk through each one.

Privacy policy. Mandatory. No exceptions. Host it on your website, a GitHub Pages site, or even a Google Doc (though a proper URL looks more professional). Your policy needs to describe what data you collect, why, and how you handle it. For apps targeting Indian users in 2026, keep the Digital Personal Data Protection Act (DPDPA) 2023 in mind. It’s India’s equivalent of GDPR, and while enforcement has been gradual, having a compliant privacy policy from day one saves headaches later.

Ads declaration. Does your app show ads? Say so. Google flags apps that declare “no ads” but serve AdMob banners. Misrepresentation can get your app suspended.

Content rating. You’ll fill out the IARC questionnaire — a series of yes/no questions about violence, language, sexual content, gambling, that sort of thing. Answer honestly. Most utility and productivity apps land an “Everyone” rating. Games with cartoon violence might get “Everyone 10+”. Lying here is a fast track to removal.

Target audience. If your app could appeal to children under 13, additional requirements kick in. You might need to comply with COPPA-equivalent policies. If your app isn’t for kids, just say so clearly and move on.

Data safety. Relatively new addition. You declare what data your app collects (location, contacts, photos, etc.), whether it’s shared with third parties, and whether it’s encrypted. Be precise. Users see this section on your Play Store page, and savvy users do check it before installing.

Screen Six: Release Tracks — Internal, Closed, Production

Google Play gives you three tracks to release on. Think of them as progressively wider circles of access:

1. Internal testing — Up to 100 testers. No Google review required. Your AAB goes live for testers within minutes. Perfect for QA and sanity checks.
2. Closed testing (Alpha/Beta) — Invite-only, but requires a brief Google review. Useful for wider beta programs before public launch.
3. Production — The real deal. Public release. Google reviews new apps, and the first review takes anywhere from 1 to 7 days. Subsequent updates are usually faster.

Here’s my strong recommendation: start with Internal testing even if you’re itching to go straight to production. Why? Because it lets you verify that the entire upload-install pipeline works. You’d be surprised how many issues only surface after uploading to Play — signing mismatches, missing permissions declarations, bundle format problems. Better to catch those with 5 friends testing than with your public launch.

Step-by-Step: Internal Testing Release

1. Click into Release → Testing → Internal testing in the sidebar.
2. Click “Create new release”.
3. Upload your app-release.aab file. The upload takes a minute or two depending on file size and your connection.
4. Add testers by email address — they need to accept an invite link before they can install.
5. Hit “Roll out”.
6. Within minutes, your testers receive a link to install via the Play Store. On their end, it looks just like any other app install.

Have your testers poke around. Check for crashes, broken layouts on different screen sizes, network timeout handling, the boring but important stuff. Once you’re confident, it’s time for production.

Step-by-Step: Production Release

1. Go to Release → Production.
2. Click “Create new release”.
3. Upload your AAB (or promote the same bundle from your testing track — saves time and ensures it’s the exact same binary).
4. Write release notes. Keep them short, user-friendly. “Bug fixes and performance improvements” is a cliche, but it works for minor updates. For your first release, be more descriptive. If your user base includes Hindi speakers, consider bilingual release notes.
5. Before you hit rollout, Google offers a staged rollout option. I’d strongly suggest starting at 20%. What that means: only 20% of eligible users see the update initially. If crash rates spike, you can halt the rollout before it reaches everyone. After a day or two of clean data, bump it to 50%, then 100%.

[Screenshot context: Play Console > Release > Production > Rollout percentage slider set to 20%.]

That 20% staged rollout might sound overcautious. It’s not. I’ve personally caught a device-specific crash on a Samsung M31 (hugely popular budget phone in India) that only appeared at scale. Staged rollout saved me from a wave of 1-star reviews.

After You’re Live: Monitoring and Keeping Things Healthy

Congratulations — your app is on the Google Play Store. But publishing isn’t the finish line. It’s more like the starting blocks.

Back in the Play Console dashboard, you’ll find monitoring tools that deserve regular attention:

Android Vitals. Google tracks your app’s ANR rate (Application Not Responding — when your app freezes), crash rate, excessive wake locks, and stuck background services. Bad vitals hurt your search ranking. Like, measurably. Google has confirmed that apps with high ANR rates get demoted in Play Store search results. Keep your ANR rate below 0.47% and crash rate below 1.09% to stay in Google’s good graces.

Ratings and reviews. Reply to user reviews, especially negative ones. A thoughtful response to a 1-star review sometimes converts it to 3 or 4 stars. Indian users, in my experience, are quite responsive to developers who actually engage.

Firebase Crashlytics. Free, and you should set it up before launch — not after. It captures crash logs with stack traces, device info, and the exact user flow that led to the crash. Far more useful than the Play Console crash reports alone.

Some ADB commands you’ll likely use while debugging issues reported by users:

# Useful ADB commands for testing on physical devices
adb devices                          # List connected devices
adb install app-release.apk          # Install APK directly
adb logcat | grep "YourAppTag"       # View app logs
adb shell dumpsys package com.yourcompany.yourapp  # Package info

India-Specific Gotchas That Nobody Warns You About

Let me bundle up the India-specific stuff in one place, because it’s scattered across different screens in the Console and easy to miss.

The $25 payment. International transactions must be enabled on your card. Some banks disable it by default. Check your banking app or call the helpline before attempting the payment. Getting declined twice can trigger a cooldown.

GSTIN entry. If you’re earning revenue through the Play Store, add your GSTIN under Settings → Payments profile → Tax information. Without it, your tax compliance for GST filing becomes a nightmare. And with GST council updates happening practically every quarter, staying on top of this from the beginning is wise.

INR pricing. When setting prices for paid apps or in-app purchases, Google lets you set prices in INR directly. Don’t just use the auto-converted amount from USD — Indian users are price-sensitive, and a 49 INR price point feels very different from a 51 INR one. Round to user-friendly numbers.

Aadhaar verification quirks. Some developers report that Aadhaar-based verification takes longer if the name on their Google account doesn’t match the name on Aadhaar exactly. Middle names, initials, spelling variations — these can cause delays. Try to get them as close as possible before starting the process.

DPDPA compliance. India’s Digital Personal Data Protection Act 2023 applies if you’re collecting personal data from Indian users. Your privacy policy should cover data minimization, purpose limitation, and user consent. It’s not as heavy-handed as GDPR yet, but the trajectory is clear.

UPI for in-app purchases. While Google doesn’t accept UPI for the developer registration fee, users can pay for your app or in-app purchases using UPI through Google Play billing. That’s a massive win given how dominant UPI is in India — over 12 billion transactions monthly as of 2025.

Common Mistakes I’ve Seen (and Made)

After helping a handful of friends and junior developers through their first Play Store submissions, a pattern emerges. Same mistakes, almost every time.

Forgetting to increment versionCode. Upload rejected. Confusion. Wasted time. Just bump it.

Committing the keystore to Git. Happens more often than you’d think. Even experienced developers slip up. Add *.jks and *.keystore to your .gitignore from the very first commit.

Skipping the content rating questionnaire. Your app literally cannot be published without it. Yet people somehow reach the production rollout screen and wonder why there’s a blocking warning.

No privacy policy. Doesn’t matter if your app collects zero data. Google still wants a privacy policy URL. Host a simple one. It takes 20 minutes.

Ignoring ProGuard rules. You enable minification (good), but then certain features break in release mode because ProGuard stripped something it shouldn’t have. Test your release build thoroughly. If a library’s docs mention ProGuard rules, add them.

Uploading an APK instead of AAB. New apps require App Bundles. Period. If you upload an APK, the Console rejects it with a message that honestly could be clearer.

A Quick-Reference Checklist Before You Hit “Publish”

Print this out, stick it next to your monitor, and go through it before every release:

1. versionCode incremented? Check.
2. Release build tested on at least two physical devices? Check.
3. Keystore NOT in version control? Check.
4. Store listing complete — name, descriptions, screenshots, feature graphic, icon? Check.
5. Privacy policy URL entered and accessible? Check.
6. Content rating questionnaire done? Check.
7. Data safety form filled out? Check.
8. Ads declaration accurate? Check.
9. GSTIN added (if monetizing)? Check.
10. Internal testing verified? Check.
11. Release notes written? Check.
12. Staged rollout set to 20% for first production release? Check.

Twelve items. None of them take more than a few minutes. But missing even one can delay your launch by days.

What Happens After You Submit for Review

You’ve hit “Roll out to production.” Now what?

For brand new apps, Google’s review process takes 1-7 days. In my experience, most Indian developer accounts see their first review completed within 3 days. Subsequent updates go faster — often under 24 hours, sometimes within a few hours.

During review, your app’s status in the Console shows “In review” with a little clock icon. You can’t speed it up. Don’t email Google support asking for a faster review — they won’t do it, and you’ll just get a templated response.

If your app gets rejected, you’ll receive an email with the specific policy violation. Common first-time rejections:

• Missing privacy policy
• Metadata policy violation (misleading screenshots or description)
• Permissions that seem excessive for what the app does
• Intellectual property issues (using trademarked names or logos)

Fix the issue, resubmit, and you’re back in the queue. Second reviews are usually faster.

And then, one morning, you’ll open your email and see it: “Your app has been published on Google Play.” You’ll search for it in the Play Store, find it there among millions of other apps, and feel something that’s hard to describe to non-developers. Your code, on people’s phones, accessible to 600 million smartphone users across India.

Every developer who’s published remembers that moment.

Yours is coming. Go ship it.