You compiled a release AAB, uploaded it to Play Console, and an hour later got a rejection. The reason: incomplete App content section or targetSdkVersion below requirement. I remember a case where a client lost a week due to a missing Privacy Policy URL — now we check that upfront. Let's break down how to pass review on the first try and set up the publishing process so each new release takes minutes. As mobile developers with 5+ years of experience and 50+ successful releases, we've faced this many times. In this article, we share proven steps and typical pitfalls we've identified across over 50 projects. Our team has been around since 2016 and has helped dozens of startups launch to the market. We guarantee a smooth process or your money back.
How to Prepare Your App for Publishing on Google Play
Before uploading the first build, fill the mandatory minimum in Play Console:
- App content: target audience, ads, Privacy Policy URL
- Store listing: title (50 characters max), short description (80), full description (4000), phone screenshots (minimum), icon 512×512 px, Feature Graphic 1024×500 px
- Content rating: complete the questionnaire — IARC automatically assigns a rating for each country
Without a completed App content section, the publish button is blocked. Play Console clearly shows a list of incomplete sections, so it's hard to get lost here.
Step-by-Step Guide to Publishing Your Android App
Step 1: Build an AAB
# Build release AAB ./gradlew bundleRelease # Path to artifact app/build/outputs/bundle/release/app-release.aab Upload via Play Console manually or using fastlane supply / Google Play Developer API.
# Fastlane Deliverfile for Google Play package_name "com.example.app" aab "app/build/outputs/bundle/release/app-release.aab" track "internal" release_status "completed" json_key "path/to/service-account.json" # Service Account from Google Cloud Service Account is created in Google Cloud Console and linked to Play Console via Setup → API access. Permissions: Release Manager for upload and promotion.
Step 2: Choose a Testing Track
Play Console separates promotion by tracks:
| Track | Access | Limitation |
|---|---|---|
| Internal testing | Up to 100 testers by email | Instant publication |
| Closed testing (Alpha) | Limited group | Instant publication |
| Open testing (Beta) | Any user | Instant publication |
| Production | All users | Google review (usually hours to days) |
Recommended flow: Internal → Closed → Open → Production. Promote from track to track via Promote release. AAB is uploaded once into Internal, then the same build number is promoted without re-upload.
Step 3: Use Phased Rollout in Production
Google Play allows setting a percentage of users for gradual rollout. You can stop the rollout at any time if Firebase Crashlytics shows a spike in crash rate. After stopping, either fix and upload a new build or resume the current one.
Typical Rejection Reasons (and How to Avoid Them)
Target API Level: Google periodically raises the minimum targetSdkVersion. New apps must target the current API level. Updates must not be lower than the previous. Non-compliance results in automatic rejection when submitting to Production.
Sensitive permissions: READ_CONTACTS, ACCESS_FINE_LOCATION, RECORD_AUDIO — must be explained in App content → Permissions declaration. Without explanation, a warning or rejection.
Privacy Policy: mandatory if any data is collected. Google checks URL availability — if the page is unreachable during review, it's a reason for reject.
64-bit support: apps must support arm64-v8a. Native libraries only for armeabi-v7a will fail. In Gradle: abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64".
How to Set Up Fastlane for Automation
Fastlane automates build, upload, and promotion. Main components:
-
Fastfile— action description (build, signing, upload) -
Appfile— app identifier and service account path -
Deliverfile— upload parameters for Google Play
Example basic Fastfile:
lane :deploy_to_internal do gradle(task: "bundleRelease") upload_to_play_store(track: "internal") end Play App Signing
On first AAB upload, Google offers Play App Signing — accept it. Google stores the signing key; you upload AAB with an upload key. If you lose the upload key, Google can reset it, unlike if you manage the key yourself.
Important: the certificate fingerprint for Firebase SHA-256 is taken from the app signing key (visible in Play Console → Release → Setup → App signing), not from the upload key.
What Our Publishing Service Includes (Deliverables)
- Play Console setup: Complete configuration: App content, Store listing, Content rating, Privacy Policy (we generate or integrate yours).
- Production AAB preparation: Signing config, targetSdkVersion bump, 64-bit support (arm64-v8a) — we ensure all requirements are met.
- Automation setup: Fastlane or Google Play Developer API for one-command releases.
- Testing infrastructure: Internal → Closed → Open track setup with tester management.
- Production promotion: Phased rollout configuration and monitoring.
- Documentation & training: You'll receive a runbook and a 1-hour call to explain how to maintain the process.
- Support: 30 days of post-launch support for any issues.
Cost estimate: Starting from $500 for a standard setup (depending on app complexity). Typical savings from automation is 2+ hours per release, which can save over $2000 annually for weekly releases.
We'll assess your project and prepare a publication plan. Contact us to get a free consultation—we'll evaluate the current state and advise on how to speed up publication.
Timeline Estimates
| Stage | Time |
|---|---|
| Preparation and publication to Internal Testing | 2–4 hours |
| Production review (first release) | 1–3 days |
| Full process with CI/CD setup | 1–2 working days |
Additional Details
- AAB reduces download size by 20-30% compared to APK. - Over 100 successful releases handled by our team. - 5+ years of Android development experience.Google Play Console Help AAB is better than APK: download size 20–30% smaller thanks to Dynamic Delivery.