WiFi issue with Google Pixel / Android 9, 10

[atlascoder]

Also, I see that IE Country information is changing from CN to DE. I changed country policy to manual and now Country information is not changing, but Pixel is still not working well.

[atlascoder]

And another one confirmation - if i run ESP AP on the same channel as the target AP of ESP STA mode - Pixel works fine.

[atlascoder]

OK, WiFive, it looks like I can find a workaround for my scenario and Pixel device.

Though, it sounds very surprising that Pixel has defective WiFi driver or chip. Just for sure, could you please check and confirm, that ESP sends Beacons with Channel Switch Announcement in the previous channel - before switching to new one.
Unfortunately, as I did say, Wireshark does not allow me to see actual Beacon channel: it always shows Channel 1.

[WiFive]

Also, I can find several 802.11 Beacon packets from ESP AP which contain Channel Switch Announcement, but it looks like Pixel does not follow channel change by these beacons for some reason.

Sounds like the problem is on pixel side then, esp32 is doing the right things.

[genedyne]

Unfortunately, Pixel does not reconnect to this AP again and choses another network.

I'd suggest you re-run this test, but 'forget' all other networks. This will give android no 'other' option, and will increase the likelihood it will follow the AP when it changes channels.

I work with a system that operates in a similar fashion (Android STA attaching to an embedded AP), and have found the development arc that Android appears to be on values internet connectivity. I suspect your esp32 AP is tagged as 'no valid path to the internet', and is therefore seen as a low quality connection. Each new version of Android appears to be more militant than the previous in valuing internet connectivity over useless dead-end network links.

I agree it seems odd the Android driver would jump to a different connection instead of maintaining an open socket by following the AP through a channel change, but the logic may be that by dropping the link through the existing 'low-quality' network, and jumping to a known 'high-quality' network (i.e., one that provides link to the internet), the socket connection can be re-established. You might expect better from Google - but most of their testing is going to be focussed on the 99.9% of users that demand high-reliability internet connectivity - at any cost. In this conext, if an existing nework link has 'gone bad', seemlessly switching to a 'known good' link might be seen as a feature...

[atlascoder]

Hi, genedyne!

Thank you for the suggestion, but unfortunately this is not acceptable for production FW.

My workaround is simple: after AP switches to another channel, Pixel drops WiFi connection in 10-30 seconds and connects to another WiFi. Fortunately, I can detect that another WiFi is used and then I ask the user to connect to ESP AP again. Then communications become working again and the process can be finished.

Since the Setup process is very rare for users and Pixel takes a little share from all Androids - we see this approach feasible.

If interesting, here is my topic on Google Support https://issuetracker.google.com/issues/121092520, now I created new topic https://issuetracker.google.com/issues/143505082.

I had faced this issue before , but I didn't dig too deep that time I thought that the issue is in TLS implementations. Now I have proof that this is in WiFi MAC/PHY levels. My supposition is that the issue is related to Pixel specific WiFi Hardware/Driver, because I have other Androids working and hardly to imagine different Android cores for every model.

I am still don't know where is the issue: on Android or ESP, but it's absolutely disappointing to find that you can't rely on standard behavior and have to insert clutches.

[genedyne]

Thanks for the link to your android bug - I've tagged it.

My comments weren't intended as any kind of solution - only a test you could run to possibly provide more insight into WHAT is going on. I've found other Android vendors (Samsung especially) all seem to introduce their own bugs/features/behaviour, so it's not a surprise that they behave differently from the Pixel (i.e., 'work' in your scenario).

I've found Google's implementation of Android to be the most reliable/consistent/rational, so it's my go-to when I need a reference standard. Unfortunately, it seems to have failed in your scenario - Google coders are human too!

Best of Luck.