Same thing here, no changes and all of sudden it stops working, but not for everyone and not all the time. Here's how we get the location: none of accuracy settings work:

export const getPosition = async (): Promise<Location.LocationObject> => {
  if (!(await Location.hasServicesEnabledAsync())) {
    throw new Error('gps disabled');
  }

  const permission = await Location.requestPermissionsAsync();
  if (permission.status === 'granted') {
    /* eslint-disable-next-line */
    const promise1 = new Promise<LocationObject>(async resolve => {
      try {
        const res = await Location.getCurrentPositionAsync({ accuracy: Location.Accuracy.Highest });
        resolve(res);
      } catch (err) {
        //
      }
      try {
        const res = await Location.getCurrentPositionAsync({ accuracy: Location.Accuracy.Lowest });
        resolve(res);
      } catch (err) {
        //
      }
      try {
        const res = await Location.getCurrentPositionAsync({
          accuracy: Location.Accuracy.Balanced,
        });
        resolve(res);
      } catch (err) {
        //
      }
    });
    const promise2 = new Promise<'too-slow'>(resolve => {
      setTimeout(() => resolve('too-slow'), 6000);
    });

    // For whatever weird reason location methods somethings get totally stuck, never resolving. Wait for 6 seconds and deem failed if none of the methods have resolved at that point.
    const possibleLocation = await Promise.race<LocationObject | 'too-slow'>([promise1, promise2]);

    if (possibleLocation !== 'too-slow') {
      return possibleLocation;
    }
    // Everything failed
    const error = new Error('Unable to get location even if services are enabled');
    Sentry.Native.captureException(error);
    throw error;
  }
  throw new Error('permission denied');
};

SDK is 40

Same with SDK41/managed, started erroring today morning, worked fine until then.

Some people reported that {accuracy: 6} or {Location.Accuracy.Low} or {Location.Accuracy.Lowest} worked for them. For us they did not, so we had to change getCurrentPositionAsync() to getLastKnownPositionAsync() everywhere.

It's worth to note that some developers reported the issue starting a week ago others just now. Might be related to an android update?

We are tracking devices that are having this issue.
A large majority of them are from Samsung. That could be a trend, or that could just be that Samsung is a huge Android OEM.

We are tracking devices that are having this issue.
A large majority of them are from Samsung. That could be a trend, or that could just be that Samsung is a huge Android OEM.

This fails for me on my Pixel 3, so it seems to affect more than just Samsung.

We are tracking devices that are having this issue.
A large majority of them are from Samsung. That could be a trend, or that could just be that Samsung is a huge Android OEM.

This fails for me on my Pixel 3, so it seems to affect more than just Samsung.

Yes, we do have a Pixel 3 in our list too.

This fails for me on my Pixel 3, so it seems to affect more than just Samsung.

Also on my LG

also on my Xiaomi Poco X3

We are tracking devices that are having this issue.
A large majority of them are from Samsung. That could be a trend, or that could just be that Samsung is a huge Android OEM.

I have this issue on Huawei using expo 42

Same issue just started happening after few months of it working fine. I did a gradlew clean and reinstalled the app and now the location on Pixel 4 returns :Error: Location provider is unavailable. Make sure that location services are enabled.

On Pixel 2 is working fine. There has been no code changes to this for few months.

Nokia 8 Sirocco (SDK 41) also has the same issue; no changes in code were made.

We have also had some iOS devices getting this issue, based on Sentry data.

Samsung Galaxy s9+ (SDK 41) also has the same issue; no changes in code were made.

please help me .....🙏🙏🙏🙏🙏🙏
for testing using -- REdmi note 8 expo "expo": "~39.0.2", expo --version =

4.11.0

here is my code i tried everything....
useEffect(() => {
(async () => {
try {
if (Platform.OS === "android" && !Constants.isDevice) {
setErrorMsg(
"Oops, this will not work on Snack in an Android emulator. Try it on your device!"
);
return;
}
let { status } = await Location.requestPermissionsAsync();
// let { status } = await Permissions.askAsync(Permissions.LOCATION);
// Alert.alert(status);
if (status !== "granted") {
setErrorMsg("Permission to access location was denied");
return;
}
// let location = await Location.getCurrentPositionAsync({enableHighAccuracy: true})
console.log('longitude is ',)

			let location = await Location.getCurrentPositionAsync({})

			console.log('longitude is ', location)


			setLocation(location);
		} catch (error) {
			// if(Platform.OS==="android"){ location !== undefined
			if (count < 3) {
				setCount(count + 1);
			}
		}
	})();
	// }, []);
}, [count]);

