This CL implements prediction of advanced device to
let users know what time their advanced device will
be out of battery.
Bug: 153706138
Test: make -j42 SettingsGoogle
Change-Id: Iadf2f1fa425ff5f0fa1abed681d82d13c392db62
This is a transitional step towards truth 1.0.1, where these APIs have
been completely removed.
Bug: 168765701
Test: m checkbuild
Merged-In: I76f9c37cb699ce6ab8715ffe35d11668ccbceea1
Change-Id: I76f9c37cb699ce6ab8715ffe35d11668ccbceea1
(cherry picked from commit 46e85a2fad)
This reverts commit 732edc3e39.
The kill is already done by StorageManagerService these days.
Bug: 133504844
Test: flip toggle, verify app is still killed.
Change-Id: I1de15108e1e214478c2b67701e95208f280195b6
- Before this CL, the device will be disconnected and reconnected
to accessory mode when choosing "File transfer/Android Auto" in
accessory mode. Because the USB menu didn't check state of
function, it should do nothing when choosing
"File transfer/Android Auto" in accessory mode.
This CL add condition to check state of function, it will do
nothing when choosing "File transfer/Android Auto" in
accessory mode.
Bug: 162451162
Test: make -j42 RunSettingsRoboTests
Change-Id: I1749c6c43d2a192e4ce1bf1ae5343ff8deafbe48
- Move isMediaOutputDisabled() from Utils to LocalMediaManager.
The isMediaOutputDisabled() is used to check whether should
disable the entry point of media output, it's not a general
method for Settings. To reduce the usage of Utils.java,
it's better to let LocalMediaManager handle this method.
- Add test cases.
Bug: 169378895
Test: make -j42 RunSettingsRoboTests
Change-Id: I5dbed2ad4de6dca8105414f8b7d7ce7141e258bd
- Before this CL, users can share their mobile data through enabling
tethering in the USB menu when in a guest account.
It will cause main users to spend their money unexpectedly.
This CL will hide the tethering option on the USB menu when in the
guest account.
- Add test cases.
Bug: 166125765
Test: 1. make -j42 RunSettingsRoboTests. 2. Switch to a guest account
to verify whether the tethering option is hiding.
Change-Id: I7523b3f3c3a1372bb128a58a6a7fac973d27cfbe
Merged-In: I7523b3f3c3a1372bb128a58a6a7fac973d27cfbe
(cherry picked from commit bde627b263)
- Before this CL, users can share their mobile data through enabling
tethering in the USB menu when in a guest account.
It will cause main users to spend their money unexpectedly.
This CL will hide the tethering option on the USB menu when in the
guest account.
- Add test cases.
Bug: 166125765
Test: 1. make -j42 RunSettingsRoboTests. 2. Switch to a guest account
to verify whether the tethering option is hiding.
Change-Id: I7523b3f3c3a1372bb128a58a6a7fac973d27cfbe
* Show edit shortcut dialog should belong to the basic feature, so move
them back to ToggleFeaturePreferenceFragment
* Add test cases for UserShortcutType to prepare to further refactor
Bug: 158540780
Test: atest ToggleFeaturePreferenceFragmentTest
Change-Id: Ia84bea5581f85d199f395b2065652ce69738abbf
It adds a minimum value if it shows only one available
cast device in the output switcher. Because users can only
change the volume slider or stop control in the output switcher.
It's too hidden to have the user stop cast in the UI.
- This CL will disable the entry point of the output switcher
if there is only one available cast device in the list.
- Update test cases.
Bug: 163095048
Test: make -j42 RunSettingsRoboTests
Change-Id: I8906878e1ba769d6940041f17d83b5de6b2a32c0
Merged-In: I8906878e1ba769d6940041f17d83b5de6b2a32c0
(cherry picked from commit b6840ced0d)
It adds a minimum value if it shows only one available
cast device in the output switcher. Because users can only
change the volume slider or stop control in the output switcher.
It's too hidden to have the user stop cast in the UI.
- This CL will disable the entry point of the output switcher
if there is only one available cast device in the list.
- Update test cases.
Bug: 163095048
Test: make -j42 RunSettingsRoboTests
Change-Id: I8906878e1ba769d6940041f17d83b5de6b2a32c0
This is a transitional step towards truth 1.0.1, where these APIs have
been completely removed.
Bug: 168765701
Test: m checkbuild
Change-Id: I76f9c37cb699ce6ab8715ffe35d11668ccbceea1
-To set highest priority when codec modification comes from development setting
Bug: 165442632
Test: make -j42 RunSettingsRoboTests
Change-Id: I8cfbaa276f3b3e269f4a80e8aae987fbb90f646e
- Add extra to these intents to help WallpaperPicker log the launch
source
Bug: 154781896
Test: make SettingsRoboTests
Change-Id: Ifb0ed22ab8ebfbb3c2ad24e9b7bad80007162b6e
When users open volume panel and keep on changing the volume slider for
a while, the panel starts to defer the slider updating, and finally gets
stuck and causes an ANR.
Root cause:
Volume panel has four volume adjusting slices. Each of them registers
a broadcast receiver to listen to the volume changed and muted events.
However, when the media volume changes, AudioManager will send four
broadcasts (music, assistant, accessibility, tts) to every receiver, and
each of them will reload slice four times. Thus, one media volume
changed event will lead to 16 (4*4) UI updates. Consequently, keeping on
sliding the volume bar will trigger hundreds of broadcasts and UI
updates, which makes the system busy and getting stuck.
Solution:
Introduce a VolumeSliceHelper to integrate the broadcasts of the volume
slices specifically.
1. Only register one broadcast receiver to reduce the broadcast loading
since the four slices are listening to the same signal.
2. Filter the only one eligible broadcast among the multiple concurrent
ones, and then relay it to the registered slice.
3. Listen to one more action STREAM_DEVICES_CHANGED_ACTION to update the
volume panel when audio output device changes.
Test: robotest, visual
Fixes: 144134209
Fixes: 160489394
Change-Id: I780b9eee35802b19a5f0ab0a7d07bd3e081f5556
Merged-In: I780b9eee35802b19a5f0ab0a7d07bd3e081f5556
(cherry picked from commit 2c7b77dad7)
Re-launching volume panel continuously will trigger an endless panel
loading, show a transparent unfinished UI, and then block the user's
screen.
Root cause:
When the activity receives a new intent from user's clicking, it will
call PanelFragment#createPanelContent to update the current fragment.
The method triggers an animation and then loads the panel content. If
multiple invocations run concurrently before the animation or the
loading finish, the loader's countdown latch will be increased
abnormally and lead to the endless loading.
Solution:
1. Since the invocations are in UI thread, simply add a flag to avoid
reentrance when the panel is animating or loading.
2. Filter out the same panel's creation request when the panel is still
visible.
3. Do not force a panel's recreation when it's under construction.
Fixes: 143889510
Fixes: 160491854
Test: robotest, manual
Change-Id: I821faedeb62354929f3af9804cbbe44ee5bb8a53
Merged-In: I821faedeb62354929f3af9804cbbe44ee5bb8a53
(cherry picked from commit 6a8d2c5e55)
