Google Fit authorization bugs (with 5005, 5000, and 5015 errors) on WatchFace, WatchConfig, and companion app

Question

I am looking for some fresh ideas on the dreaded 5005 error: \"Status code denotes that an unknown error occurred while trying to obtain an OAuth token.\" when my Watch Face

Answer 1

Here's the result of my testing with the above code. First I went into the Google Accounts page and made sure that my app was revoked from the Connected Apps.

If I start the Mobile app, I will get asked for:

• the Google account to use for Soccer Referee Pro
• Allow the app to View Location and Activity History
• Grant the Read Calendar permission (used elsewhere) and eventually when I want to display a field coverage map:
• Grant Access Fine Location permission

However, in my testing I deliberately didn't go into the Mobile app. Instead when I start the Watch Face: - I get asked to grant the Access Fine Location permission (I fire the Config Activity intent to handle this check/grant)

I then go into the Watch Config to set the period length and turn on my Fitness collection flags. The Watch Config never asks for any permissions and succeeds silently with the READ_WRITE permissions.

When I finish my data collection on the watch face, I get the following output:

? D/RefWatchFace:: Listener registered for data Type com.google.speed
? D/RefWatchFace:: Listener registered for data Type com.google.location.sample
? D/RefWatchFace:: Detected -1 Activity datapoints; inserting 10 (including created ones)
? D/RefWatchFace::  inserting final 10 activity segments (including created ones)
? D/RefWatchFace:: Detected 10 Speed datapoints; inserting in 1 batches
? D/RefWatchFace::  inserting final 10 Speed points (including created ones)
? D/RefWatchFace:: Detected 16 Location datapoints; inserting in 1 batches
? D/RefWatchFace::  inserting final 16 Location points (including created ones)
? D/RefWatchFace:: Checking inserted fitness data for com.google.activity.segment in this batch time 1468440718000-1468441013000
? D/RefWatchFace:: Successfully inserted Session Wed, Jul 13; 1:11PM: Period 1
? D/RefWatchFace:: Checking inserted fitness data for com.google.speed in this batch time 1468440716000-1468440734000
? D/RefWatchFace:: Checking inserted fitness data for com.google.location.sample in this batch time 1468440709575-1468440750000
? D/RefWatchFace:: After insert; read-back found 9 data points for data type com.google.activity.segment
? D/RefWatchFace:: After insert; read-back found 10 data points for data type com.google.speed
? D/RefWatchFace:: After insert; read-back found 16 data points for data type com.google.location.sample

In other words, at no point was I asked to grant WRITE permissions, but it wrote anyway.

In my second test, I removed the WRITE permissions in the Watch Config app, and reran the Watch Face. Now all the inserts return a 5005 (Unknown Error) status code, but the Location data is actually inserted (not the Speed or Activity data).

In my third test, I move the WRITE permissions to the Watch Face Google Api code. In this case, the .connect fails immediately with a 5005 error.

Conclusion: It seems to me there is at least one security hole here, as well as inconsistent behavior and completely unhelpful errors on the Wear side.

Answer 2

I finally got an answer from Google on how useDefaultAccount works behind the scenes and this affects which Fit account is being written/read above. Here's the question I posed:

I really need an answer on the following question which has been messing my testing up for months. I am using the Fitness Apis from my Wear watch face. I use "useDefaultAccount" in the Google client builder. But which account is the default in this case? - the account used to download the app (in which case what account is used when you install the app from your dev machine) - it's null/unset - it's the account you pick your companion app when you connect. - it's the current account selected in Google Fit - you can't use useDefaultAccount in Wear faces/apps

And the answer from Google (thanks Gustavo Moura): Here's how I understand the logic (it's not very well documented and we intend to clean it up in the near future): 1. if there's a companion app and the user has signed into Fit and picked an account there, we'll sync that account to the Wear device and use it. 2. if there's no companion app (or the user hasn't signed into it), but the user has Google Fit installed and enabled, and has selected an account with Fit, we'll sync that account to the Wear device and use it. 3. if there's no companion app and no Google Fit, but the Wear device has another built-in app that has similar behavior (like Moto Body on Motorola watches), we'll use the account from that app. 4. if none of the above is true, there are still some APIs that will work even without an account (like step counter recording and querying). This is special in that any data accessed in this mode will be data local to the watch only and it will never be synced to any other devices or servers.