showing --
waiting...

only
please help me into that

@Gautam-24 Only workaround that's working for us is to use Location.getLastKnownPositionAsync();. You can either choose prefer last known or use it as fallback, up to you. This has significantly reduced error rates we are seeing in our application.

Here's a our current implementation, preferring last known.

export const getLocation = async (): Promise<Location.LocationObject> => {
  if (!(await Location.hasServicesEnabledAsync())) {
    throw new Error('gps disabled');
  }

  const permission = await Location.requestPermissionsAsync();
  if (permission.status === 'granted') {
    const lastKnown = await Location.getLastKnownPositionAsync();
    if (lastKnown) {
      try {
        // Update last known behind the scenes
        Location.getCurrentPositionAsync({ accuracy: Location.Accuracy.Balanced });
      } catch (err) {
        //
      }
      return lastKnown;
    }

    /* eslint-disable-next-line */
    const promise1 = new Promise<LocationObject>(async resolve => {
      try {
        const res = await Location.getCurrentPositionAsync({ accuracy: Location.Accuracy.Highest });
        resolve(res);
      } catch (err) {
        //
      }
      try {
        const res = await Location.getCurrentPositionAsync({ accuracy: Location.Accuracy.Lowest });
        resolve(res);
      } catch (err) {
        //
      }
      try {
        const res = await Location.getCurrentPositionAsync({
          accuracy: Location.Accuracy.Balanced,
        });
        resolve(res);
      } catch (err) {
        //
      }
    });
    const promise2 = new Promise<'too-slow'>(resolve => {
      setTimeout(() => resolve('too-slow'), 6000);
    });

    // For whatever weird reason location methods somethings get totally stuck, never resolving. Wait for 6 seconds and deem failed if none of the methods have resolved at that point.
    const possibleLocation = await Promise.race<LocationObject | 'too-slow'>([promise1, promise2]);

    if (possibleLocation !== 'too-slow') {
      return possibleLocation;
    }
    // Everything failed
    const error = new Error('Unable to get location even if services are enabled');
    Sentry.Native.captureException(error);
    throw error;
  }
  throw new Error('permission denied');
};

@Gautam-24 Only workaround that's working for us is to use Location.getLastKnownPositionAsync();. You can either choose prefer last known or use it as fallback, up to you. This has significantly reduced error rates we are seeing in our application.

Here's a our current implementation, preferring last known.

export const getLocation = async (): Promise<Location.LocationObject> => {
  if (!(await Location.hasServicesEnabledAsync())) {
    throw new Error('gps disabled');
  }

  const permission = await Location.requestPermissionsAsync();
  if (permission.status === 'granted') {
    const lastKnown = await Location.getLastKnownPositionAsync();
    if (lastKnown) {
      try {
        // Update last known behind the scenes
        Location.getCurrentPositionAsync({ accuracy: Location.Accuracy.Balanced });
      } catch (err) {
        //
      }
      return lastKnown;
    }

    /* eslint-disable-next-line */
    const promise1 = new Promise<LocationObject>(async resolve => {
      try {
        const res = await Location.getCurrentPositionAsync({ accuracy: Location.Accuracy.Highest });
        resolve(res);
      } catch (err) {
        //
      }
      try {
        const res = await Location.getCurrentPositionAsync({ accuracy: Location.Accuracy.Lowest });
        resolve(res);
      } catch (err) {
        //
      }
      try {
        const res = await Location.getCurrentPositionAsync({
          accuracy: Location.Accuracy.Balanced,
        });
        resolve(res);
      } catch (err) {
        //
      }
    });
    const promise2 = new Promise<'too-slow'>(resolve => {
      setTimeout(() => resolve('too-slow'), 6000);
    });

    // For whatever weird reason location methods somethings get totally stuck, never resolving. Wait for 6 seconds and deem failed if none of the methods have resolved at that point.
    const possibleLocation = await Promise.race<LocationObject | 'too-slow'>([promise1, promise2]);

    if (possibleLocation !== 'too-slow') {
      return possibleLocation;
    }
    // Everything failed
    const error = new Error('Unable to get location even if services are enabled');
    Sentry.Native.captureException(error);
    throw error;
  }
  throw new Error('permission denied');
};

