In my testing, this reduces the runtime of the Robolectric Settings test
suite on my Z840 workstation from 440 seconds to 402 seconds on average.
By avoiding having a method-level Robolectric shadow import, we avoid
going down a code path which needs to add more shadows later in the
Robolectric execution.
Bug: 64808827
Test: Settings robotests still pass
Change-Id: I7b40d73b30306ae3f9759281afbd7f7266579e24
Bug: 36719359
Test: runtest --path
packages/apps/Settings/tests/unit/src/com/android/settings/wifi/SavedNetworkSettingsTest.java
Test: Open saved networks from WifiSettings. Ensure that exiting and
resuming the activity keeps the "Add Network" button on the bottom of
the network list. This is tested through the cases where networks are
forgotten/saved before resuming, and that pausing/resuming when the dialog
is open or closed does not affect the result.
Change-Id: Ib719a1f6b9468c0f8f44470eeed9144904672cf1
In monkey test, the suggestions list can become null. So, add check
for valid suggestions list before trying to iterate through the
suggestions.
Fixes: 64757618
Test: make RunSettingsRoboTests
Change-Id: Ib670808a4f222187b9cd53d7d939e71b5ce8dbae
BluetoothPairingDialogFragment has code that makes the OK button on the
dialog disabled until the user has entered at least one character into
the PIN field. However it didn't properly handle the case where the user
had entered some text and then rotated the screen - because it always
marked the OK button as disabled during onShow even if it already had
some content. This CL fixes that by looking at the text content and only
disabling the OK button if the content is empty.
Bug: 36514895
Test: make RunSettingsRoboTests
Change-Id: I4e8e70089a862e67b20ff614bbaa64fc2b641fd4
After b/64124535, battery strings in settings page use shortString
version. This cl updates the charging string in this situation to
match the mock.
Note that no matter whether we use shorString, the chargingLabel
should remain the same.
Bug: 64752046
Test: RunSettingsRoboTests
Change-Id: I4395d4660e212688cd560ca0b124acbd9c099cc9
Changes behavior to only render the wifi pie icon if the new rssi has
resulted in a new signal level.
Bug: 64712237
Test: make -j40 ROBOTEST_FILTER=WifiDetailPreferenceControllerTest
RunSettingsRoboTests
Change-Id: I01be2f87d61489242d646ff2003db13c9268ea14
Removes all references to the deprecated NetworkBadging class. Replaces
Badging enums with AccessPoint.Speed. Uses SettingsLib Utils class to
get the WifiIcons.
Note: This change depends on ag/2676505.
Bug: 62355275
Test: make -j40 RunSettingsRoboTests
Change-Id: If3301ce30e22a7b2cc4d534b0a89e6d7ddfef45b
Before this cl, the app list couldn't distinguish different users
because all of them have the same key: USER.
This cl adds userId into key, to make sure the preference key
is unique.
Bug: 64605854
Test: RunSettingsRoboTests
Change-Id: Ia4de2ff85b214465a35f1983ca69a9280d053154
The preference controller shouldn't be shared between the
"Assist Gesture" parent setting, and the child setting within
Fixes: 64318213
Test: manual test of settings && make -j RunSettingsRoboTests
Change-Id: I2d2437e2036881a08977924dc1386aa1fab67070
If device doesn't support MOBILE_DATA, then stop show
"Mobile network standby" in battery advanced page.
Bug: 63252393
Test: RunSettingsRoboTests
Change-Id: Icaf5c0c781c96fa1d4df999c6769c27a84c27446
This implements an explicit toggle to enable/disable automatic 12h/24h
time formatting detection based on the current locale.
Previously automatic detection was the norm on a freshly wiped device,
but could never be re-enabled once either 12h or 24h format was
configured.
Bug: 32761619
Test: m RunSettingsRoboTests
Change-Id: Idbbb8f79fccec95e33bf2f12767d5736e1118fa7
There are two problems with the Bluetooth settings and pairing pages
that are fixed by this CL:
(1) We advertise on the page that the local device is visible to other
devices, but that only lasts for the length of the default timeout (120
seconds) for the local adapter being in discoverable mode.
(2) Both the BluetoothSettings and BluetoothPairingDetail fragments
enter discoverable mode in their onStart handler and exit it in their
onStop handler. Unfortunately when doing a fragment navigation the
onStart and onStop events interleave in a non-intuitive manner. When you
go from BluetoothSettings to BluetoothPairingDetail, we see the onStop
event for BluetoothSettings *after* the onStart event for
BluetoothPairingDetail, and similarly when going back from
BluetoothSettings to BluetoothPairingDetail. What this means in practice
is that if you go to the BluetoothSettings page, the device will be
discoverable, but once you navigate to BluetoothPairingDetail or back
again you won't be discoverable again until you go somewhere else or end
the settings activity.
This CL adds a new object called AlwaysDiscoverable which can be used to
start and stop a mode of "always being discoverable". While started, it
will listen for changes to the discoverable state, and return to
discoverable mode. This fixes (1) by returning to discoverable mode
whenever the normal timeout expires, and (2) similary by returning to
discoverable mode when we accidentally exit it due to the onStop/onStart
mismatch.
A better fix for (2) would be to avoid the "glitch" of briefly exiting
discoverable mode only to re-enter it, but the implementation of that is
a little more complicated so that's being left as future work in order
to keep this CL as small as possible.
Bug: 64130265
Test: make RunSettingsRoboTests
Change-Id: I559dd8187263ea6a0008be1a8abdfffac97cb87a
