Connect-app requires location to connect to garmin device

• Read https://forums.garmin.com/showthread.php?344660-Default-Sync-only-works-with-location-services-turned-on&p=813348#post813348
  
• Take it up with Google if you don't like the requirement it has imposed.
  
• As you've already noted, there is currently no such requirement for iOS, so it's up to you as the end-user whether to abandon Android and use iOS devices instead if Google won't budge on your say-so.
  

Thank you for the Info! (I didn't just searched for location, else I would have found it.. My apologies) I just switched back to Android from iOS. Damn this is pity! When you think iOS is bad, Google comes with this *unfortunate thing* (to say it nice).
=> Ok, I will have to life with it. (no way to alter this, via root or so?)

I don't know the answer, sorry, but if rooting Android‑6 opens the door to a workaround, I suspect we'd have read about it in this forum by now. Some users seem very keen to defy and/or taunt decision-makers (such as Google in this case, and Garmin in terms of which features the company has excluded from particular models by design), and would be actively promoting circumvention of mandated requirements and restrictions if the opportunity arose. :)

My Samsung Galaxy handset and tablet are staying on Android‑5.x; that's my preventative ‘action’ for not allowing a known issue to occur in the first place. (I also have a handset running Windows‑10 Mobile that I could use instead to be my everyday phone and on which to run Garmin Connect Mobile.)

Well, I just bought the OnePlus 3 so, android 6.0 is the one on it :/


But how come, that other applications work perfectly without locations enabled, and if you look at the article given by you (https://forums.garmin.com/showthread.php?344660-Default-Sync-only-works-with-location-services-turned-on&p=813348#post813348 => where there is a link to http://stackoverflow.com/questions/33045581/location-needs-to-be-enabled-for-bluetooth-low-energy-scanning-on-android-6-0 , where they state that there are alternative functions an app-dev can use to scan for BLE without location (permission).. So this is a Garmin issue..

where they state that there are alternative functions an app-dev can use to scan for BLE without location (permission)

Whether that is true or not (I don't know and cannot verify), Google is the one that ‘broke’ the method that is known to work in the existing code. Actually, from my reading of it, the method still works in Android‑6.x, but requires access to Location services (which is not the case in earlier versions of the operating system).

So this is a Garmin issue..

It isn't. You're expecting Garmin to work around Google because that's what you'd like, as opposed to accept that if Google imposes a new requirement, then that's what Garmin Connect Mobile will require using the existing method.

If you can make Google back off and make the existing method work in Android‑6.x without Location services being enabled, then good for you. Why would you expect Garmin or any other company to fight for you, when its apps already work as is, as long as you accept Google's new requirement? It isn't Garmin's requirement, and it isn't Garmin's fight to defy it.

Whether that is true or not (I don't know and cannot verify), Google is the one that ‘broke’ the method that is known to work in the existing code. Actually, from my reading of it, the method still works in Android‑6.x, but requires access to Location services (which is not the case in earlier versions of the operating system).

It isn't. You're expecting Garmin to work around Google because that's what you'd like, as opposed to accept that if Google imposes a new requirement, then that's what Garmin Connect Mobile will require using the existing method.

If you can make Google back off and make the existing method work in Android‑6.x without Location services being enabled, then good for you. Why would you expect Garmin or any other company to fight for you, when its apps already work as is, as long as you accept Google's new requirement? It isn't Garmin's requirement, and it isn't Garmin's fight to defy it.

Actually that's not true. While Google may have changed how Android manages permissions to be more granular (a good thing for users), Garmin's developers have a choice when it comes to leaving the legacy code as-is or adapting it to work better for Garmin's users in the new Google permission model.
By choosing the easy way out and leaving the legacy code in place Garmin has also chosen to decrease customer satisfaction since the combination of the new and improved Google permission model plus the legacy Garmin code makes it harder for Garmin's users to do what they have been doing for quite some time.

Given that 1) this Garmin functionality is a very important part of the value prop for a number of Garmin devices, and 2) Google's Android ecosystem is not something any company would want to alienate themselves from, it would seem that Garmin would be more willing to adapt to the new Android reality so that Garmin users would not see any degradation in their experience (or reduction in value prop) just because the developers (or more accurately, their masters) have chosen to take the easy path with the legacy code.

In short, Garmin blaming an upstream provider for Garmin's choice to not adapt a Garmin product so that users, at a minimum, are no worse off is rarely a good marketing strategy, especially for a market the size of Android's. It sends a message that Garmin is unwilling to insulate their users from their supply value chain and causes users to question whether or not Garmin will continue to support Android in the future (and no company wants that rumor to start circulating). Ask the companies that used to make typewriters. I'm sure they fell back on the defense of "Sure, the PC world has this thing called a word processor, but hey, our product still works, so why should we adapt?" plenty of times, but look how that turned out for them.

If Garmin is unwilling to modify their code to keep up with Android as it evolves and improves, how are we users to know that when the next version of Android comes out Garmin won't just tell users some other painful workaround is the way to deal with it? (step 1: downgrade your phone; step 2: perform bluetooth pairing; step 3: upgrade your phone; step 4: reverse the steps to unpair; See - our code still works so blame Google if you don't like this workaround)

As someone who has worked in IT and software development for many years I would strongly recommend that the Garmin product owner for the Connect Mobile product quickly get a story in the backlog to change how they handle BLE in the context of the new Android permission model and get it to the top of the list for the next sprint. It should not be hard to justify after a quick look at the potential market impact for the number of affected units already sold and number of future unit sales that will be affected by the decreased value prop. And rest assured that if you effectively force users to choose between being loyal to their phone OS vs Garmin, 9 out of 10 will stick with their phone and drop Garmin if push came to shove (data on repeat sales from the mobile device industry supports this).

Garmin: Please do the right thing and fix this.

NB - This is not meant to be a direct attack on anyone, so please don't take it that way. I am merely trying to add some perspective from a pragmatic business point of view.

Don't overlook the fact that Garmin Connect Mobile continues to be demonstrably compatible with Android including Android ‑6 and allows pairing and syncing with Garmin devices over Bluetooth LE. One user preference – which not every Android and/or Garmin device user holds, although for the record I do – can no longer be accommodated by application code that still works correctly when the required permissions and access to Location services are granted by the user. Equally without this being an attack on anyone in particular, an individual's preferences do not set the bar or control the narrative of what constitutes technical compatibility and interoperability.

What I won't stand for are fellow users presuming or pretending they hold the power or dictate how things must be done, especially when they're just jumping up and down and making noise in frustration due the objective fact that they aren't getting what they want while the planet keeps on revolving. I acknowledge their frustration and sentiment, and equally I recognise they (as well as I) can only suck it up and that's how the power dynamic works in the consumer IT world today.

It's Garmin responsibility (and best interest) to ensure continued compatibility with newer versions of popular operating systems, but defending the legitimacy and viability of individual's preferences is not the company's fight to take up. As I've suggested several times already, if particular users aren't happy with the requirement for Location services to be on, why not take it with Google in the first instance, tell the IT giant just how important they are as users and ‘customers’, and jump up and down demanding respect and to be accommodated?

Same issue With Fitbit

I have just come from a fitbit Surge and there are numerous complaints on the forum regarding syncing and having location services on. I unfortunately have just got a new Samsung Galaxy S7 which I am assuming I will have to enable location to sync. Should have stayed with my S5!