hi Thanks for your response can we please connect i am still facing issues..

https://meet.google.com/jxg-zuhh-cpy

thanks
gautam

We are up to 103 users and climbing.
It is no longer a trend of Samsung devices, but a whole bunch of different ones.

Same here. I Tryed with everything, emulators, real devices, restarting phone makes it work but only the first time, then the error comes back. Workaround that worked for me (but is not suitable for my projects): set the accuracy to "lowest".

Location.getCurrentPositionAsync({ accuracy: Location.Accuracy.Lowest });

I'm using Xiaomi Mi 8 Lite, Moto G4 Play, Pixel 4 (emulator).
Expo SDK 41
----------------------- UPDATE --------------------------
Now, I'm getting same issue with workaround. 😢

Just to add my experience with this issue to the data collection - the ({ accuracy: Location.Accuracy.Lowest }); workaround only seems to work with WIFI internet, not mobile data. But perhaps this is a feature of Lowest, not a bug?

(Other aspects of my app works)

Samsung Galaxy S7, SDK 41

I've had this issue with different accuracy settings on different Samsung phones.

I've been trying the above suggestion of falling back to the last known location, but that doesn't seem to be a sufficient solution as the last known location might not be available when the app is first used for quite some time.

Some people have suggested simply switching to a different accuracy level, but this also fails to solve the problem as different devices seem to fail with different accuracy settings.

I've found an odd solution that seems to solve the problem... spamming the phone for location for one accuracy setting.

So, if Location.getCurrentPositionAsync( ... ) fails, I simply run it again, and again, and again... and after about 21 times, the phone returns the location.

It doesn't take long for the app to go through these 21 iterations, so the location is found pretty quickly.

This seems like a ridiculous thing to have to do, but for now it seems to be the only solution.

... btw if you want to deal with promises in a more elegant way, checkout https://dzone.com/articles/promises-that-dont-fail . It allows you to do away with tedious promise notation and try-catch blocks and simply do async-await functions with if-else blocks.

I was able to do a Software upgrade on one of the two Samsungs I'm testing with. It now only takes one try to get the location. The other requires the spamming solution.

Code solution for the above:

// ----------- SUBSCRIBE TO TRACKING LOCATION FUNCTION -----------------
  const subscribeToTrackingCurrentLocation = useCallback(() => {
    // ----------- TRACKING LOCATION SUBSCRIPTION HANDLER -----------------
    const getAndSetLocation = async () => {
      if (trackingPermission === "granted") {
        let positionTry;

        let tryCount = 0;

        do {
          positionTry = await sureThing(
            Location.getCurrentPositionAsync({
              accuracy: Location.Accuracy.Highest,
            }),
          );

          tryCount++;
        } while (!positionTry.ok && tryCount < 50);

        if (positionTry.ok) {
          console.log(`TRIES TAKEN TO GET LOCATION: ${tryCount}`);

          const position = positionTry.result;

          const { longitude, latitude } = position.coords;
          const tempLocation = { longitude, latitude };

          setLocation(tempLocation);
          console.log(`LOCATION: ${JSON.stringify(tempLocation)}`);
        } else {
          const positionError = positionTry.error;

          console.log(positionError);
        }
      }
    };

    // ----------- INITIALIZE LOCATION -----------------
    getAndSetLocation();


    // ----------- CREATE THE LOCATION SUBSCRIPTION INTERVAL -----------------
    const interval = setInterval(() => {
      getAndSetLocation();
    }, TRACKING_LOCATION_UPDATE_INTERVAL_MILLIS);

    // ----------- RETURN THE LOCATION SUBSCRIPTION INTERVAL -----------------
    return () => clearInterval(interval);
  }, [trackingPermission]);

  // ----------- SUBSCRIBE TO TRACKING LOCATION -----------------
  useEffect(() => {
    if (trackingPermission === "granted") {
      return subscribeToTrackingCurrentLocation();
    }
  }, [trackingPermission, subscribeToTrackingCurrentLocation]);

