The user denied the camera permission once — now tapping the camera button in the Mini Program does nothing. Do they have to open Settings themselves?

Bottom line first: after a user taps Deny on camera, photo album, or location permission, tapping the related button in the Mini Program often does nothing. Most of the time this is not broken code — it is the authorization mechanism itself: once the same permission has been denied, neither the platform nor the OS will show a second prompt automatically. In 2026, the common approach is to read the authorization state with wx.getSetting first, show a clear message when it has been denied, guide the user to open the permission manually in Settings, and prepare an alternative path that does not depend on that permission.

Why does it go silent after permission is denied?

Capabilities such as camera, photo album, location, and microphone in a Mini Program go through the platform's wrapped authorization flow: the system shows a prompt on first call, a tap on Allow makes it valid long-term, and a tap on Deny sends the current call straight into the failure callback — and that authorization scope will not prompt automatically again. This differs from the web experience, where a prompt may reappear each time, which is why many clients assume during acceptance testing that the button is broken.

Also distinguish two layers of switches. One is the phone OS permission granted to the Mini Program's host app (such as WeChat), and the other is the Mini Program's own authorization for that scope. The OS allowing it while the scope is denied — or the reverse — will both make the API call fail. Around launch in 2026, you also need to configure the user privacy protection guideline in the platform backend, declaring what information is collected; if it is not configured, or the declaration does not match what is actually collected, the API will return a failure directly, which is easily misdiagnosed as a permission problem.

• Calling it again after denial: it will keep going into the failure callback and will not prompt again; on the user side this looks like “nothing happens when I tap.”
• The two platforms behave differently: on iOS, after switching back from system Settings, the page often needs to re-fetch the state before it refreshes.
• Privacy guideline not configured: this is a platform compliance prerequisite, and the error message does not look the same as a permission denial — read the error carefully.

First tell whether it was “denied” or “never triggered”

When troubleshooting, do not start by changing the permission code. First check whether tapping the button enters a callback and whether the log shows a clear error message. A practical habit is to print the callback error as-is; keywords such as auth deny and authorize:fail can basically locate the authorization step. If not even a callback is entered, the problem is probably button binding, an overlay intercepting the tap, or the page not being fully rendered — nothing to do with permissions.

The pass bar is very concrete: tap once in the developer tools and once on a real device, and both should return a readable error message rather than failing silently. If that cannot be done, any later discussion of guidance flows is just spinning wheels.

• Counterexample 1: the button is covered by a fixed bottom overlay, so the tap actually lands on another element.
• Counterexample 2: the check runs only once on first page load, and there is no re-check after the user changes the permission in Settings and comes back.
• Counterexample 3: treating the OS-level prompt and the Mini Program scope as the same thing, so changing the system setting is mistaken for fixing the Mini Program.

A four-step authorization state check

This order is organized around delivery acceptance habits: read the state first, then decide the action. It avoids rework such as “the button stays dead after the user denies permission.” Each step has a different focus, and skipping a step makes it easy to miss the fallback.

1. Check the state: read the authorization settings. For the relevant scope, true means authorized, false means explicitly denied, and undefined means the user has not been asked yet. The three states require completely different handling.
2. Branch: if undefined, call the API directly and let it prompt naturally; if false, stop calling it and go straight to the message and guidance.
3. Provide an exit: the guidance must be tied to a user tap — opening the Settings page must be triggered by a user gesture, and an automatic call will not be accepted. The message should state clearly which permission to enable and what it is used for.
4. Fallback and degrade: if the user still does not authorize, offer an alternative path, such as selecting a city manually, choosing an image from chat history, or skipping this step and submitting first.

Steps three and four are often skipped, leaving the user stuck on that screen with no option but to exit and re-enter. Based on project delivery experience, guidance plus fallback for one page typically takes an experience range of 0.5 to 1 person-day, making it a patch with a good return on effort.

Three handling options: which one fits better

When authorization is denied, the handling method depends on how important that permission is to the main flow. Core permissions are worth the effort of guidance; optional permissions are better handled by direct degradation — there is no need to force every user to enable them.

• Guide to enable: suitable for permissions the main flow depends on, such as camera, photo album, and scanning. Low cost and a short path; the downside is that the user has to jump to the Settings page, and some proportion will drop off along the way.
• Feature degradation: suitable for optional permissions such as location and contacts. After the user denies them, the main flow can still be completed, so the experience loss is small; the cost is lower data accuracy or convenience.
• Pre-explanation page: suitable when users do not understand “why permission is needed as soon as I enter.” Explain the purpose first, then trigger authorization; acceptance is usually higher, at the cost of one extra tap.

In terms of experience range, a change that only shows a message without providing an exit is almost no change at all; a combination of one or two of these three options is what passes acceptance. When delivering photo-upload requirements, Xiyue Company writes “what happens after a denial” into the interaction spec rather than leaving it to be patched after launch.

Applicable scenarios and boundaries

Scenarios that need denial handling share a common trait: the permission directly determines whether the main flow can be completed. Photo upload, scan-to-identify, choosing a store by location, and saving an image to the album all belong to this group. Conversely, pages that only browse products, read articles, or fill in ordinary forms can be completed without permission; forcing guidance in only disturbs users.

The boundary can be stated plainly: if the main flow becomes completely impassable after a permission is denied and there is no alternative path at all, the problem lies in requirements design and flow planning, not in poorly written permission code. Such cases should be confirmed during the prototype stage, not fixed only after testing reports that users are stuck.

Common pitfalls in delivery

Permission issues are easily underestimated at the testing stage because developers' own phones have usually already tapped Allow. Switching to a test device that has never been authorized and adding a denial path usually exposes most of the problems.

• Checking only once at startup, so when the user changes permission in Settings midway and returns, it has not taken effect in the Mini Program.
• Putting the Settings-page-opening capability into an automatic flow; without a user tap, the call is ineffective.
• No feedback at all after denial, so the user thinks it is frozen and taps many times in a row.
• The privacy protection guideline is not configured, or the declared information does not match what is actually collected, causing problems both in review and at API call time.
• Testing only the allow path, not the three combinations: deny, deny-then-enable, and system permission off.

Frequently asked questions

If the user enables the permission in Settings, do they still need to restart the Mini Program?

Usually not. Re-checking the authorization state in the page-show lifecycle when the app returns to the foreground is enough for it to take effect. On some device models or OS versions, the page needs to be re-entered before it refreshes; this is a typical difference.

Do iOS and Android behave the same for authorization?

Not exactly. The OS-level permission switch and the Mini Program scope are two separate things. On iOS, the state more often fails to refresh after the user returns from system Settings, so the re-check should be done on both platforms.

Will guiding the user to the Settings page always open it?

Not necessarily. This capability must be triggered by a user tap gesture; an automatic call will fail. It can only open the permission switches related to this Mini Program, not the full system Settings.

After location is denied, can we still know roughly which city the user is in?

You can use a fallback, such as letting the user select a city manually or using coarse network-based location, but accuracy will drop and it cannot be used as precise location.

Implementation advice: make the four steps — deny → message → guide to Settings → fallback path — a fixed checklist item for camera, scanning, and location pages, and walk through them on a real device that has never been authorized before testing. This approach suits features where permission affects the main flow; purely display pages can skip it, avoiding unnecessary interruptions just to look complete.