It should use msg.obj to detect whether to start listening, not
msg.arg1.
Bug: 70607303
Test: Build
Change-Id: I55c4d988f0ebb35f4be9039055eba7803c0b082f
When the dashboard summary is being initialized, it will rebuild the UI
while the summary loader tries to to go through the tiles to update the
summary. Both is being done on a separate backgroud thread, and it will
run into concurrent modification issue if the thread is being swapped
while one is looping through the list.
Instead of letting clients access the list of tiles directly, add a
getter method in DashboardCategory to get a copy of the list of tiles
for all read-only operations.
Change-Id: I479669abd8d1d0a8ee9a4113d8ad2244da56f4d8
Fixes: 69677575
Test: make RunSettingsRoboTests
- Move view initialization from onViewCreated to onCreateView. This
doesn't really improve anything, it simply aligns the code more
with view's lifecycle management.
- Move dashboard category init into background. The init contains logic
invoking packageManager, which can be very expensive.
- Remove any call to DashboardFeatureProvider from SummaryLoader, and
delay the getCategory call until someone calls setListener().
- call updateCategory() from background thread.
Test: rerun app launch test. Avg latency drops back to pre-suggestion-v2
level.
Test: robotest
Fixes: 68761512
Change-Id: I5ec85af08e7b610786e439bda93b3651f5975593
- In SettingsActivity, do not call updateCategories() if nothing
changed.
- In SummaryLoader, create a mapping between tile key and summary. This
is necessary to handle a race condition where category is refreshed
after summary load.
- In DashboardSummary, refresh Tile's summary to latest cache value
everytime category is refreshed.
Change-Id: I61389b8ba614ba7e34939325bada6e1bd6fa6709
Fix: 63149109
Test: robotests
- remove DashboardFeatureProvider.isEnabled() and all relating code
and tests.
Bug: 35764802
Test: make RunSettingsRoboTests
Change-Id: If7796677abc8904b7436525836d50cdef38e37a4
- Added a activity-alias pointing to displaySettings as top level
setting item.
- Refactored all preference logic in DisplaySettings into
PreferenceControllers. During fragment onAttach it installs all
controllers, and during onResume it updates preference state. Each
controller listens to its own preference change event.
Bug: 31800242
Test: RunSettingsRoboTests
Change-Id: Ibc9bf200c5acce7c4ae9292340822afee27a3a28
- Make a SummaryConsumer interface. Things that needs latest summary
should implement this interface (DashboardAdapter for homepage,
DashboardFragment for subsettings). This also decouples SummaryLoader
from relying on SettingsDrawerActivity.
- Make DashboardFeatureProvider more generic to load DashboardCategory
by key.
Bug: 31781480
Test: RunSettingsRoboTests
Change-Id: I9c65456fb433a74c352498251e0ccf65da0be1f0
Merged refreshAllPreferences into DashboardFragment. This hopefully
makes it more modular to manage preference display logic in each
dashboardFragment, and makes it more efficient to monitor category
changes.
Now subclasses needs to implement 2 methods:
- displayResourceTiles(): for 'static' preferences from xml
- getDashboardTiles(): returns a list of dashboard tiles and superclass
will wire it up to preference screen.
If getDashboardTiles() return null (aka no dashboardCategory available),
the fragment will not attempt to monitor category change. The edge case
is that if a package starts to provide a tile for this category, we will
not be notified. I have not seen this case coming up. If we indeed need
to handle this case, the category listener needs to have a way to
monitor specific category rather than globally.
Bug: 31781480
Test: make RunSettingsRoboTests -j40
Change-Id: Ia9f9541b95816214df0d0bb27e3e41078c36c5ca
Adding support to homepage category.
Test: SettingsRoboTests for regression. Will write tests for new feature
soon once we are set on the data structure.
Bug: 31781480
Change-Id: I25fa367fecb643f17e23f0182df7585bf1fcdd02
Bug: 30490325
SummaryLoader needs DashboardCategory to update summary and it currently
ask for it from DashboardAdapter. But DashboardCategory is not always
available in DashboardAdapter. When SummaryLoader wants to get category
from adapter before adapter is ready, it won't have it, causing summary
to appear blank sometimes.
The fix is to get category from data source directly.
Change-Id: I9d7f676954d1cece42d6e03748ab7aa35357f8b7
Once more and probably not for all
Don't let multiple listening state changes get queued, this can cause
rapid changes like listening->not listening->listening. Also store
listening state on the worker thread now that we drop some state
messages and only notify summaries when there is a state change.
Change-Id: I93a5f364e9b35929f9088e044ebefd9be69740e6
Fixes: 28319383
When in doubt, post to main thread.
Also clean up the listening state just in case there were any
doubts about it.
Change-Id: I9ab85781f38b0f694dc46ed5a953506ef10c5778
Fixes: 28319383 (Fingers crossed)
Previous CL accidentally cleared the listening bit too early making
it never actually tell the SummaryProviders to stop listening.
Change-Id: I6af1acc861f6987b33641c40637354c75cf4d708
Fixes: 28306872
The background thread is not stopping listening fast enough and is
resulting in first a receiver leak message followed by a crash when
trying to finally unregister the receiver.
Fix this by adding a registerReceiver to SummaryLoader that will
automatically unregister the receiver on the main thread to ensure
it happens in time.
Change-Id: I0104e929d5505eb53993f6765e4c90120df35cf6
Fixes: 28211606
- Cut down on amount stored in conditions xml
- Remove extra work from dashboard startup
- Move summary to min priority
Change-Id: I51ca3828e4446632d6faa60dcfbab3446d19d335
Fixes: 28134360
Mostly hypothetical fix for weird circumstance where listening
lifecycle gets broken. To fix this, track the current state
of listening in the SummaryLoader and force it into the non-listening
state when released.
Bug: 26027137
Bug: 26731143
Change-Id: I7299749230924eafa3e6e7d5b0de6e48ff014a38
Otherwise the receivers don't get unregistered, which causes a warning,
immediately followed by them actually getting unregistered, which
causes a crash.
Bug: 26027137
Change-Id: Ib55edb4490de960d10036c35d98b8a8e31e13ae1
Use an XML to define the categories that Settings will look for,
and surface enabled activities under those categories as suggestions.
When clicked on the activity will be started for result. If the result
is not cancelled, then the operation is assumed successful and the
suggestion is disabled. Users can also use an overflow -> remove
flow to get rid of unwanted suggestions.
Change-Id: I767abf8efe103af0509bc6b6b55888ae82643512