This assumes that you store the result of Location.requestForegroundPermissionsAsync() as a trackingPermission state (via useState) in the same component, and that you save the resultant location as a location state via setLocation.

You can replace TRACKING_LOCATION_UPDATE_INTERVAL_MILLIS with any constant that indicates how often the location should be polled for.

I actually use React Context instead of a component, but that is just my way of doing it.

Turn the above into what you need for your scenario.

Thank you for the suggestion but trying for 50 times isn't an ideal scenario for us and is more if a workaround than solution. Our clients are already disappointed in waiting for location locks before this happened. We have a smaller scale version of what you are doing here, just not that many tries, and we still get locks failing in places.

As for our own research, we found on one device that going back to Google Play Services 16.0.89 from July fixes the issues. Google Play Services plays a part in location acquisition on Google Play enabled devices, and Expo requires it from the logs I pulled from Android while trying on an AOSP device.

My working theory is that Google updated Play Services and broke something.

... we found on one device that going back to Google Play Services 16.0.89 from July fixes the issues ...

Same here. After uninstalling Google Play Services 21.30.16 location is working again.

It looks like @lukmccall pushed some changes about this to master. Are they going to be available to 41, 40 SDK's?

Fixed by #14281.

The fix will be available in the next SDK. Unfortunately, we don't plan to backport this fix to the older SDKs.

Wait, what?! We didn't have any possibility to check if your fixes work, and you closing this? I mean you could not possibly check it on all devices we listed (and I mean real devices)). SDK 42 is not even half a year old, so most applications still use 40/41. We are talking about production applications and paying expo money for build (so not about you working for free), at least in the case of the application I work on.

I have a question... in versions prior to expo 42, location worked correctly, after updating the problems began. my question is: ¿rollback expo to 38 possible, and doing this could avoid this issues?

I have a question... in versions prior to expo 42, location worked correctly, after updating the problems began. my question is: ¿rollback expo to 38 possible, and doing this could avoid this issues?

My understanding is that this is to do with the version of Google Play services on the device and nothing to do with the Expo SDK version. So downgrading the Expo SDK will not fix the problem.

If you go into the device settings and find the "Google Play services" app and check the version you will see something like this:

Version 21.30.16 (100408-391784508)

If I check the info in the Play Store it says:

Updated on 23 Aug 2021

For everyone running into this issue locally with the Expo Go app, new binaries are deployed to production and will soon-ish be deployed to turtle. For now, you should be able to install the newer Expo Go versions using the EXPO_STAGING=1 environment variable.

Edit, the Expo Go binaries are available through the Expo CLI. Turtle has been updated with new shell apps as well. Create a new build with $ expo build:android to use the workaround.

Managed workflow

• Go to your Expo project
• $ expo client:install:android
• Install recommended version

Here is a quick overview of the SDK and the Expo Go version you should be getting, and if it includes the workaround when building with $ expo build:android.

Bare workflow (or EAS)

If you are using the bare workflow, make sure you installed expo-location@12.1.3, currently the next tag. This version includes the workaround. Note, this will be the only backported version we will send out through npm. Always update to the latest versions when using the bare workflow.

Alternatively, you can apply the patch from #14281 manually using patch-package. This also works in EAS.

Would it be possible to get more details on what the workaround is, how it fixes the problem, etc?

Does this mean that we won't need to upgrade our SDK version or the expo-location package to get the workaround?

I think I'm missing something - we're using the managed workflow and I've run the $ expo client:install:android command and it prompted me to install the correct client version (2.18.8 for SDK40) but after rebuilding this morning and submitting to our internal test track on the Play store I'm still seeing the location failure.

However, I'm still also seeing "Client version: 2.21.5" in my Expo Go app, which is why I assume I'm missing something. Any advice is appreciated!

I think I'm missing something - we're using the managed workflow and I've run the $ expo client:install:android command and it prompted me to install the correct client version (2.18.8 for SDK40) but after rebuilding this morning and submitting to our internal test track on the Play store I'm still seeing the location failure.

However, I'm still also seeing "Client version: 2.21.5" in my Expo Go app, which is why I assume I'm missing something. Any advice is appreciated!

