Query sitemap will return a list of pairs [parent class name, child
class name]. It's up to consumer to figure out the display name later
so the provider doesn't have dependency on localizing any display names.
- Removed SiteMapManagerTest. We will perform the test in
SettingsIntelligence instead.
- Added test for the new provider in instrumentation test (robolectric
doesn't recognize the new constants in framework yet)
Bug: 67359411
Bug: 64938328
Test: atest
Change-Id: Ia973115320e6b7c8cf84d4756db1763ae7010aed
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 the the indexing check for the
index data's locale to match the locale of
the device. We don't require locale for
indexables, and we reindex on locale change.
It had introduced a bug where when locale
changed, the default us-en results would
not be added to the db.
Change-Id: I43a4284f5c23bc51ee3efdfcabe511eac2d3317d
Fixes: 66916397
Fixes: 68380443
Test: robotests
This is entirely implementation detail, the public
interface and tests get to stay the same.
- The Raw, Resource and Provider methods now return single
or lists of IndexData rather than adding to a member var.
- Some code duplication was removed for Raw IndexData.
- Extra methods were squashed or removed
The only remaining refactoring in IndexDataConverter is
moving work done on IndexProviders to get the raw and
resources into PreIndexDataCollector.
Bug: 33577327
Test: make RunSettingsRoboTests, Database dump before & after
Change-Id: If6011046955f242ba2614400cfeca3bea5b683cb
For the sake of incremental updates, we moved all of the
conversion from PreIndexData to IndexData, and the
insertion of the rows into the SQLite DB into a new class,
IndexDataConverter. However, it's real role is just to
convert PreIndexData into IndexData.
So this CL moves the insertion of the rows back into
DatabaseIndexingManager.
Again, for the sake of simplicity, I did not change the
conversion flow. Rather, instead of inserting a row at the
end of the conversion, I just put it into a list which is
then returned. This lets me move the tests to appropriate
locations, without having to change them too much.
In the tests, the references to real xml layouts are
changed to fake references. Hooray for being less brittle.
IndexDataConverter now just tests that the IndexData
has the appropriate data from PreIndexdData.
Independently, we test that IndexData gets inserted in
DatabaseIndexingManager.
In the next CL, I'll refactor the conversion
flow for readability.
Bug: 33577327
Test: make RunSettingsRoboTests
Test: Took a database dump before and after change,
and they were the same. Cool.
Change-Id: I39cc812d1f736e13a0a51af50984c239961ecf7a
This is a small refactor in the large game of refactoring
DatabeseIndexingManager, and the general indexing pipeline
for Settings search.
This change is centered around hiding the normalization of
data (title, summary, keywords) from the data collector,
and putting that responsibility into the IndexData object.
In a future CL, we may move this again to the controller
that actually indexes the data.
Note, the conversion from PreIndexData to IndexData is
still messy, but until I can write a CL that just
rearranges the code, we must stay patient and vigilant.
Bug: 33577327
Test: make RunSettingsRoboTests
Change-Id: I53543d3d9c74a61380601297c55b6e4fea13031a
Step 2 in refactoring DatabaseIndexingManager.
This step moves the insertion of data into the database
into a new class. This removes the remaining bulk of the
code outside of DIM, but it does not fix the actual issue
with the indexing code.
The indexing code still chains functions together to
insert data into the database at the end of the functions.
It is exceedingly hard to read, and hard to track down bugs.
I would like the converter to eventually return a list of
IndexData objects, which lets us dissociate the database
from the data collection. I.e. we can store the database
in the Search app, and just pass IndexData objects via
IPC.Fixing this requires more of a refactor, and will be
done in a subsquent CL.
Bug: 33577327
Test: make RunSettingsRoboTests
Test: Took a database dump before and after change,
and they were the same. Cool.
Change-Id: Ia9bb815657b76f6cb9163014e746ec5eb6db8c5e
The first step in refactoring the god class,
DatabaseIndexingManager.
The class has one major entry point: indexDatabase
which begins a chain of calls that first collects all the
data from the fragments, and then massages that data into
the SQLite database. Unfortunately, most of the methods
do not return data, and just pass along some mutated
form of the data until it can be insterted.
Reading and testing this class is very difficult.
This first step moves the collection of the indexable data
into a new class which has a few benefits:
- The data can be easily mocked in tests
- Reduces complexity of D.I.M.
- Separates data collection from indexing, which allows the
indexable data to be piped into a new API that unbundled
search can consume.
Bug:33577327
Test: make RunSettingsRoboTests
Test: Grabbed a DB dump before change, compared to DB dump after change
to make sure everything is still indexed.
Change-Id: Ibc91e3d75ff5dcf5274b93b29bf3544f90b2194d
We do this by tracking a list of package/version that provides search
indexing data. When they change, we do a full reindex.
Change-Id: I906a1524f5b1292932f63727d605283ddb7d6ee2
Bug: 63903835
Test: robotests
Adds a public intent action to the index so that intents
can be created for callers outside of settings.
Change-Id: I9f87263f213b6de40542e8735c931ee1f0d82094
Fixes: 63136008
Test: make RunSettingsRoboTests
- Opens the database indexing to be synchronous for the
external settings api.
- Adds logging to track synchronous and async indexing
times.
Bug: 62826872
Test: make RunSettingsRoboTests
Change-Id: I28b69f3952946c0ae5dd7ea7da66f7a5fd485637
InlineSwitchPayload now assumes that all switches will be
stored as 1 or 0, which simplifies the code.
Moves Availability into ResultPayload, so that custom
payloads can be created to set/get values which are more
complicated than stotring ints (like bluetooth or DnD),
and give more expressive reasons when unavailable.
Bug: 62022517
Test: make RunSettingsRoboTests
Change-Id: I87e6fc041bfd398e7daf6e6e479d502930d36f0f
- 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
