Show Wifi MAC Randomization preference in both "Add network" and "Join
Network" flows.
Bug: 1227787
Test: RunSettingsRoboTests
Change-Id: Iff422eb870e661ceda5ae04f55de802a91f08aeb
Since EAP has many sub type, which controls differnet view. We still need to check the
visibility to determine which type it is.
Bug: 116767176
Test: RunSettingsRoboTests
Change-Id: Iee04a50140ae1afacdf77eedf7743a465bae1f58
After we switch secutiry from EAP to WPA, add button will become
disabled forever. Main reason is that we use view visibility to decide
which security type it is. In this case target view is visible while its
parent view is gone. So even though UI shows correctly however we still
think it is in EAP mode.
This CL check the mAccessPointSecurity directly instead of depending on
fragile view.
Fixes: 114689178
Test: RunSettingsRoboTests
Change-Id: I4284d25e6bf86ee7c5e7c0e17f0834c719d8d587
This means that in some cases RestrictedLockUtils has to be used and in
some RestrictedLockUtilsInternal.
This causes a lot of trivial code changes.
I also updated the ordering of the imports in all affected files.
Bug: 110953302
Test: Built
make -j RunSettingsRoboTests
Change-Id: I9bdf8b89134f853bae4f38c81af436715c73e924
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
Modify the WifiSliceCode to follow the pattern for
Slices that do not match existing UI components.
Test: robotests
Bug: 80263568
Change-Id: Id69e019608777282f4b64ff945e8c30c97aaf577
WifiDialog.java can be launched as "full screen mode"
in some use cases. However the way it's done is that
it uses theme to fake the full screen appearance.
It just feels hacky to use a dialog for full screen UI.
So, we created an "AddNetworkFragment" to make this
page can look like a normal fragment.
Also, clean up some useless code about "full screen mode"
of WifiDialog.
Change-Id: Iedd04c6a8e403cbceb872313314e1cba0d514246
Fixes: 111875856
Test: robo test, manual test
When user launches "Set up Wi-Fi NFC tag" dialog
and then tries to rotate screen, device will
crash.
Because isShowing() of dialog won't return true
anymore when fragment calls onSaveIntance(),
we can't save status of dialog successfully.
And then, when fragment called onCreateDialog()
again, it can't get any dialog object.
So, we only check dialog whether is null or not.
If dialog is null, it means that there is no dialog
was shown before user rotates the screen.
Fixes: 112741721
Test: NFC tag wifi test, robo test
Change-Id: Idb448ea32c4215d8380c69bfd896cc91d8c1f8d1
When user clicks a Wi-Fi access point in WifiSettings,
screen pops up a Wi-Fi point dialog. And then user
rotates the screen, Wi-Fi access dialog changes to
"Add network" full screen dialog.
In old code, we check whether dialog is showing by
dialog.isShowing() in onSaveInstanceState.
For now, this design is not appropriate. Since isShowing()
won't return true anymore when fragment calls onSaveInstanceState.
So, we check dialog object whether is null or not now.
If dialog is null, it means that there is no dialog was shown,
before user rotates the screen.
Change-Id: I7dc26369c005f576fe679abc70327f6a02620935
Fixes: 112624846
Test: manual test, robo test
Remove MenuItem.SHOW_AS_ACTION_IF_ROOM flag for menu items
to avoid showing truncated texts on action bar.
Bug: 112671955
Test: Manual
Change-Id: I1c9678321442169bc86d719e820d4af68261dee1
WifiDialog was created by WifiDialogActivity.
If activity was destroyed suddenly, WifiDialog can't dismiss itself.
So, we need to dismiss dialog, when activity was destroyed.
Test: robo and manual test
Bug: 111841375
Change-Id: I8aaf1c78e72144bf7c9cbc2392bce30e715d86e9
Since Theme_Settings_NoActionBar extends from Theme.DeviceDefault.Settings,
so it carshed when AppCompatDelegateImpl tried to get AppCompat theme from WifiDialog.
Test: visual inspection, robo
Change-Id: I751b771fdfa9ad2261baa5a06274f6bb0a70d677
Fixes: 111804691
- Apply footerPreferenceStyle to reduce the text size and text color
- Add "info" icon
Bug: 80087791
Test: visual, RunSettingsRoboTests
ROBOTEST_FILTER=com.android.settings.wifi
Change-Id: I19d4f67c5a9f2fc2b542f40e051c1469ab40e7db
This CL only changed AlertDialog imports.
So, reviewer can review it easily.
Change-Id: I097bc44394195b14287f4f920c570ac8653f356a
Fixes: 111413092
Test: This CL can't pass Robo test.
In WiFi calling settings, although each WifiCallingSettingsForSub
instance has its mSubId, the mPhoneStateListener always listens to
state of default subId, which is incorrect. This is to fix that.
Bug: 109787945
Test: In DSDS device, open WFC settings. Make phone call using default
voice phone, and check that WFC setting tab of the other phone is
not greyed out.
Change-Id: I126047c6099bf156b40e0145aa55df0fdf8ef882
This patch focused on fixing compile errors and some runtime errors.
Test: We can't test it now. But we will have an integration test later.
Bug: 110259478
Change-Id: I16c471ddcd0fa1460c665b7f74d86fcace5ee67b
In the WifiTetherApBandController the incorrect method was
being called to check if the device is 5Ghz compatible. We
were calling is5GhzBandSupported directly, but we were
supposed to call isDualBandSupported instead.
Test: robotests updated
Bug: 110793581
Change-Id: I61d3ff10abedde6196b8e29591ebfd3272dbbcd9
Index is already handled by SettingsIntelligenec. No longer needed in
Settings.
Change-Id: Id43fb3100dc2759185744441cff8cb9cd2d2da20
Fixes: 69808376
Test: robotests
Display "Unavailable" instead of "02:00:00:00:00:00" when the current
MAC address is "02:00:00:00:00:00" which indicates that we couldn't get
the actual device MAC address.
Bug: 110043449
Test: unittest (make RunSettingsRoboTests
ROBOTEST_FILTER=WifiInfoPreferenceControllerTest)
Change-Id: Iac9f81d144fd4c93ac12adaa80e1a55b19a6e186
If Wifi is not enabled at boot, WIFI_STATE_CHANGED_ACTION
sticky intent is not present. This results in Wifi 'Off'
status is not shown. This patch handles such case by calling
notifyChangeIfNeeded at register to refresh status.
Bug: 110373099
Test: manual - Check status after device boot with wifi off
Change-Id: I009386b03ef3269b00ce403b86087664b295f397
We decided to use the list preference after all due to
some devices not supporting various combinations of AP
configurations. This change makes it so that there are
three different UIs depending on the configurations
which are supported.
- 5.0 GHz unsupported: disable the preference and just
set the value to 2.4 GHz
- all supported, no dual mode: allow the user to choose
EITHER 2.4 GHz or 5.0 GHz
- all supported, dual mode: allow the user to choose
2.4 GHz or BOTH 2.4 GHz & 5.0 GHz with 5.0 being
preferred
Test: atest SettingsRoboTests
Bug: 80315296
Change-Id: I888d35811a98b8cf0155a3cb96c42ff762763378
Merged-In: I888d35811a98b8cf0155a3cb96c42ff762763378
We decided to use the list preference after all due to
some devices not supporting various combinations of AP
configurations. This change makes it so that there are
three different UIs depending on the configurations
which are supported.
- 5.0 GHz unsupported: disable the preference and just
set the value to 2.4 GHz
- all supported, no dual mode: allow the user to choose
EITHER 2.4 GHz or 5.0 GHz
- all supported, dual mode: allow the user to choose
2.4 GHz or BOTH 2.4 GHz & 5.0 GHz with 5.0 being
preferred
Test: atest SettingsRoboTests
Bug: 80315296
Change-Id: I888d35811a98b8cf0155a3cb96c42ff762763378