I noticed that builds on expo, even when the package is pointing at 12.1.3, are building 12.1.2. Lost on how to continue.

I think I'm missing something - we're using the managed workflow and I've run the $ expo client:install:android command and it prompted me to install the correct client version (2.18.8 for SDK40) but after rebuilding this morning and submitting to our internal test track on the Play store I'm still seeing the location failure.

However, I'm still also seeing "Client version: 2.21.5" in my Expo Go app, which is why I assume I'm missing something. Any advice is appreciated!

Have you upgrade expo to 42.0.3? in the process reinstall explo-cli from emulator (also updates the expo go app from your device).

When i do this, location is back to my projects, also the signed builds, Don't Forget that now await Location.requestPermissionsAsync(); is deprecated, use instead await Location.requestForegroundPermissionsAsync(); or background... hope it helps

I don't see that the issue is fully fixed - still can't get accurate location in a specific case:
From what i've been seeing the phone can't get accurate location without using wifi scanning.
Is that ok? what's the solution for those who need accurate location?

Location settings	Wifi & Bluetooth scanning

@byCedric Does this mean there will be no patch for Expo 39 or is it still in the works?

Does this mean that we won't need to upgrade our SDK version or the expo-location package to get the workaround?

• If you are using a managed app and are using the classic builds ($ expo build:android): you don't need to upgrade expo-location. The native code change is already applied in Turtle and is included in all new builds.

• If you are using a managed app, but using EAS instead: you have to upgrade expo-location. In EAS we build the app from scratch, based on your current modules.

• If you are using the bare workflow: you have to upgrade expo-location.

I think I'm missing something - we're using the managed workflow and I've run the $ expo client:install:android command and it prompted me to install the correct client version (2.18.8 for SDK40) but after rebuilding this morning and submitting to our internal test track on the Play store I'm still seeing the location failure.

However, I'm still also seeing "Client version: 2.21.5" in my Expo Go app, which is why I assume I'm missing something. Any advice is appreciated!

Double-check if a simulator or other device is connected. It will only install on the first device listed from $ adb devices. If you are still having issues, please open a new issue at https://github.com/expo/expo-cli

I don't see that the issue is fully fixed - still can't get accurate location in a specific case:
From what i've been seeing the phone can't get accurate location without using wifi scanning.
Is that ok? what's the solution for those who need accurate location?

I can't reproduce this issue, both with and without the wifi/bluetooth scanning the location is returned. If you think this is an issue with Expo, please open a new issue with a reproducible example. Happy to take a look!

@byCedric Does this mean there will be no patch for Expo 39 or is it still in the works?

Unfortunately, the SDK 39 version didn't pass the tests. Although the location worked fine with the workaround, there were other issues. I hope to push out a newer version for SDK 39 somewhere next week.

Also, be aware that SDK 39 is going to be deprecated once we launch SDK 43. I would heavily recommend upgrading to SDK 40 or higher.

Hi everyone, I will lock the thread to keep this answer "findable" for everyone. To reiterate on #14248 (comment):

Status

• The updated Expo Go binaries are available through the Expo CLI, using $ expo client:install:android.
• Turtle has been (partially) updated with the new shell apps for people using $ expo build:android.

Managed workflow

To install the new Expo Go binaries:

• Go to your Expo project
• Run $ expo client:install:android
• Install the recommended version (see table below for exact version)

To upgrade your app with the workaround, create a new build with $ expo build:android. You don't need to upgrade expo-location because this change is already applied in Turtle.

Bare workflow (and EAS projects)

If you are using the bare workflow or EAS to build your app, make sure you installed expo-location@12.1.3. All versions after this one will include the workaround. We won't backport the workaround to older versions on npm.

Example project

Because some of you weren't sure if the workaround solved the issue, I created an example project for you to test with. It's a simple managed app to fetch your location. You can change the accuracy within the app and see the results.

You can find the APKs with the workaround in these workflows:

• SDK 42 - https://github.com/byCedric/expo-issue-14248/actions/runs/1224872488
• SDK 41 - https://github.com/byCedric/expo-issue-14248/actions/runs/1224886303
• SDK 40 - https://github.com/byCedric/expo-issue-14248/actions/runs/1224900143
• SDK 39 - pending