ActiveModeWarden: SAP recovery restart
Changes in the wifi stack to restart tethered SAP on recovery:
ActiveModeWarden should be abstracted away from device specific
iface combinations (this info is stored in HalDeviceManager). This
however means that there is no way for ActiveModeManager to figure out
if the device supports STA + AP concurrency or not (This is important
because even when SAP is turned on in legacy devices, wifi toggle state
is internally stored as "enabled". This would cause ActiveModeWarden to
try and recreate both STA & AP mode managers which based on the order it
is created will cause the first one to be destroyed). So, instead take
a snapshot of the active mode managers before the recovery and try to
recreate them (for legacy devices, this will always be == 1, for newer
devices, this could be <= 2). This helps to avoid using device
specific iface combination info in ActiveModeWarden.
Note: While recovery is in progress, the UI toggles are off. If the user
turns on wifi/sap while the recovery is in progress, the recovery is
aborted (This CL preserves existing behaviour).
Bug: 167660545
Test: Manual tests (New Pixels with STA + AP support)
a) Turn on SAP
b) Tun on wifi
c) Crash hostapd
d) Ensure that both SAP & wifi are back on after recovery.
Test: Manual tests (Legacy Pixels without STA + AP support)
a) Tun on wifi
b) Turn on SAP
c) Crash hostapd
d) Ensure that SAP is back on after recovery.
Test: atest com.android.server.wifi
Change-Id: Iaccbbf6515e770847d99bdb0c6947dfb0db853d1
9 files changed