By marking the Intent that's being sent to WPP as "launched from
settings", the code in CustomizationPickerActivity can correctly
conclude that the multi-pane wrapper does not need to be applied to the
intent, preventing the odd "disordering" of the back stack in the bug.
Fix: 284809020
Test: manually verified, on a large screen device with a multi-pane
settings configuration, that going to Display > Lock screen > Shortcuts
and then swiping back off the left edge of the display correctly exits
settings instead of revealing an incorrect screen like it did in the
bug.
Test: also manually verified that the long-press on the home screena and
on the lock screen paths both open the right tab in WPP in settings
correctly.
Change-Id: Iac2b4e9fa5bab91b6a5251f1c51b4d21a0824f00
**Root cause**
The test was failing because it was not grabbing the boolean resource
from the values-mc999 folder. I'm not sure what changed in Robolectric
that causes it not able to find the resources based on the
qualifiers.
Bug: 279082331
Test: atest TopLevelAccessibilityPreferenceControllerTest
Change-Id: Ie738d1ada1a87b48f34efb7e0477c691c4d44d1e
metric category
**Root Cause**
The test was written when the metric category is set to 0. After we
update the metric category to FLASH_NOTIFICATION_SETTINGS in the
FlashNotificationsPrefereenceFragment, we forgot to update the test.
Bug: 279082331
Test: atest FlashNotificationsPreferenceFragmentTest
Change-Id: Icd709bd9e571ca264226d0ca860e5c482eae3927
performAccessibilityAction
**Root cause**
When constructing an AccessibilityAction, robolectric's
ShadowAccessibilityAction uses reflection to get the private static
final variable `ACTION_TYPE_MASK` to check if the passed action is a
valid action.
However, since ag/I744b3a94fe3c3cc3b559758a95ab0b5b181155bb we renamed
the internal variable, hence robolectric is not able to find the
ACTION_TYPE_MASK variable when using reflection.
By passing the action id directly when calling
performAccessibilityAction, we don't need to use
ShadowAccessibilityAction anymore.
Bug: 279082331
Test: atest AccessibilityQuickSettingsTooltipWindowTest
Change-Id: Ie956de44c9b19a2d19470ad670866d77ca272b3b
**Root cause**
Robolectric doesn't like to launch a spy'ed fragment. You will get an
error like java.lang.IllegalStateException: Can't access ViewModels from detached fragment
Since the test itself doesn't require launch a fragment, I removed the
setup part and renamed the test.
Bug: 279082331
Test: atest ToggleFeaturePreferenceFragmentTest
Change-Id: Iafc431fd8c9cf7812ea99164e5e85683f3e0c121
**Root cause**
We expected the spy resources will be used when calling
context.getResources(). However, we didn't set up the connection. Hence
the test failed due to trying to use the original resources.
Bug: 279082331
Test: atest AccessibilityButtonFragmentTest
Change-Id: Ib6e51b2b2607bec7980b9288a0a8076e4a036863
**Root cause**
When adding a feature flag on showing different hearing aid page on
click, the tests were not executed because they were marked as @Ignore.
In order to execute the test, we need to turn the feature flag off, so that the test run in the same scenario where the feature flag was not introduced.
Bug: 279082331
Test: atest AccessibilityHearingAidPreferenceControllerTest
Change-Id: If11ac40a7ea3926578992f7c0577e7cbb1bb3273
- Prevent mocking ToggleScreenMagnificationPreferenceFragment for test
- Use Robolectric's way to launch the fragment so that the fragment
contains necessary setup
**Root cause**
- We called onCreateView directly in the test without the necessary setup
in onCreate, which causes the FooterPreferenceController not being
initialized.
- We created a spyContext that returns a mock PackageManager, however,
in the test execution, we didn't mock the context used by the fragment
under test. Hence, the fragment didn't use the mock PackageManager in
test.
Bug: 284209879
Test: atest ToggleScreenMagnificationPreferenceFragmentTest --iterations
5
Change-Id: I7e71a03177526f5bb0c20a58855a7dfdffc2a22f
- Do not show Wi-Fi hotspots in Settings Widgets if the config is not set to show
Bug: 275268676
Test: Manual test
atest -c CreateShortcutPreferenceControllerTest
Change-Id: I5d86a78c9d48c9b63faff50d46f1254dbefd94cf
Many robotests that touches BluetoothAdapter might need to use our own
ShadowBluetoothAdapter which implements a "fake" getSupportedProfiles
call, so that the test won't trying to execute the android framework's getSupportedProfiles method.
Bug: 285235777
Test: atest AccessibilitySettingsTest
Change-Id: I5b3b2f4528a2b32aff22928653c57576981c0ff9
