When should I ask for permissions?

In context, at the moment the feature that needs them is used, rather than all at once on launch. Show a clear in-game explanation of why the permission helps before the system prompt, since a confused player denies by default and on some platforms the system dialog only ever appears once, so you effectively get one chance to ask.

What happens if a player denies a permission?

The game must keep working with the feature degraded, never crash or lock the player out over an optional permission. Run the game with each permission denied and confirm the dependent feature falls back gracefully, and that the player is not nagged on every launch, which is hostile and often against platform policy.

How do I re-request a permission that was denied?

Once permanently denied, the OS usually will not show the prompt again, so a request call does nothing. Detect that state and route the player to the system settings with clear instructions, then detect the grant when they return so the feature works without a restart. Test the full deny, settings, grant, return loop.

QA Testing for First Launch Permissions

Quick answer: First launch is where permission handling breaks, because most testing happens with permissions already granted. Test the prompt timing and wording, confirm the game works when a player denies every permission, and verify you can re-request or guide the player to settings later. Test permanent denial and revocation mid-use too. Capture the permission state with each report so denial-related bugs are obvious.

The first time a player opens your game is the only time they see the initial permission prompts, and it is the moment most QA never properly tests because every developer device already granted everything long ago. Players are increasingly cautious and deny permissions freely, especially for notifications, location, or storage they do not see why a game needs. A game that assumes a permission was granted will crash, hang, or silently break a feature the moment a player says no. This post covers how to QA first launch permissions: when and how you prompt, handling denial gracefully, and re-requesting or routing players to settings when they change their mind.

Get the prompt timing and context right

The worst permission experience is a wall of prompts the instant the game opens, before the player understands why anything is needed. Test that permissions are requested in context, at the moment the feature that needs them is used, rather than all at once on launch. A microphone prompt should appear when the player enables voice chat, not on the splash screen. Verify the timing on a truly fresh install, since that is the only state where the prompts actually appear, and a developer device that already granted them will never show you the first-run flow.

Wording and pre-prompts matter because a denied permission is often hard to recover. Test any in-game explanation you show before the system prompt and confirm it clearly states why the permission helps the player, since a confused player denies by default. On iOS especially, the system permission dialog typically only appears once, so a player who denies without understanding may never be asked again by the OS. Verify your pre-prompt and timing give the player the context to make an informed choice, because you usually get exactly one shot at the system prompt.

Make denial a fully supported path

The central test is that the game works when the player denies a permission, because denial is common and must never be treated as an error state. For every permission you request, run the game with it denied and confirm the dependent feature degrades gracefully: voice chat disabled but the game playable, no push notifications but everything else intact, no photo access but the avatar falls back to a default. The bug to hunt is a crash or a hang on the code path that assumed the permission was granted and dereferenced a resource that does not exist.

Denial should not nag or block. Test that a player who declined a non-essential permission is not repeatedly prompted on every launch, which is hostile and often violates platform policy, and that they are never locked out of the game over an optional permission. Distinguish in your testing between permissions that are genuinely required for the app to function and those that gate a single feature, and confirm only the truly essential ones can stop progress, with a clear explanation, while everything optional simply turns off the corresponding feature quietly and lets the player continue.

Handle permanent denial and re-requesting

Once a player denies a permission, especially permanently, your app usually cannot show the system prompt again, and a button that calls the request API does nothing in that state. Test the permanently-denied case: confirm that instead of a dead prompt, the game detects the denial and offers to open the system settings where the player can grant it manually. A re-request button that silently does nothing because the OS will not show the dialog is a confusing bug, so verify the game routes the player to settings with clear instructions in that state.

Test the return trip from settings, because it is a real transition that breaks code. When the player grants the permission in settings and returns to the game, the app must detect the new grant, often the game was backgrounded during the settings visit, and enable the feature without requiring a restart. Test the full loop: deny, get routed to settings, grant there, return, and confirm the feature now works. Also test the reverse, granting then revoking in settings while the app runs, since a permission can disappear mid-use and code holding a now-invalid handle must handle that gracefully.

Cover the platform differences and edge cases

Permission models differ between platforms and OS versions, and the differences hide bugs. Newer Android versions split storage into scoped access and add a separate notifications permission, while older ones grant at install time, so test across the OS versions you support, not just the newest. Some permissions have a one-time-allow or allow-while-using option that grants temporarily, so test that your feature handles a permission that was available a moment ago and is gone the next session, which is easy to forget when you only ever test the permanent grant.

Test the unusual entry points too. A player who arrives through a deep link or a notification may hit a feature that needs a permission before they have seen your normal onboarding, so confirm the prompt and the denial handling still work from those paths. Test repeatedly reinstalling to reset permission state, since that is the only reliable way to see the first-run flow again, and consider a developer build that resets permissions on demand so testers do not have to reinstall constantly to exercise the path that real players hit exactly once.

Setting it up with Bugnet

Permission bugs are easy to miss internally because developer devices have everything granted, and the failures only appear for players who denied. Bugnet's in-game report button captures the game state, and a custom field recording the grant status of each permission turns a vague feature-not-working report into an obvious one: a cluster of broken-voice-chat reports that all show the microphone denied tells you instantly the denial path, not the feature itself, is the problem. That context is exactly what is invisible on a developer device that granted everything.

Because a denial-path crash hits every player who declined the same permission, Bugnet's occurrence grouping folds those crashes into one issue with a count and a shared stack trace, making a permission-related crash stand out clearly. Filtering reports by the permission-state custom field lets you see how many of your players actually deny a given permission, which is valuable product data on its own, and confirm whether a reported issue is a real bug on the denial path or simply expected degraded behavior for a player who said no.

Test the first run on purpose

The first-run permission flow needs deliberate setup because it is invisible after the first launch. Build a test pass run from a fresh install, or a permission reset, that covers: each permission granted, each denied, each permanently denied with the route to settings, and the grant-in-settings return trip. Add the revoke-mid-use case and the deep-link entry. Reinstalling between runs is tedious, so a developer affordance to reset permissions pays for itself by making this path easy to exercise on every release rather than once at launch.

Re-run the permission pass whenever you add a feature that needs a permission, target a new OS version, or change onboarding, since each can reintroduce a broken denial path. Respecting a player's choice to deny is both a quality and a trust matter, and increasingly a platform-policy one, so a game that works cleanly no matter what the player allows feels considerate and reliable. The first thirty seconds set the tone, and a smooth, respectful permission flow is a quiet but real part of a good first impression.

Players deny permissions freely, and developer devices hide it. Test from a fresh install, make denial a supported path, and route to settings when the OS will not prompt again.