1. Wakeup alarm detector
Because we cannot distinguish it between foreground and background
2. Bluetooth unoptimized scanning detector
There is a bug in framework that may undercount the scanning time
Bug: 63390581
Bug: 63964363
Test: RunSettingsRoboTests
Change-Id: Ia762f580462823e8eddccbeb12dec3876b0ef47a
- when creating the dashboard data, pass the sublist of suggestions to
cap the total number of suggestions to be shown to 5.
- if user swipe away the suggestion, it will only remove the suggestion
from the suggestion adapater, and will not trigger rebuilding the whole
UI.
Change-Id: I3bbc08bb67c411ff5671a837efa40da0ac885983
Merged-In: I1efabeb2a805c670007c631d3ccb0fdfbde7b55a
Fix: 64072051
Test: make RunSettingsRoboTests
Some utility methods in UsbBackend were needed elsewhere so this CL
increases their visibility slightly rather than copying the code.
Test: Robotests still pass
Bug: 62271803
Change-Id: If8ac5494e306ac7f4f6d8eeef75f516308c78026
Check for valid activity when trying to access the action bar as the
activity can become null when in monkey test.
Change-Id: I684d873b9eabb9d8461e99bb4385d411a48c0c52
Fix: 64084651
Test: make RunSettingsRoboTests
- when creating the dashboard data, pass the sublist of suggestions to
cap the total number of suggestions to be shown to 5.
- if user swipe away the suggestion, it will only remove the suggestion
from the suggestion adapater, and will not trigger rebuilding the whole
UI.
Bug: 64072051
Change-Id: I1efabeb2a805c670007c631d3ccb0fdfbde7b55a
Fix: 63309218
Test: make RunSettingsRoboTests
- This is not a functional change and it only updates the model weights
which affects the ranking of suggestion items. The previous weights were
tuned to force the ranking to have immediate response to signal changes.
But, the current weights are tuned to maximize the user interactions
with suggestion.
Test: RunSettingsRoboTests & also manually testing suggestions
Bug: 64093782
Change-Id: I9f50ed6c4ed22d1a14110ec61156c14ba74aef64
Due to substantial risk in landing the "retain profiles" flow that
would otherwise occur if the user elected not to wipe eSIM profiles
during a factory reset, we no longer expose this option to users
through the UI. Instead, we show affected users messaging indicating
that their eSIM will be wiped unconditionally.
The underlying plumbing is retained to keep the change small and to
make it easier to revert back to a checkbox when the rest of the
platform supports it.
Change-Id: Ida7df14d81ffc4cb6b4b414928d3ce7e5c78594b
Fixes: 64081853
Test: TreeHugger
Fixes an issue where other instances of WifiDialog were being launched
fullscreen. Creates static methods for creating fullscreen and modal
WifiDialogs to make the style more explicit.
Bug: 63889135
Test: make -j40 RunSettingsRoboTests
Change-Id: I2200b5d7f817b9f69a6abb73bf2c04ea24556d19
If we only toggle the app type in battery settings, don't update
the header. Then it won't have flicker in battery header.
Bug: 64065456
Test: RunSettingsRoboTest
Change-Id: If1cfa745f723f808ad9c5fd921be797acd3199ba
- Upon configuration changes during the last leg of enrollment,
a check is required to see if maximum progress has been reached.
If so, the next intent has to be launched.
bug: 36656476
Test: Manually tested and verified.
Change-Id: Ie4ec75cb775f83536ad0127011aabcc87c6c5ae0
Should exit the summary handling if sensor is not available.
Change-Id: I5918fa5ac614db48fc2c41e1de555d1ba6928bd4
Fix: 64039312
Test: make RunSettingsRoboTests
When we're failing to connect to a wifi access point due to an incorrect
password, we want to allow an intent from a notification to open up the
wifi settings page and bring up the dialog for entering a different
password. We already have code in settings to do this for not-yet-saved
access points, so this CL just changes it slightly to also allow it for
saved access points.
Unfortunately WifiSettings can't be tested with Robolectric due to it
not supporting PreferenceScreen, so this adds a test to
WifiSettingsUiTest. There were some existing test failures in that file
which I've fixed while I was in there:
-The TestAccessPointBuilder class wasn't being found at runtime because
it was getting stripped out at build time due to not being used in
settings.
-The changingSecurityStateOnApShouldNotCauseMultipleListItems test was
asserting that we don't end up with multiple entries for the same SSID
in the access point list when changing the security state for the AP,
but it was accidentally passing multiple AP's with the same name the
first time.
Bug: 33245941
Test: runtest --path WifiSettingsUiTest.java
Change-Id: I16c9c8b0d8380a0e26f9b23df6a8d012af6a2476
Merged-In: I929ca6892242059df157c01d6e9ea30e8d1c5e78
