Logging in and syncing on watch takes a long time

[mchowning]

Description

There are three issues I'm seeing:

1. When logging in using a Google account on debug builds, the watch app takes a very long time to get the token from Google (I've seen this take 4 minutes on a debug build). I originally thought this was a general issue, but it now looks like it is just an issue on debug builds, which makes it not such a big deal.
2. Performing all of our API calls to download the account data after we get the Google account can easily take 1-2 minutes (not surprisingly, it seems to take longer with larger accounts).
3. Once the login and refresh is complete and the logging in screen is dismissed, I am still seeing it take ~20 seconds for the Now Playing chip to appear on both debug and release builds. In other words, the main watch list screen is shown, and the account has an episode that is currently being played, but the now playing chip doesn't show until about 20 seconds later.

Some things I've noticed:

• This is only really an issue on physical devices, emulators are much, much faster, to the point where it is not a noticeable issue on emulators
• If you log out and log back into the same account, the second log in goes much more quickly, to the point where it is not a noticeable issue.
• Release builds are faster debug builds (seem to take roughly half as long to log in), but I still see release builds taking at least a minute to log in

Step-by-step reproduction instructions

1. Do a fresh install of the app on a physical wear os device
2. Log in using a google account
3. Observe that that it takes multiple minutes to get to the main watch list screen.

Screenshots or screen recording

No response

Did you search for existing bug reports?

• I have searched for existing bug reports.

Device, Operating system, and Pocket Casts app version

Pixel watch running Wear OS 3, 7.40 pre-release PC build

[mchowning]

Google token slowness appears to only really be an issue on debug builds

In my testing on debug builds, I am seeing it taking anywhere from 1 minute to 4 minutes, just to get the token from Google and start making our API calls to login/refresh. In release builds, however, this seems to be around 20 seconds or so. Not great, but nothing like the crazy times I was seeing on debug builds.

Another way of looking at this, on debug builds, I saw login with a Google account taking from 2m30s to 6 minutes. If I logged in to the same account with email/password, however the times were between 1 and 2 minutes.

Something weird must be going on here, but I haven't dug into it since we're short on time and it seems like it may only be an issue with debug builds.

Release builds still take >1 minute to log in

Testing email/password login on release builds, I see times of between 1 and 2 minutes (roughly the same as on the debug builds), even when my watch is connected to fast wifi. It would be really good to get this time down. If we can't get this time down, perhaps we need to update the text on the logging in screen to give some indication about how it can take a long time (i.e., "Please be patient" or "This may take a while'). A set of funny, rotating messages might be even better.

I have done some testing with the network-awareness library from this PR, and I have not noticed any significant difference on the login time.

[mchowning]

This is closely related to #1006

[mchowning]

On a fresh install, if I log into one account that login takes a long time (1-2 minutes), but if I log out of that account and then log into a different account, the second login takes around 10 seconds. This makes me wonder if the baseline profile might do a lot to address this.

[mchowning]

It is possible for a user to dismiss the logging in dialog currently. I wanted to allow that just to avoid any risk of the user getting stuck on that dialog since the logic around showing/dismissing it is kind of tricky. If a user does dismiss it early though, the app performs very sluggishly (because it is still syncing in the background), and until the sync is complete the user will have missing podcasts/episodes/etc, so it's certainly not an ideal solution. I just wanted to mention that here since the slow login times probably increase the chances that a user will dismiss the "logging in" screen.