Settings now collects search results from a single
loader which fetches from an aggregator. This is to
facilitate the separation of search functionalitiy,
where "query" becomes a single synchronous call.
In this case, the aggregator will move to the
unbundled app and would be called on the
other end of the Query call. i.e. the new search
result loader will just call query, and unbundled
search will handle everything else.
An important implication is that the results will
be returned in a ranked order. Thus the ranking and
merging logic has been moved out of the RecyclerView
adapter (which is a good clean-up, anyway).
The SearchResultAggregator starts a Future for each
of the data sources:
- Static Results
- Installed Apps
- Input Devices
- Accessibility Services
We allow up to 500ms to collect the static results,
and then an additional 150ms for each subsequent
loader. In my quick tests, the static results take
about 20-30ms to load. The longest loader is installed
apps which takes roughly 50-60ms seconds (note that
this will be improved with dynamic result caching).
To handle the ranking in DatabaseResultLoader,
we start a Future to collect the dynamic ranking before
we start the SQL queries. When the SQL is done, we
wait the same timeout as before. Then we merge the
results, as before.
For now we have not changed how the Dynamic results
are collected, but eventually they will be a cache
of dynamic results.
Bug: 33577327
Bug: 67360547
Test: robotests
Change-Id: I91fb03f9fd059672a970f48bea21c8d655007fa3
- Remove incorrect summary from set date/time
- Remove some unused resources
- Remove ability to clear individual search history
- Add remove all query history menu item
Change-Id: I4383d075310297163fd2206d1a5b9c8f4ed94078
Fix: 62741488
Fix: 31589605
Test: robotests
Previously everything lived in an inner class method of
SettingsRobolectricTestRunner. That method has now been turned into
a static method so that it can be called by other runners.
Bug: 62460102
Test: robotests
Change-Id: I6612b1f26404587301c534c8ba60e39d59d6c840
- Ranking API is modified to run the ranking asynchronous to the main thread.
Therefore, it can now run in parallel to loading the results from DB
which decreases the overall latency.
- Ranking API now supports reporting failure from the ranker
implementation side.
- Settings that are not ranked by the ranker algorithm are now ranked at
the end of the list. This is added for dynamic settings (e.g., apps).
- Failure handling mechanism is added for cases that ranker catches an
exception or it takes a long time to respond.
Bug: 37312700
Fixes: 36866337
Fixes: 36867476
Fixes: 36866736
Fixes: 36866838
Test: RunSettingsRoboTests
Change-Id: I3a2a97e3a07a8d4afbb090061d92172a27588ee7
This will avoid unnecessary static ranking if smart ranking is used.
Since loader does not need to provided sorted collection of results,
the loading data type has changed from List<> to Set<>. This will also
faster lookup in the Adapter.
Fixes: 38447799
Test: make RunSettingsRoboTests
Change-Id: I448b29bd4e8700c8ec4b5766cbeab4b3087ae39a
- SearchResult stableIds are now DocIds from the database
- DocIds are data reference key's hash, when the key is not
empty or null
- Otherwise, DocIds are a hashcode from a set of fields.
Change-Id: Id36f7bf4ceaaa3a2bd326ecafbfe97fd0b247df2
Fixes: 37327194
Test: make RunSettingsRoboTest
All search results are now refreshed when resuming the
search fragment, to prevent crashes from results that
no longer exist.
Bug: 34817357
Test: make RunSettingsRoboTests
Change-Id: I96a0cbfee711ab9dee49d56bfdc4e885202d9ecd
In order to index Intents into Icing, they need to be
built at Index time rather than at Search time.
Test: make RunSettingsRoboTests
Bug: 36443380
Change-Id: Ia731b5038380bb658232e2e175f52a81d86d7e02
Adds mechanism for adding a button in the search screen
and stubs to show and hide the button.
Fixes: 35164702
Test: make -j40 RunSettingsRoboTests
Change-Id: I34d245e84b62cedf2dc6e5de4ea336c5a99ffd31
