Adds unit test for DeviceInfoUtils.formatKernelVersion to see if it can
parse a /proc/version string from a kernel compiled with Clang/LLVM.
Bug: 32455817
Change-Id: I25123bf44f67e038e01d8c76d6eab18d5616c7c2
This revises the previous attempt to drop taps when another window is
obscuring the device admin details. Any system alert windows or toasts
are disabled when the activity is in focus, otherwise the button is
disabled so no floating activities can obscure it and delegate taps back
to the security sensitive "Activate" button.
Bug: 35056974
Change-Id: I292a44e713ea4a4b0305ca3b3b21f1c82fd73c2b
Merged-In: I292a44e713ea4a4b0305ca3b3b21f1c82fd73c2b
This revises the previous attempt to drop taps when another window is
obscuring the device admin details. Any system alert windows or toasts
are disabled when the activity is in focus, otherwise the button is
disabled so no floating activities can obscure it and delegate taps back
to the security sensitive "Activate" button.
Bug: 35056974
Change-Id: I292a44e713ea4a4b0305ca3b3b21f1c82fd73c2b
Merged-In: I292a44e713ea4a4b0305ca3b3b21f1c82fd73c2b
This revises the previous attempt to drop taps when another window is
obscuring the device admin details. Any system alert windows or toasts
are disabled when the activity is in focus, otherwise the button is
disabled so no floating activities can obscure it and delegate taps back
to the security sensitive "Activate" button.
Test: CtsVerifier -> Device Administration -> Device Admin Tapjacking Test
Bug: 35056974
Change-Id: I292a44e713ea4a4b0305ca3b3b21f1c82fd73c2b
Merged-In: I292a44e713ea4a4b0305ca3b3b21f1c82fd73c2b
This revises the previous attempt to drop taps when another window is
obscuring the device admin details. Any system alert windows or toasts
are disabled when the activity is in focus, otherwise the button is
disabled so no floating activities can obscure it and delegate taps back
to the security sensitive "Activate" button.
Test: CtsVerifier -> Device Administration -> Device Admin Tapjacking Test
Bug: 35056974
Change-Id: I292a44e713ea4a4b0305ca3b3b21f1c82fd73c2b
Merged-In: I292a44e713ea4a4b0305ca3b3b21f1c82fd73c2b
When the media stream is set, initialize the preference max and progress
with the streams current value. Otherwise, when we initialize the seekbar
volumizer, it will first set the seekbar max to 0 and progress to 0,
then update with the correct value, which will result in the jank that
is seen when the sound settings are displayed.
Change-Id: I515c97bbc6ec38bbe92755e3d7cb53bb13ac52d0
Fix: 34035654
Test: make RunSettingsRoboTests
(cherry picked from commit b7490bea28)
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
