1. Use AndroidJunit4 instead of RobolectricTestRunner
2. Use ApplicationProvider instead of RuntimeEnvironment to get context
3. Change Copy Right
4. To get the original value and add @After to restore the data
Bug:
Test: atest -c CdmaListPreferenceTest
atest -c CdmaSubscriptionPreferenceControllerTest
atest -c CdmaSystemSelectPreferenceControllerTest
Change-Id: I110727b643a6755ee888708bd1fb2a39cf524a2d
Before this CL, the same request code will cause intent to
be cached. It will cause the output switcher to display the
previous media session.
This CL uses the package name as an unique request code to
fix this issue.
Bug: 169077753
Test: make -j42 RunSettingsRoboTests
Change-Id: Iebfc7904609e243d5bf0222307bae98a952a3331
Merged-In: Iebfc7904609e243d5bf0222307bae98a952a3331
(cherry picked from commit c3fe8d87d6)
1. Use AndroidJunit4 instead of RobolectricTestRunner
2. Use ApplicationProvider instead of RuntimeEnvironment to get context
3. Change Copy Right
4. Remove the PreferenceViewHolder that not used in test
5. Remove the ProxySubscriptionManager that can get the real object by
context
Bug: 168767478
Test: atest -c CellDataPreferenceTest
Change-Id: I1fa5747c8c6d224d6b13f1a693ff88e57fd150d3
- Add extra to these intents to help WallpaperPicker log the launch
source
Bug: 154781896
Test: make SettingsRoboTests
Change-Id: Ifb0ed22ab8ebfbb3c2ad24e9b7bad80007162b6e
The updated preference key made slice auto conversion mechanism fail,
so when this slice is requested by external apps, the UI won't be shown
properly. So we need to revert the key to the original one.
Bug: 131897855
Test: manual test
1. Open Settings app -> Settings search -> search battery saver
2. Observe battery saver result item has a toggle
Change-Id: Ifb5b0a6786d60d1e67567272610cc3cb078f11a4
Merged-In: Ifb5b0a6786d60d1e67567272610cc3cb078f11a4
Before this CL, the same request code will cause intent to
be cached. It will cause the output switcher to display the
previous media session.
This CL uses the package name as an unique request code to
fix this issue.
Bug: 169077753
Test: make -j42 RunSettingsRoboTests
Change-Id: Iebfc7904609e243d5bf0222307bae98a952a3331
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)
