Fix the followings:
Recent access apps are not displayed after toggling off/on
"Use location".
When "Use location" is enabled, "Location for work profile" switch is
disable and gray out.
Fix: 227621199
Fix: 227265216
Test: manual
Change-Id: I9f955a381827eb020fbd0d6ebeb9fced3dec1dcf
Keep the queried name is null to use the custom provided battery attribution name (avoid to replace it with POWER_COMPONENT_ prefix name), such that we can show "TPU", "GPU" ... attribution.
old screenshot: https://screenshot.googleplex.com/8KGNxW2eHFY85zw
new screenshot: https://screenshot.googleplex.com/8KVj3jBjShfa8wK
Bug: 227749579
Test: make RunSettingsRoboTests
Change-Id: I22fba3c252a92f7d64670ad5d0f6f3548374968a
For example when changing display states.
Save view states to solve this issue.
- Save current tab. (System / User)
- Save group expanded state. (Personal / Work)
- Save scrolling position of each group.
Also updated to ViewPager2 and updated the styles.
Bug: 204839552
Test: manual
Change-Id: Ibeda50b50e7dfd2ba071b75fe2aa88ef560f4c88
Root cause: Base class provides an override function for accessibility settings shortcut preference. But, it cannot update to the edit dialog.
Solution: Refine the resilience function and base class apply into accessibility settings shortcut preference and edit dailog.
Bug: 228830417
Test: Manual testing on all accessibility page and edit dialog
Change-Id: I84bc63a39cd9cfa7e12944dff20ee6b92879008d
The extra PreferenceCategory is adding some unnecessary padding, so
removing it. Instead of using a preference category to enable/disable
all items, we just iterate through all the preferences when
enabling/disabling items.
Bug: 227139218
Test: locally on device
Change-Id: I403295fbccb7b135b7d603cd1fc713c4c0189569
Setting Active dream to not be clickable to stop Talkback from prompting
user to "Double tap to activate".
Bug: 228573813
Test: Manually tested on device.
Change-Id: I5f646bcf82d8c4172127f0739b6c0d7af890dabb
This notification is an introduction to new notification permission changes in T and is shown to the user upon upgrade; this change records that the user has seen/interacted with the notification already so we don't have to keep showing it.
This change essentially makes a copy of the existing functionality of NotificationAppListActivity, but meant only for access internally (so that neither the activity nor the associated action is exported/publicly accessible).
Bug: 225373531
Test: manual with the change that sends the notification
Change-Id: I20c6084652ea11a8d0a002a21561fe50b9cf5de3
Fix the logic used that determines whether the automatic time
zone detection toggle is available in the Settings UI Date & Time
screen. Also, ensure that the TimeZonePreferenceController uses correct
logic for whether the user can manually enter a time zone.
This change migrates the controllers to use a existing high-level
TimeManager API rather than (incorrectly) duplicating in Settings UI the
logic for whether time zone detection is supported / enabled.
Without this change, WiFi-only devices _with_ location-based time zone
detection enabled would incorrectly hide the "auto time zone" toggle,
which would have the knock-on of making it look like the user is allowed
to enter a time zone manually when they aren't (because it is
enabled/disabled based on the presence of the toggle).
That toggle still needs to be present while there is a possible time
zone detection mechanism. All the (quite complex) logic around this is
already considered by the TimeManager API.
Possible side effects:
This change decouples the "does the toggle show true or false?"
(isEnabled()) from the "should the toggle be shown at all?"
(isAvailable()) logic by removing a call to isAvailable() inside of
isEnabled(). This is to avoid making multiple (probably more expensive
than what it was doing before) calls to the time_zone_detector service,
and avoid the extra complexity of caching / cache invalidation that
would be needed to mitigate it. Previously, as a result of the call to
isAvailable(), isEnabled() would always return false when mIsFromSUW is
true, but now it will return the underlying value of the device's
auto_time_zone setting. This means that if the UI is changed in future
to render a visible-but-can't-be-changed-by-the-user toggle for auto
time zone, it will display the current setting value, which is perfectly
reasonable. It is assumed it will have no other side effects.
The AutoTimeZonePreferenceControllerTest.isFromSUW_notEnable test has
been changed to reflect the change in behavior. Various name changes
made to tests to reflect the new behavior.
Bug: 228247623
Bug: 186625820
Bug: 172891783
Test: treehugger
Test: Manual test on a device with telephony
Test: m ROBOTEST_FILTER=AutoTimeZonePreferenceControllerTest RunSettingsRoboTests -j40
Test: m ROBOTEST_FILTER=TimeZonePreferenceControllerTest RunSettingsRoboTests -j40
Change-Id: I4c7608e8645eee5994c8ecf85a14a27d3278ac04