Uri.toSafeString strips out paths and shouldn't be used
for situations other than logging.
Bug: 232694281
Test: PtsPowerTestCases
Change-Id: Iec835b738c3e928e922bd6a14573106f2ce4f526
Sliceable.isCopyableSlice() is not set to true for any controller, so this function is not used.
Usage is removed in Change: I81474aed994678c42d73cc59e169573880de1378
Bug: 227722942
Test: robotest & manual
Change-Id: I86e23aa8ad43f60b5017ff0a278e20e3f727706c
- Add an interface to get highlight menu key resource in Sliceable
- Force implementing the new interface in TogglePreferenceController and
CustomSliceable at syntax level
- Update the slice index db schema
Bug: 204695404
Test: manual, robotest build pass, unit
Change-Id: I0b5068bccd04f1590023de7f3385bc0a4c6fa47b
Starting Android S, all PendingIntent should have the mutability flag
assigned to prevent from vulnerability.
Fixes: 172811605
Fixes: 172206649
Test: 1. Play on the slices in Settings search.
2. Make a permission request intent of Settings wifi slice in the
slice-viewer app, clicking on it and make sure it gets redirect to
Settings without crashes.
Change-Id: I86f915bc062a6e632b5ca9c74e232db1036f08de
This change do the 2 things:
1. Add new junit tests files which replace robolectric
RobolectricTestRunner & RuntimeEnvironment with
AndroidX objects without problem.
2. Remove the robolectric test files which have it's new junit files.
This change migrate 103 files, there are still 1209
files to go.
Bug: 174728471
Test: atest
make RunSettingsRoboTests
Change-Id: I15ed3f4745b85862f720aabbf710ce1475aced93
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
Bug: 144134209
Bug: 160489394
Change-Id: I780b9eee35802b19a5f0ab0a7d07bd3e081f5556
Implement a throttle in SliceBackgroundWorker to control slice updates.
Test: robotest
Fixes: 152366832
Change-Id: I8b65d1b57973e036b932172627aca506f4fae3a4
- Reload theme in slice provider when Dark theme mode changes for slices
- Reload theme in onCreate of Panel activity for its non-slice header
- Remove applyTheme from individual slices
Test: robotest
Fixes: 153700819
Change-Id: I40a7d2817c4b9100d7b2f2962a69c8a9ce6f7906
We would like to remove all sub-text from Settings Search. But slice
view does not support API to configure the sub-text visibility.
Therefore, the only way is to remove the sub-text from slices directly.
Since Settings slices are also invoked by other apps, we can not
directly remove the sub-text.
Finally, we decide to check the caller's uid. If it comes from Settings
Search, we will return the slice without the sub-text.
Bug: 143118037
Test: visual, robotests
Change-Id: Iac72f1683a2c930592634e0599058890d86f669d
A malicious app is able to obtain this pending intent.
It can then mutate all fields except for the action and
launch the intent. This can be used to launch any activity
with the ACTION_SETTINGS action.
So, we enfore assign the package name for this intent,
it only can launch the settings app.
Fix: 147355897
Test: a) Install the new settings apk, and it won't launch other screen.
(See details in bug)
b) Start the settings search, slice search results work as normal.
Change-Id: Ie954d8a4b7153d6a4cac40621f363b45185990f2
(cherry picked from commit b3c0a2a6c1)
Merged-In: Ie954d8a4b7153d6a4cac40621f363b45185990f2
Apps get Settings Slices through onGetSliceDescendants(), so adding some
codes here to make us be capable returning non-public Slices. As these
SliceData come from slice_index.db, where SliceDatabaseAccessor is the
middleman for us to access those data, so adding a parameter in
getSliceUris() to determine what data should be returned.
Bug: 141088937
Test: robotests
Change-Id: I411eb1ff194b7c8915b9e7309c684046dbde29fb
To distinguish public and non-public slices, add public_slice column
to the database so we can return corresponding results based on this
value.
Bug: 141088937
Test: robotests
Change-Id: I05d003875a8be27e5cb735b4814eb86d6dc40174
- New SearchIndexableResources interface returns SearchIndexableBundle,
we don't need reflection to get SearchIndexableProvider
Bug: 135053028
Test: robolectric, check database search_index.db items
Change-Id: I5ed3416ccf72ef3d38db817fcb4aff7502649ed4
- Use SettingsLib Indexable
- Directly use resource id in getPreferenceScreenResId
Bug: 135053028
Test: roboletric
Change-Id: I05f493b55e8b6e2091301e9231ba5615215618e6
During SettingsSliceProvider#onGetSliceDescendants, use the uris from
database directly instead of getting the key and construct the uris
manually.
Bug: 126222433
Test: robotest
Change-Id: Iad4e9fc28ec4442b6bb323878503d743582b35ac
And slightly refactored the SliceDataConverter to remove 1 reflection.
Bug: 126222433
Test: robotest
Change-Id: Ic5782bdd71f5c9cb77879a35de81dc61c01d1912
When it is null, we should also update SliceView, so SliceView can
update to be "invisible"
Fixes: 133790296
Test: RunSettingsRoboTests
Change-Id: I239405cce8bcadacbd374ccbb24d0fcbadc04880
Return null when slider getMax() <= getMin(), instead of force
build it to make it crash
Fixes: 132657278
Test: RunSettingsRoboTests
Change-Id: I9f3c078ae07522aa8f1cebdee3f73df2d014d6bb
SettingsSliceProvider no longer allows apps to request permission
from the user for Settings Slices. Instead, the PrimaryAction on the
permission slice will be an intent into Settings.
This is because the dialog for granting apps Settings Slices would act
as a replacement for regular permission dialogs, which we want to avoid.
Fixes: 130795282
Test: robolectrico
Change-Id: I6848215bab2bf10ee5e53814b765d04f04f53f4e
We did not set the min value on slider slices when converting them
from preference to slices, which makes the slices all have min 0.
However, there are some slider which should have min value greater
than 0, for example, call and alarm.
We should get the min value and apply it to slider slice to make it
consistent with what we have in settings pref.
Test: Manual verification
Test: make -j40 RunSettingRobotests
Test: atest VolumeSeekBarPreferenceControllerTest
Fixes: 130439216
Fixes: 130358208
Change-Id: Ib4399c36c7da3ac41a6d46a6c150f0ec1b9b0b0f
- Add boolean useDynamicSliceSummary() in Sliceable interface. This is
the switch equivalent to android:allowDynamicSummaryInSlice in xml. It
moves the setter closer to regular Sliceable APIs, thus less easily to
miss.
- Coverted all android:allowDynamicSummaryInSlice to use the java API.
- Except 2 prefs in my_device_info. They incorrectly set this to true
previously (controller is not sliceable, no point setting
dynamicSliceSummary to true. They just won't do anything)
Fixes: 128446156
Test: robolectric
Change-Id: Ic57acd590dec3e87dcf4592df137321d14b854d9
