According to patch of A-231987122, AOSP restricts app to modify relevant
mobile settings when user is a guest. This change intends to prevent the
slices related to mobile settings from being requested by guest user.
Bug: 278616139
Bug: 277333776
Bug: 262244832
Bug: 278616520
Bug: 278615120
Test: robotests
Change-Id: I4dc4bbfdb5cf76e188e6f62ebfd74ef6fa2fe33b
in the cache.
loadSlice just fills Slice read from the DB into a
map, if there is already such slice in the map, we
could skip the async load process.
Change-Id: I6e96ef72a9dc5a833ae158492134f4a6c94a7465
Bug: 249101421
Test: robotest
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
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
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
Postpone setTheme to decrease memory usage of Settings for the test
android.platform.test.scenario.sleep.Idle
Bug: 156631776
Test: forrest test
Change-Id: I4178eae0832e15c9d6da4a0f1f2898f5c797d388
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
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
The notification package was getting too big.
Test: make -j64 RunSettingsRoboTests
Fixes: 145224451
Change-Id: I25ba82f42f7a137d8adcce72dcf8089d0e018bdc
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
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
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
- Introduce a static long in SliceFeatureProvider that updates once
every "session". A session is when user is in an UI (screen rotation,
going to subpage, etc does not break the continuation of session).
- Use session token in ContextualWifiSlice to determine when to refresh,
instead of relying on WeakHashMap from CustomSliceManager.
WeakHashMap can be cleaned up at any time by gc so it doesn't match
what we want on the UI.
- Also as a side fix, merged CustomSliceManager into
SliceFeatureProvider.
Fixes: 123937830
Test: robo
Change-Id: I199bceceb208b99a32f3f08e624787b5a03e73a9
- Make everything that can be static, static.
- Also removed a unused slice for battery info.
Next step - going to make CustomSliceManager into a regular class
instead of getting it from FeatureProvider. This way it's no longer an
application level singleton, then we can do things like attaching
lifecycle to it. It will be easier to deal with "session" based use case
after the refactor
Bug: 123937830
Test: manual
Change-Id: I384761a6894fa907f72a3610437835c4dd4d1944
The NFC Slice would jank on enable and disable, because of the
intent filter it registered with SysUI. The intent filter would
broadcast an update for four states:
1) On
2) Off
3) Turning On
4) Turning off
The first two caused no problems. The third and fourth caused jank,
since when clicked, the switch in the NFC slice would turn on / off
asynchronously - that is, it turned on or off based on the previous
state of the switch, rather than on the actual value of NFC. It does
this to feel fluid in the app in which it is rendered.
From the off state, the order of events is:
1. Switch clicked
2. Switch animates on
2. Background intent is fired to settings to turn on Nfc (happens at
the same time as animation)
3. Settings calls the NFC enable API
4. A broadcast for Turning On is sent
5. The receiver in SysUI gets the broadcast and forwards it to settings
6. Settings tells the Slice to make sure it is up to date
7. The Slice checks for the current value - IMPORTANTLY - which is
currently off, it is only in the process of being enabled.
8. The Slice flips back off
9. Nfc finishes getting enabled in the background
10. The framework pushes the NFC ON broadcast
11. SysUI gets the broadcast, and forwards it to settings
12. Settings tells the slice to update
13. The slice checks again and finds that NFC is on, flipping on.
This CL creates a new background slice worker for NFC and registers
the intent filter there, rather than in SysUI. When the background
worker gets the broadcast, it checks if it is in state 3/4, and if so,
it drops the update silently.
Fixes: 115737701
Test: robotests
Change-Id: I17043828ad3a67a2a5acdf5c75d9cc51ff7e91d0
And remove unused methods from SliceDeepLinkSpringBoard.
This is part 1 of b/110156445
Bug: 110156445
Test: atest
Change-Id: Iab36a97332fd847ed911a9e34b505fd4a64522d3
Build the special case mobile data slice for general use,
and for the Internet Connectivity Panel. The Slice controls
the default data subscription, and links to the subscriptions
page.
Bug: 117804089
Fixse: 119411534
Test: robotests & test app.
Change-Id: I31b524a8fe3182a244d940848090e97250632f39
Establish the Activity which hosts Settings panels through the
PanelFragment. The Activity's purpose is to validate the intent
data coming in, including:
- Called with startActivityForResult (so we can log who is calling)
- Intent has the proper intent extra to link to a Panel
The fragment takes the Panelable data and builds a Settings Panel.
Each panel will have:
- Title
- List of Slices
- Link to underlying content
The Panelable interface is created to provide all of those datums, and
the new FetureProvider provides the Panelables by linking them with
keys. The keys will eventually become public APIs with CTS tests.For
now, we store them locally.
I included an exmaple panel, the InternetConnectivityPanel which
currently shows Wifi and Airplane mode.
Screenshot: https://screenshot.googleplex.com/c6sv7ZzQ5OJ
Bug: 117804089
Test: make -j40 RunSettingsRobotest
Test: Manual app
Change-Id: I1932f7179cc32088acd6413a736901ddf9651892
- Create workers via reflection in SliceBackgroundWorker
- Store the workers in a static container and release then at shutdown()
Fixes: 118228009
Test: robolectric
Change-Id: I564277d3a12b2d7d3b50cef091bdfedb3397c145
It's because WifiTracker's initialization and onStop is on different
thread. Fine tune the thread logic in SliceBackgroundWorker.
Fixes: 118165942
Test: manual
Change-Id: Icc86b5df7ec3c6fd0e4a79a62ea0c84465e9528d
- Generated a simple EmergencyInfo slice with fixed string in title and summary.
- Moved hardcode string into strings.xml
- Modified the contentProviderCall_returnCorrectSize test case for general version
Bug: 114793520
Test: compile and manual test
Change-Id: Ia3444c61b0f7e4c04794fe3590dc0731885cf062
Also move it under package network, so all of them belong to
com.android.settings.network.telephony.
Bug: 114749736
Test: RunSettingsRoboTests
Change-Id: I35dbdcd5cc9dab939b0a3efccc8897b9a92338d1
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
Modify the WifiSliceCode to follow the pattern for
Slices that do not match existing UI components.
Test: robotests
Bug: 80263568
Change-Id: Id69e019608777282f4b64ff945e8c30c97aaf577
Explicitly set the Settings SliceBroadcastReceiver to
be non-exported and remove the intent-filter.
Add a second provider: SliceRelayReceiver to receive
broadcasts from SysUI to alert Settings to potential
changes to bound Settings Slices. The new receiver is
exported, but only notifies changes to Settings, and
doesn't make any changes itself.
Change-Id: I80d070f7636614135ebe4f57a16f12a3eb6dee81
Fixes: 111330641
Test: boot, robolectric, Slicebrowser
This CL only changed AlertDialog imports.
So, reviewer can review it easily.
Change-Id: I097bc44394195b14287f4f920c570ac8653f356a
Fixes: 111413092
Test: This CL can't pass Robo test.
Create a handler for any slice that doesn't include anything
from a PreferenceController.
Test: robotests
Change-Id: If23947152d61877537d0cac6240e96b9ab977bce
Bug: 80263568
