The switch should be on if the default state is on. Also, make sure the
revert button is accessible if the default value is on.
Bug: 240726265
Test: Toggle the switch and then Revert to Defaults with the default value as on
Change-Id: I07d1713316281b0590fab7f1581e15d9f5e57969
Draw the first and the last labels. Then recursively draws axis labels between the start index and the end index. If the inner number can be exactly divided into 2 parts, check and draw the middle index label and then recursively draw the 2 parts. Otherwise, divide into 3 parts. Check and draw the middle two labels and then recursively draw the 3 parts. If there are any overlaps, skip drawing and go back to the uplevel of the recursion.
screenshots: https://drive.google.com/drive/folders/11AJ4Fz6xS76LGlbAy9WfvjZpffgFkMji?resourcekey=0-HBWCQa1oQW4e0UfvLzEXGQ&usp=sharing
Bug: 242009481
Fix: 242009481
Test: manual
Change-Id: Iaa9019feba7693638d5ae64bbbee7298eb74f749
- Because the wifiConfiguration is only save the carrier ID for EAP-SIM authentication
- If multiple SIMs have the same carrier ID, the Wi-Fi framework will use the default data SIM for EAP-SIM authentication
- Show default data SIM in Wi-Fi details settings, when dual SIMs have the same carrier ID
Bug: 233765468
Test: manual test
make RunSettingsRoboTests ROBOTEST_FILTER=WifiDetailPreferenceController2Test
Change-Id: I350fe637f506134770ccf316e47c0e225661bb6a
Merged-In: I350fe637f506134770ccf316e47c0e225661bb6a
Root cause: When the default captioning color was selected, the opacity became 100% and made the opacity preference is disabled. After changing to non-default color, the opacity preference becomes enabled, but it keeps showing cached opacity in opacity preference and the preview still shows the wrong color.
Solution: Cache the latest opacity if default captioning color was selected to show the correct opacity later.
Bug: 241308551
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.accessibility
Change-Id: I7712fb25d622da62d7fb2d017e33f94ef258941b
Prior to this cl, we use #getPackagesForUid()
to get a list of calling package names and
pick up 1st package name in the list as target
calling package. And then go to check the
Wi-Fi permission.
This implementation is ok for most apps without
sharing system uid. However, this may not work
if the package is set with sharing system ui.
In this case, we get a list of packages
and we don't know which one is caller. So, if we
decide to choose the 1st package as our
calling package, then it could fail to pass
permission check since that package could be not
a correct calling package.
In this cl, we skip permission check for those
packages running with system uid. So, it can resolve
Wi-Fi Panel problem since Wi-Fi panel runs
on settings process(with system uid).
Test: 1. adb shell am start -a android.settings.panel.action.WIFI
2. Verify on assistant app and system ui launcher and search app.
Bug: 240531998
Change-Id: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
Merged-In: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
init NotificationBackend in constructor and set isSliceable to false in
search result since the NAS enabling logic is required and is in the
parent fragment ConfigureNotificationSettings.
Bug: 237251075
Test: test manually on device
Change-Id: I9082d6eda27784cf378a0d06304b5fc1e2ae6d7f
(cherry picked from commit 26ce9a98f0)
Prior to this cl, we use #getPackagesForUid()
to get a list of calling package names and
pick up 1st package name in the list as target
calling package. And then go to check the
Wi-Fi permission.
This implementation is ok for most apps without
sharing system uid. However, this may not work
if the package is set with sharing system ui.
In this case, we get a list of packages
and we don't know which one is caller. So, if we
decide to choose the 1st package as our
calling package, then it could fail to pass
permission check since that package could be not
a correct calling package.
In this cl, we skip permission check for those
packages running with system uid. So, it can resolve
Wi-Fi Panel problem since Wi-Fi panel runs
on settings process(with system uid).
Test: 1. adb shell am start -a android.settings.panel.action.WIFI
2. Verify on assistant app and system ui launcher and search app.
Bug: 240531998
Change-Id: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
Merged-In: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
The ArrayEquals, ArrayHashCode, ArrayToString, and
ArraysAsListPrimitiveArray errorprone findings were
demoted from errors to warnings. Fix existing
occurrences of them so they can be made errors again.
Bug: 242630963
Test: RUN_ERROR_PRONE=true m javac-check
Change-Id: Ida6513002f8fd845a385924be290b720f06c4748
- Because the wifiConfiguration is only save the carrier ID for EAP-SIM authentication
- If multiple SIMs have the same carrier ID, the Wi-Fi framework will use the default data SIM for EAP-SIM authentication
- Show default data SIM in Wi-Fi details settings, when dual SIMs have the same carrier ID
Bug: 233765468
Test: manual test
make RunSettingsRoboTests ROBOTEST_FILTER=WifiDetailPreferenceController2Test
Change-Id: I350fe637f506134770ccf316e47c0e225661bb6a
Merged-In: I350fe637f506134770ccf316e47c0e225661bb6a
(cherry picked from commit 2732be59e5)
- Because the wifiConfiguration save the carrier ID only for EAP-SIM authentication
- If multiple SIMs have the same carrier ID, the Wi-Fi framework will use the default data SIM for EAP-SIM authentication
- To avoid user confusion, show one SIM only when dual SIMs have the same carrier ID
Bug: 233765468
Test: manual test
make RunSettingsRoboTests ROBOTEST_FILTER=WifiConfigController2Test
Change-Id: I56f956d20053d314f082ba185d661d8e0a0ef3cb
Merged-In: I56f956d20053d314f082ba185d661d8e0a0ef3cb
Root cause: the visibility of link button is not correctly set due to
the onPageSelected callback isn't called when the first page shows
Solution: Manually set the visibility of link button according to the
first tutirial page type when dialog is shown
Bug: 242141428
Test: make RunSettingsRoboTests ROBOTEST_FILTER=AccessibilityGestureNavigationTutorialTest
Change-Id: I33ed07bc7ae39d96baeeed85771c5f13e00ebf44
When DISALLOW_APPS_CONTROL restriction is enabled, users should not be
able to enable/disable apps, clear app caches and clear app data.
The function of reset app preferences will re-enable the disabled apps,
it can let users bypass DISALLOW_APPS_CONTROL to enable an app disabled
by IT admin to see sensitive information.
To fix this vulnerability, we add a check for DISALLOW_APPS_CONTROL
restriction before users reset app preferences. Once the restriction is
enabled, it will show dialog “Blocked by your IT admin” instead.
Bug: 238745070
Test: Verify change by turning on/off DISALLOW_APPS_CONTROL with TestDPC.
Change-Id: Iffee73cf4952b686a78b4c7aaa54747971337d03
(cherry picked from commit 4356c9c653)
