How to publish an Android app on Google Play (Data Safety, AAB)

What you need before you click Publish

Google Play does not accept a raw APK as the main production artefact for new apps. You upload a signed Android App Bundle (.aab). You also complete a Data Safety form, host a privacy policy URL, and fill the store listing. Skip any of those and review fails or the listing stays incomplete.

HackifyTech ships Play-ready Android and Flutter builds this way. Smart Finance Toolkit (com.hackifytech.sft) is a Flutter utility with local-only calculators and a Data Safety posture that matches that design. SarvamAstro (com.sarvamastro.app) and Farm360 (com.jpishitantra.farm360, published by Krishitantra) are live Play apps we have worked on.

Play Console registration is a paid developer account in USD, with identity checks. New personal accounts may need a closed test with real testers before production—follow the checklist Play shows on your account. Do not assume yesterday’s blog still matches your console.

Android App Bundle (.aab), not a fat APK

An App Bundle lets Play generate split APKs per device (ABI, screen density, language). Users download less. You enrol in Play App Signing: Google holds the app-signing key; you keep an upload key. Lose the upload key and you must go through Play’s reset process—store the keystore and passwords offline.

From Android Studio use Generate Signed Bundle. From Flutter use flutter build appbundle (release). Test the release build on a real phone before upload. Internal testing tracks exist so you can install the Play-signed artefact, which can differ from a local APK.

Meet the target API level Play currently requires. Old target SDKs are rejected. Set versionCode higher on every upload. Keep the applicationId (package name) stable forever. Changing com.yourcompany.app later is a new app.

Data Safety form: declare what the binary actually does

The Data Safety form lives under App content in Play Console. It is mandatory for production and for testing tracks. The answers appear on the store listing so users can see collection, sharing, and security before they install.

You must include your code and every third-party SDK. Analytics, crash tools, payments, ads, and auth libraries often collect device IDs or diagnostics even if you never built a “profile” screen. If an SDK reads Android ID, that is “Device or other IDs.” Look up each vendor’s Data Safety mapping (Firebase and others publish one).

For each data type you collect or share, say why (app functionality, analytics, advertising, fraud prevention, personalization, account management), whether it is required or optional, and whether it is encrypted in transit. If you collect personal or account data, Play expects a way for users to request deletion, and that URL must match the privacy policy.

Google can compare the form to the AAB and to the privacy policy. A mismatch is a common rejection. Do not copy a template that says “we collect nothing” if your crash SDK uploads logs.

When you collect almost nothing

On-device tools can still be honest: “Data is processed on the device; we do not collect it.” Smart Finance Toolkit was designed that way—no login, no location/camera/mic/contacts, inputs processed locally, optional history on-device. The Data Safety form and privacy policy must say the same thing.

You still submit the form. “No collection” is a valid outcome, not a skip. If you later add Firebase Analytics or Google sign-in, update the form before you ship that bundle.

Privacy policy, account deletion, and in-app links

Play needs a publicly reachable privacy policy URL. The policy must describe the same data types as the form, including SDKs. Host it on your domain (for example yoursite.com/privacy). HackifyTech sites include Privacy and Terms pages for this reason.

If users can create an account, provide a deletion path that is not geo-blocked. Put policy links in the app (settings or about), not only on the website.

Store listing copy that helps ASO

ASO is the Play listing: title, short description, full description, screenshots, feature graphic, and category. Use the words people type: “EMI calculator,” “Kundli matching,” “soil health card”—only if the app truly does that. Keyword stuffing in the title looks spammy and can be policy trouble.

Screenshots should show the real UI on a phone, in the language of your market. For India, English plus a regional language in screenshots or listing can help if the app supports it. Farm360’s multilingual Seeta chatbot is a product fact; put facts in the listing, not slogans.

Complete the Data safety, ads, and content-rating questionnaires. A missing content rating blocks production.

Upload, test tracks, then production

Create the app in Play Console, set the package name, and complete the dashboard checklist. Upload the .aab to Internal testing, then Closed or Open testing if you need wider feedback. Production is last.

Review can take hours to several days. Rejections often cite Data Safety vs binary, missing privacy policy, broken login, or misleading listing text. Fix the artefact and the form together; do not only edit the description.

After go-live, every new permission or SDK is a form update. Treat Data Safety as part of release, like versionCode.

What HackifyTech can do—and what you still own

We can build the app, produce a signed App Bundle, write listing copy, align Data Safety with the real build, and add in-app policy screens. Play fees, the developer account, and merchant / Maps / WhatsApp API bills stay in your name unless the written scope says otherwise.

Mobile MVPs start from ₹1,20,000. Store listing support is included as scoped. WhatsApp +91 82177 16658 with your platform (Android / iOS), a feature list, and whether you already have a Play Console account.