Sameer: Can you please try out CrOS 68.0.3421.0 to see if you can reproduce this issue still?

I landed e602d3a83ceaaa2d8e66e8282fc78fb7f9474df6 last Friday, which I expect to improve your first issue (~10 second lag). For issue (2), I expect this to be an EasyUnlock bug that would not be fixed by my patch.

Will do as soon as it's pushed out.

For what it's worth, I tested the build and both latency and stability are way better after Kyle's fix.  I'm seeing 3-5 seconds latency now (down from around 13s before).

Report back when you get a chance, Sameer.

From a quick experiment on an Eve yesterday, I did see an improvement in the unlock time (2-3 seconds).  However out of around 10 attempts I did see one attempt where the time was till long (~10 seconds) and one where it didn't work.

The device is at my home and I didn't get a chance to collect logs.  Will try to get them tonight.

Do we still want both the Phone & Chromebook side logs or just the Chromebook side?

Were you locking and unlocking back-to-back?  Or were these 10 attempts relatively far apart?

Unlock -> wait a few seconds -> suspend (either via lid close or shift+search+L) -> resume.

Great, thanks for the clarification.  There is a known issue which stems from the fact that Magic Tether starts a communication channel over BT immediately after every device unlock, then if you lock the screen fast enough (usually on the order of seconds, but it depends on how many devices the user has), Smart Lock and Magic Tether will stomp on each other's communications over the same channel.

That issue will be fixed with Kyle's SecureChannel implementation, which will allow multiplexed communication over the same underlying channel (IIUC).  That's slated for M69.  Given the relative rarity of the described issue and the fact that a natural fix is coming soon, we probably won't prioritize a band-aid fix in the meantime.

Let me know if that all sounds good to you and we can probably close this issue out.

Sounds good.  Will reopen if I observe this issue again in normal usage where the screen has stayed unlocked for of the order of minutes.

Before we close this bug, should we revisit the second issue in Sameer's original report?

"2. why does the phone not found message get displayed just before the lock icon turns green?"

This seems like it's a UI bug in EasyUnlock.

I don't know about Sameer, but I haven't experienced that since your fix landed.

I am not 100% sure but I might've seen #2 in the long delay unlock case. Let me monitor this for couple of days to be sure.