Publishing an Android app in Huawei AppGallery: a step-by-step guide

Why publishing in Huawei AppGallery fails moderation

Publishing in Huawei AppGallery fails not on code but on formalities: the app is built, tested, and works, yet moderation returns it with a terse wording that still needs decoding.

Most often the cause is a discrepancy with app store requirements: declared permissions do not match actual behavior.

The second most common cause is app signing. A release build signed with a debug key or a key from another keystore is not accepted by the store.

A separate trap is changing the key between versions: the update no longer installs over the previous one, and some users remain on the old build.

The third block is the store listing: description, screenshots, icon, age rating, privacy policy link. A missing policy is an almost guaranteed moderation rejection, even if the app collects a minimum of data.

An incomplete listing does not block publication but lowers positions in the store's internal search.

The cost of each failure is measured not in development hours but in a missed launch window. A review iteration takes days, fixes require a new build and a new waiting cycle, the release slips, and the acquisition channel that has already started warming up cools down.

We break down exactly what moderation checks and how to prepare a build to pass it on the first try.

How app store requirements differ from one another

Each store checks its own set of rules, and a build that passed moderation in one does not guarantee acceptance in another.

Differences between app stores concern signing, target OS version, listing content, and data handling policy — revision requests come exactly on these points.

Signing and certificates

Platforms treat keys differently: some accept a build signed only in your keystore, while others require an additional platform signature and a separate certificate.

A separate item is the key expiration date: when it expires, updates stop being accepted even if the code is ready. That is why we create keys with a validity margin, store them outside the repository, and verify the release signature before upload.

Store listing content and localization

The store listing is the second source of revisions: a set of screenshots for different screen sizes, description texts, age rating, privacy policy link, and disclosure of the data collected.

Localization of descriptions is mandatory on some platforms for target regions; otherwise, the listing is not shown in featured selections.

Platforms update app publishing rules regularly, so before every release we check the current documentation of Huawei AppGallery and other stores, not last year's checklists.

Process of app placement: from build to approval

The release route in AppGallery is built around one idea: by the time the build is uploaded to the store, the listing, signature, and developer account data are already consistent with each other. Then passing review is about reading comments, not rebuilding from scratch. The order in which we handle publication:

1. Audit of the current build: sign-in, payments, and notifications must not depend on services unavailable on Huawei devices — they are covered by an alternative implementation.
2. Signing preparation: the key is created once and reused in all updates, so it is stored in a secure keystore rather than on an engineer's laptop.
3. Filling out the listing: name, description, screenshots for the required screen resolutions, category, age rating, privacy policy, and data collection information.
4. Uploading the build to the store: format, distribution zones, and staged percentage rollout.
5. Closed testing on a limited list of accounts — before the app appears in open availability.
6. Passing review and releasing the update: responding to comments, public release, then scheduled releases.

Closed testing before release

This is not a formality but a way to catch what is not visible in a test environment: updating over the previous version, devices without familiar services, different screen diagonals.

We separate clean installs and updates over the old version and compare reports — regressions are found before the flow of new installs.

What to do about reviewer comments

A comment almost always points to a discrepancy between the listing and the app's behavior, so we respond not with text but with a new build or a precise explanation with a screen recording.

We log every iteration: build version, reason for rejection, what was changed — this way review does not go in circles.

Release modes and review timelines in app stores

The first publication and an update to an already installed app go through different review queues: the initial version undergoes manual policy review and the store may review it for several business days; an update over an installed one usually takes from several hours to two days.

We always calculate the release date from the worst-case timeline and allow a window for fixing moderator comments.

Staged rollout and version rollback

Staged rollout opens the new version in shares — for example, 5%, 20%, 50%, and 100% with a pause between steps.

We look at the share of successful launches and crashes in the first hours: if the metric drops, the rollout stops, and the rest of the audience remains on the previous version.

Rollback in stores is not instantaneous: you cannot lower the version, so we keep a stable predecessor build in advance and release it as an update.

User data is preserved in this case if the storage scheme is compatible — we verify this in closed testing before the rollout starts.

Release artifacts: builds, keys, accesses, and procedures

After release, the client retains a set sufficient to release updates on their own or with another team: builds, keys, rights in the developer console, and procedures. Below is what exactly is included in the handover and how it is stored.

• Signed builds — published packages in AAB and APK formats with version number, date, and file checksum.
• Signing keystore — the key itself, its passwords, and certificate fingerprint: without them, updating in the store is impossible, and the key cannot be recovered.
• Developer console access — the owner account belongs to the client, separate roles for development and testing, a contact for communication with reviewers.
• Release instructions — the sequence of actions: build, sign, upload, fill out the listing, submit for review, handle comments.
• Update and support procedure — release frequency, responsible parties, response time to rejection, and rules for rolling back to the previous build.

Transfer of access and roles

The client becomes the account owner — for their legal entity and contact addresses.

