expo: [Android] getForegroundPermissionsAsync returns canAskAgain false even though location permission can be requested
Summary
getForegroundPermissionsAsync returns status: denied, canAskAgain: false even though in reality you can and if called requestForegroundPermissionsAsync it will actually prompt the user.
To reproduce please use the minimal reproducible example below with expo go or custom dev client.
First open the app and check permissions which will be undetermined. Next ask for permissions and give only this time which translates to ask every time in the settings. Next request location and everything is successful as shown in the video:
Now kill the app and lock the device for a couple of seconds(i guess this ends the only this time session). Now open the app again and check permission, you will notice that status is denied and canAskAgain is false, where in reality canAskAgain should true because you gave ask every time permission and going on to request location will be successful as well as requesting location after.
Expected behavior: canAskAgain should be true in this case since I actually can ask again
What platform(s) does this occur on?
Android
Environment
expo-env-info 1.0.5 environment info: System: OS: macOS 12.5.1 Shell: 5.8.1 - /bin/zsh Binaries: Node: 16.16.0 - ~/.nvm/versions/node/v16.16.0/bin/node Yarn: 1.22.19 - ~/.nvm/versions/node/v16.16.0/bin/yarn npm: 8.11.0 - ~/.nvm/versions/node/v16.16.0/bin/npm Watchman: 2022.07.04.00 - /usr/local/bin/watchman Managers: CocoaPods: 1.11.3 - /usr/local/bin/pod SDKs: iOS SDK: Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5 IDEs: Android Studio: 2021.2 AI-212.5712.43.2112.8609683 Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild npmPackages: expo: ~46.0.9 => 46.0.10 react: 18.0.0 => 18.0.0 react-dom: 18.0.0 => 18.0.0 react-native: 0.69.5 => 0.69.5 react-native-web: ~0.18.7 => 0.18.9 npmGlobalPackages: eas-cli: 2.1.0 expo-cli: 6.0.1 Expo Workflow: managed
Minimal reproducible example
import {
getCurrentPositionAsync,
getForegroundPermissionsAsync,
requestForegroundPermissionsAsync,
} from "expo-location";
import { StatusBar } from "expo-status-bar";
import { Alert, Button, StyleSheet, Text, View } from "react-native";
async function checkPermissions() {
const currentPermissions = await getForegroundPermissionsAsync();
Alert.alert("currentPermissions", JSON.stringify(currentPermissions), [
{ text: "dismiss" },
{
text: "request permissions",
onPress: requestPermissions,
},
]);
}
async function requestPermissions() {
const permissions = await requestForegroundPermissionsAsync();
Alert.alert("permissions", JSON.stringify(permissions), [
{ text: "dismiss" },
{
text: "request location",
onPress: requestLocation,
},
]);
}
async function requestLocation() {
const location = await getCurrentPositionAsync();
Alert.alert("location", JSON.stringify(location));
}
export default function App() {
return (
<View style={styles.container}>
<Button title="request location" onPress={checkPermissions} />
<StatusBar style="auto" />
</View>
);
}
const styles = StyleSheet.create({
container: {
flex: 1,
backgroundColor: "#fff",
alignItems: "center",
justifyContent: "center",
},
});
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 26 (1 by maintainers)
There is a minimal example. I don’t get why it was closed. @brentvatne any insights on why this happened?
the issue is still valid
I am still seeing this behavior in expo v49, not sure why this issue is closed if there is a minimal reproducible example. This renders location permissions fundamentally broken on Android.
the issue is still valid
Hi there! It looks like your issue requires a minimal reproducible example, but it is invalid or absent. Please prepare such an example and share it in a new issue.
The best way to get attention to your issue is to provide a clean and easy way for a developer to reproduce the issue on their own machine. Please do not provide your entire project, or a project with more code than is necessary to reproduce the issue.
A side benefit of going through the process of narrowing down the minimal amount of code needed to reproduce the issue is that you may get lucky and discover that the bug is due to a mistake in your application code that you can quickly fix on your own.
Resources
Common concerns
“I’ve only been able to reproduce it in private, proprietary code”
You may not have spent enough time narrowing down the root cause of the issue. Try out the techniques discussed in this manual debugging guide to learn how to isolate the problem from the rest of your codebase.
“I didn’t have time to create one”
That’s understandable, it can take some time to prepare. We ask that you hold off on filing an issue until you are able to fully complete the required fields in the issue template.
“You can reproduce it by yourself by creating a project and following these steps”
This is useful knowledge, but it’s still valuable to have the resulting project that is produced from running the steps, where you have verified you can reproduce the issue.
I think I’ve found a workaround @itsramiel,
requestPermission()from theuseForegroundPermissionshook returns a promise, so await or chain a then on that and the response is correct with thecanAskAgainso I will save that in local storage.It’s not ideal but better than the current behaviour imo, also need to check the solution works in iOS as my development is only on android for now