Identify where the artifact is attached
Open the app's release area and locate the specific track and release. In the current workflow, releases are under Test and release, with testing tracks and Production managed separately. The artifact inventory is described as Latest releases and bundles, replacing older “App bundle explorer” wording in current help navigation.
Record the version code, signing identity and track before editing. A similarly named bundle from another build is not interchangeable.
Remove from a draft where appropriate
Google's release guide describes removing an artifact from the Included section with Remove. That changes the release's selection; the uploaded artifact remains available in the broader bundle inventory.
If changes have been submitted or published, use the controls appropriate to that state. Do not assume the draft workflow applies to a live production release. Review Publishing overview for pending changes and their review status.
Replace a defective artifact correctly
Build a corrected release with a new valid version code and the required signing arrangement. Retain the previous artifact for diagnosis. The version name displayed to users can be similar while the internal version code increases.
Bad artifact: versionCode 120
Corrected build: versionCode 121
This illustrates sequencing, not a prescribed version scheme. Check every active track and existing version-code range before assigning the next value.
Avoid confusing local deletion with Play state
Deleting the .aab file from your computer does not remove it from Console. Removing a release entry does not delete customer accounts. Unpublishing the app does not repair a signed artifact already delivered to users.
APKLint's AAB Analyzer can help identify the bundle you are about to upload. It does not remove cloud artifacts or verify all delivery configurations.
Use the current release instructions, unpublishing guidance and Android versioning reference. When the UI does not offer the expected action, inspect permissions and release state instead of inventing an undocumented deletion endpoint.
Trace the bundle through a draft replacement
Imagine a draft closed-test release containing version code 120, where inspection reveals the wrong server endpoint. Record the draft's track and artifact identity before removing its included bundle. Prepare corrected version 121, inspect its endpoint configuration and signing relationship, and add it to the intended release. This is a controlled replacement of the draft's contents.
Check the release summary after the change. Confirm that the selected artifact is 121 and that the notes describe that candidate. A filename such as final.aab provides no reliable evidence about which uploaded version the release will distribute.
Check the state before applying a removal instruction
If version 120 is already available on another testing track, removing it from this draft does not establish that the other track stopped serving it. Inspect the affected track separately and identify its current release. Likewise, a production installation already on a device is not erased by editing an unrelated draft.
The official release workflow distinguishes selecting artifacts from managing a release. Use the controls available for the specific state and account permissions. An unavailable button can indicate a state or permission boundary rather than a reason to search for an unofficial deletion method.
Retain the defective bundle in a restricted internal release archive if it is needed to explain the incident. Mark it clearly as rejected for distribution and keep its checksum with the diagnosis. This prevents another operator from selecting the same artifact later because it happens to remain in the broader inventory.
After replacing the draft, install through the intended test track and verify the version on the device. Exercise the behavior that exposed the wrong endpoint using synthetic data. This checks delivery and configuration together instead of relying entirely on a local inspection of the corrected file.
Document the next available version-code choice against all relevant active tracks. The illustrative 120-to-121 sequence is deliberately simple; an actual project may already have higher codes in a parallel release and must account for that history before building again.
Sources and further reading
- Google Play: Prepare and roll out a release
- Google Play: Update or unpublish your app
- Android Developers: Version your app
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
