Signed APK and AAB for Google Play: package id, version and keystore

Getting an app onto Google Play used to mean installing Android Studio, generating a keystore from the command line, guessing at Gradle settings and hoping the bundle uploaded. If you lose that keystore, you can never update the app again; if you pick the wrong package id, you cannot change it without starting a new listing. This guide is for anyone who has built an app in App Builder Agent and now wants a proper signed release, with the decisions explained before they become permanent.

The builder does the mechanical work: the AI agent sets your package id and version, generates and keeps the signing key with the project, and produces both a signed APK and an AAB from the same build. Your job is the handful of choices Google asks about and the store listing itself. Below is the whole path, from the first test APK to a listing in review.

What you need before you start

• A finished test build — install the test APK from the preview header on a real phone and use it for a day. Store builds are for apps that already work.
• A package id — the permanent identifier in reverse-domain form, such as com.yourname.app or ng.lagosrides.driver. Lowercase letters, digits and dots; no hyphens, no leading digits in any segment.
• A version name and code — the name people see (1.0.0) and a whole number that must go up with every upload (1, then 2). The code is what Google Play compares.
• A Google Play developer account — a one-time registration fee paid to Google, plus identity verification, which can take a few days. Start it before the app is ready.
• A privacy policy URL — required for every app, even one that stores nothing. The builder can publish a simple policy page from the same project.
• Store assets — a 512 px icon, a 1024×500 feature graphic and at least two phone screenshots. The preview’s phone frame gives you clean screenshots.

Test APK versus signed store build

The preview header’s Download APK menu offers two things, and it helps to know which is which.

• Test APK — built in seconds, release-signed with a shared platform key. Perfect for your own phones and for sharing with testers, but it cannot be uploaded to Google Play, and every project’s test APKs share a signing identity.
• Signed build (APK + AAB) — built with a key generated for this project and sealed with it. Carries your package id and version. The AAB goes to the Play Console; the APK is for direct downloads from your site or for phones without Google services.
• Why they cannot mix — Android refuses to install a build over another with the same package id but a different signature. Uninstall the test APK before installing the signed one, or give them different package ids during testing.

Build it with App Builder Agent, step by step

1. Freeze the app. Finish features, fix what the test APK showed you, and set the icon and name. Every change after this point is a new version code.
2. Ask for the signing identity. Tell the agent the package id, version and app name in one message. It writes them into the project and sets up signing; a signing summary card appears in the chat.
   Prepare this app for the Play Store. Package id com.dhakatiffin.orders, app name “Dhaka Tiffin”, version name 1.0.0, version code 1. Generate and keep the signing key for this project. Build both a signed APK and an AAB. Also add an About screen showing the version and a link to the privacy policy at https://dhakatiffin.com/privacy.
3. Check the summary and build. The signing summary shows the package id, version and key fingerprint. If anything is wrong, fix it now; then start the signed build. It takes longer than a test APK because it produces the bundle too.
4. Install the signed APK on a phone. Uninstall the test version first. Confirm the name under the icon, the version on the About screen, and that the app opens cleanly.
5. Release the next version. When you ship an update, ask for the code to go up; the key is reused automatically, so Play accepts it as an update.
   Bump the version to 1.0.1 with version code 2 and build a new signed APK and AAB. Keep the same package id and signing key.

What Google Play asks for

• App content declarations — privacy policy URL, ads yes/no, target audience and age group, data safety form (what the app collects and whether it is shared). An app that stores data only on the device declares no collection.
• Store listing — short description (80 characters), full description, icon, feature graphic, screenshots, category and contact email. Write the description for a person searching, not for the reviewer.
• Testing tracks — internal testing (up to 100 emails, no review) is where the first upload should go. Closed testing with real users is required for new personal developer accounts before production is unlocked.
• Signing by Google — Play App Signing is on by default for new apps: you upload the AAB signed with your project key and Google re-signs it for devices. This is normal; keep your project key for uploads.
• Review time — a few hours to several days for a first release; updates are usually faster. Rejections almost always cite the privacy policy, a permission without a stated purpose, or a login the reviewer cannot get past. Provide test credentials in the review notes.

Prompts that work well

Common mistakes (and the fix)

• Using a package id you do not own the domain for. Google does not check, but com.example.* and com.google.* are refused. Use your own domain reversed, or com.yourname.appname.
• Uploading the APK instead of the AAB. New apps must be bundles. Upload the AAB; keep the APK for your website.
• Forgetting to raise the version code. Every upload needs a higher code, even for a tiny fix. Ask the agent to bump it with each store build.
• Testing the signed build over the test APK. Same package id, different signature, so Android says “App not installed”. Uninstall first.
• No privacy policy. The most common rejection. Publish a page and link it in Play Console and inside the app.
• Requesting permissions the app does not use. Reviewers flag location, contacts and SMS permissions without a visible purpose. Ask the agent to remove any it added for a feature you deleted.

Make it feel finished

• A version number on the About or Settings screen, matching the version name in the store.
• Screenshots from the preview’s phone frame, in the same brand colour as the feature graphic.
• A short description that says what the app does in the first six words; that is all that shows in search results.
• An account deletion path if the app has accounts; Play requires it for apps with sign-up.
• A changelog line for each release (“Fixed cart total on discounts”). Users read it more than you would think.

Installing, publishing and next steps

After the signed build finishes, the Download APK menu offers the signed APK for direct installs and the AAB for the Play Console. If an install on a phone fails, the install troubleshooting guide lists the causes, and the icon and name guide covers the last polish before you take screenshots. The APK app builder page describes the build types and pricing in one place.

Apps with accounts need the account deletion and data-safety answers to match what the app does; the ready-made login & dashboard apps show how a clean sign-in and settings flow looks. When you are ready, Open the builder, pick the project and ask for the signing identity in one message.

Frequently asked