Our engineers remain with the developer role and a minimal set of rights under two-factor authentication, and when work is completed, access is revoked in one operation rather than by changing a password.

Update release procedure

The procedure specifies the frequency of scheduled builds, responsible parties, and the time frame for handling a version rejected by reviewers.

A separate item is the response to changes in store requirements, so that updating publishing rules does not turn into a rush, and the rollback procedure if a fresh build worsened stability.

Case: release without rejections and install growth from a new channel

What was before contacting us

The client — a delivery service — twice failed review in Huawei AppGallery: first, the permission set was broader than the app's features required; then background sync started without user action. Each iteration meant rebuilding, a new justification for review, and waiting.

The release stretched to six weeks instead of the planned two, and the channel itself brought not a single install.

What changed and what happened

We went through the platform requirements line by line: left only the permissions without which the scenario does not work, tied background tasks to explicit user action, and added correct handling of permission denial.

We brought the listing, screenshots, and description to the platform's formats, and ran the build through checks on test devices before submitting.

The third submission passed on the first try. The release time was nine business days from the start of work; in the first month, 23% of installs came from the new channel, and the crash rate at launch fell from 4.1% to 0.6%. The channel stopped being an experiment and became part of the regular release plan.

“Previously, releasing to a new store was a lottery. Now it is a planned task, like an update in the main channel.”

— client's product manager

What to do if AppGallery publication is rejected by moderation?

A moderator rejection is always a specific wording: a reason code and comment text in the Huawei AppGallery developer console.

We parse it literally: technical causes (build signature, permission set, behavior when requesting access) are fixed in the manifest; content ones (description, screenshots, category, age rating) — in the store listing. The class of the cause determines the scope of fixes.

Fixing comments ends not with a code change but with a checklist verification: we reproduce the scenario the moderator pointed to on a clean install and on an update over the previous version.

Resubmission of the build goes with a raised version number — moderation checks it against the rejected one and does not review the same build again.

If the comment is disputable, store rejection appeal works: we attach a video of the scenario, screen screenshots, and a link to the policy clause that permits the behavior.

A response comes within several business days, and a reasoned appeal removes the comment more often than resubmission without explanations.

A separate category is an already deployed build. Fixes must not break compatibility: we verify data migrations and server exchange contracts on an update from the previous version; otherwise, the store will accept the build, but users will get a crash.

If signing keys are lost, the existing app cannot be updated — a new one is published with a different identifier, and the audience with reviews is not transferred.

That is why we keep keys in a secure keystore with backups, and keep comment wordings and moderation responses in a log — this reduces rejection handling to hours.

Frequently asked technical questions about placement and updates

Before starting, clients usually ask the same set of questions: how long to wait for review, what happens to reviews during migration, whether a separate version must be built for each store, and who is responsible for updates after release. Below are short answers based on our experience publishing in Huawei AppGallery and other catalogs.

Can an app be migrated from another store together with reviews?

Technically, yes: we transfer the build and metadata, and the app continues to work for current users. Reviews, rating, and install history are not transferred: they are tied to a listing in a specific catalog.

The rating is built anew, so in the first weeks after release we handle feedback especially carefully.

Do I need to build a separate version for each store?

Yes, and this is normal practice. A separate build is signed with its own key and connects the services of a specific catalog — notifications, maps, payments, analytics. The shared core is the same, so supporting several builds does not turn into developing several apps.

What should I do if the signing key is lost?

The signing key is a critical artifact; its backup is stored separately from the repository, with restricted access. If the key is lost or compromised, recovery goes through catalog support with confirmation of publishing rights.

Without a backup, it will be impossible to update installed copies — you will have to publish a new listing and rebuild the audience.

Who is responsible for updates after release?

The owner of the listing and developer account rights is always the client; this guarantees control over the product.

We handle the technical part: monitor catalog requirements, rebuild for new OS versions, close dependency vulnerabilities, run regression, and release an update with a description of changes.

Let's discuss publishing your app in the store

Estimating an AppGallery publishing task takes one conversation if we have the input data on hand.

Below is a list of what removes almost all questions at the start: the work plan is built from it, and placement timelines are given without the caveat "depends on the store."

• Release build: a signed package ready for upload, version number, and changelog for the update description.
• Signing key and its storage procedure — without access to it, updates and publication recovery become a separate task.
• Developer account access: a role with publishing rights, linked services, account review status.
• Store listing: icon, graphics for different screen sizes, localizations of the name and description, keywords.
• Privacy policy and consent screens — most often this is what returns the app for revision.
• Services the app depends on for operation on the store's devices: notifications, maps, payments, account sign-in — what is already connected and at what stage.
• Deadline constraints: the date by which the app must be available to users, with a margin for moderator review.
• Current store comments if publication has already been rejected: rejection text and materials from the developer console.

With this set, we come back with a task estimate and work plan: what we cover on our side, what is required from you, how long each stage takes, and when the app will appear in the store. Describe the task — we will discuss it concretely.