Location permission denied: what your Android app does next is the real design

Someone opens a café app and taps "Find cafés near me." Android asks for location access. They choose "Don't allow."

Now what?

Sometimes the answer is: nothing. A dead-end screen, a "location is required" message, maybe a button that fires the same dialog again. I think that is a poor experience when the app could offer another way forward.

The person said no to one way of answering "where should I search?" They didn't say no to the café. They may well know exactly which city they want. If the app can search by city, it already has a second way to help, and all it has to do is say so.

A quick note on the sample before we go on. The permission dialog and app screens in the video are captures from an Android emulator. The character and surroundings are illustrated, and the café names and results are fictional.

Start with the task, not the permission

Location is one way to find a place to search. It isn't the only way, and sometimes it isn't even the best one. Someone planning tomorrow's trip will probably type a city whether or not you have their GPS.

The sample shows two outcomes after the same denial. In the first, the app stops at a message saying location is required. In the second, it explains that location access wasn't granted and offers a city field. Type a city, tap Search, and you land on a screen with fixed illustrative results, not results from a real search service.

Same denial, completely different experience. One of them treats "no" as the end of the conversation. The other treats it as new information.

To be fair, this won't work for every feature. A navigation app can't produce a live position without a real location source, and pretending otherwise would be worse than the dead end. A café directory is different: it can search a place the person gives it. So pick your fallback based on the task, and be upfront when the results will be less precise or less convenient than the location-based version.

Ask less often than you think you need to

Before you build a permission flow, ask whether the task needs device location at all. If the need is occasional, Android's own permission-minimization guidance suggests letting people enter an address or postal code manually. It also covers other approaches depending on how often and how precisely you need location.

If the person does choose "Find cafés near me" and you genuinely need the device's position, ask in context, at that moment, not on first launch. And don't request precise location when approximate will do. Approximate location may be enough for a café search, depending on the feature and the accuracy it needs. What the system shows will vary with the Android version, the permissions you request and what the person chose before, so don't hard-code assumptions about the dialog.

Treat denial as a state you designed

A denied permission should land on a screen somebody thought about, not on whatever the error path happened to produce. For this example, that means four things.

1. Say what changed, in plain words. "Location access wasn't granted. Search by city instead" tells the person why the nearby search can't run and what to do next. No blame, no jargon.
2. Make the alternative actually work. A city field that returns nothing useful is worse than no field. Handle empty input, no results and network errors too, because those are the first things a real person will hit.
3. Leave everything else alone. Someone who denied location can still browse their saved places. If a feature doesn't need location, don't punish it for the permission.
4. Don't nag. Re-showing the same request right after a "no" is how you teach people to distrust your app. If they later want a location-dependent feature, give them a clear, deliberate way to turn it on.

None of this is exotic. Android's guidance says the same thing: request permission in context, check it every time an operation needs it, and degrade gracefully when access is denied or revoked. See Request runtime permissions.

Test the whole path, not just the dialog

Seeing the permission dialog appear proves very little. What matters is whether a person can understand what happened and still finish what they came to do.

On the Android versions you support, try these:

• Deny the request. Is the change explained? Can the person reach the alternative without hunting?
• Use the alternative end to end. Enter a city, submit it, follow the results to the next meaningful action. Then break it: empty input, no matches, a failed request.
• Grant, then revoke in system settings. Come back to the app and trigger the location action again. Does it re-check access and recover, or crash?
• Grant approximate, not precise. Does the feature work with the accuracy it got, or at least explain its limit?
• Walk away from the location flow. Can the rest of the app still be used?
• Restart the app. Does what's on screen match the current permission and what the person chose?

What we did and didn't verify

The sample is deliberately small. On an Android 16 / API 36 emulator, we captured a real approximate-location prompt, denied it, entered a city and reached the alternative results screen. The results are fixed examples, not output from a search service. We didn't verify the flow on a physical device, and we didn't test every Android version. A production app needs its own search implementation and its own tests for the devices and permission states it supports.

So take the sample as a demonstration of the shape, not as proof it works everywhere.

The question that matters

After someone says no, what can they still do?

In this example, a city field gives them a way forward that the nearby search alone never would. That's a small amount of work for the difference between an app that works with the person's decision and one that argues with it.

Disclosure: This article was drafted with AI assistance.