- toolbar default has touchscreenBlocksFocus enabled which make toolbar not focusable when touch screen present. Explicitly set touchscreenBlocksFocus to false make the toolbar can be focus when keyboard navigation.
- Remove focusableInTouchMode which breaks normal touch control. Read https://android-developers.googleblog.com/2008/12/touch-mode.html for more details.
Fix: 327025582
Fix: 324420544
Test: manual test with keyboard and touch navigation
Change-Id: I6cad869e3a51926405a6f3ae894daa5416050bf8
getLaunchedFromPackage() reports who launched this Activity or built
PendingIntent used to launch it, whereas getCallingActivity() reports
who will get result of Activity.
Bug: 316891059
Test: robotest, manual
Change-Id: If97018c2741caef622f0596bbfeaa42ef1788b78
This reverts commit 19d1d3d15d.
Reason for revert: revert it because this is not the root cause.
bug: 316867690
Change-Id: I0f168dbb64044aa720202af7b1040afd4f028c9c
This reverts commit cf0501e4d7.
Reason for revert: b/317462033, it seems a flaky but revert it first.
Change-Id: Ie1d5e279cca6477fc17d8c27c1ecda8d7a6b2553
Prior to this cl, if user opens settings app
in single-pane first and navigates to
the search page, then rotate the device,
user observed the search page was still shown
with full screen.
Because we didn't register correct split rule,
it causes the abormal behavior on two-pane mode.
In order to register correct rule, we also need
to assign correct component name while opening the
search page.
Fix: 206896763
Test: Rebuilt apk and verify the behavior
Change-Id: I7343467aa716d71da63f2ad0a034dc6c1b7fd415
1. Add a receiver to monitor the search state
2. Shoe/hide the menu highlight in the listener
3. Highlight the menu entry in SearchResultTrampoline
4. Enable/disable the receiver in SettingsInitialize
Bug: 205781792
Test: manual, robotest
Change-Id: Ia04901f504172f4f0c7b4b2ea7eda5f3713f676d
- Support fragment and direct link in SearchResultTrampoline
- Start activity for SI case and start deep link trampoline for others
- Disable menu highlight whenever the search bar is clicked
- Don't overwrite SettingsApplication's homepage activity in
SliceDeepLinkHomepageActivity
- Scroll to highlighted menu entry after homepage is loaded to prevent
UI overlapping
Bug: 201724410
Test: manual, robotest build pass
Change-Id: I5115d17d829e85036000da2e80f0e5b0598c733f
The Activity launched by android.settings.APP_SEARCH_SETTINGS
does not setResult. So it's no meaning to use
startActivityForResult for the Intent.
Bug: 196923591
Test: manual
Settings -> Search settings -> search an item ->
click back button twice and back to Settings home.
Change-Id: Ia760a301465bb87814326611a1ec2368887f120a
- Search bar in homepage.
- Avatar icon in homepage.
- More personal safety in Safety & emergency.
Test: Rebuilt rom
Fix: 190341976
Change-Id: I14297211e4b7424f5fdeb46c360b3913101251d7
Enable the transition between Settings app and Settings Search
Test: Record the transition video and confirm it.
Fix: 175764903
Change-Id: I95125fba17bbf517feee9a10fd828ff8017f7106
- Search box is hidden if user set intent extra isSetupFlow true
Fixes: 135717823
Test: search box is hidden in the following command
adb shell am start -a android.settings.SETTINGS --ez isSetupFlow true
Change-Id: Ia3d955c9390d6b0eef9391b9b35b6a483eb63d26
We start a search page with a request code which is same as
"uninstall" request code. The root cause is we handle same
reuqest code for different event.
We redefine an unique request code for "search" feature.
Fixes: 124775813
Test: Click search and back to App info screen.
Change-Id: I8ab21c30b605bcb65b6d4bd9fceb749a65a49f80
mIsShowingDashboard is always false, it used to be true when we are
displaying homepage, but now homepage is hosted in a entirely different
activity.
so all related logic can now be removed.
Test: robotests
Misc clean up: remove unused colors
Test: rebuild, color-lint
Change-Id: I1e1628c1e9606c2b7dc40ef3c21d4ed1391a8c03
- When user disable settings suggestion in App Settings, click
search button without leaving settings app. The search button is
still existed.
- Doesn't allow user to disable app in App Settings
- Add check before start search intent
Change-Id: Ifbc4615914678d8df734e14d63bb626403313d1e
Fixes: 118805907
Test: manual
- Settings Suggestion App is responsible for searching, we can not
prevent user disable it. Hide search feature if user disable it.
Fixes: 118805907
Fixes: 117921464
Test: manual
Change-Id: I61c47c52265a6efd79ef2fa60272bf6513e678b1
- Remove search fab from layout xml
- Change RelativeLayout to CoordinatorLayout so we can use prebuilt
scrolling behavior
- Minor update to theme so search bar background works in dark mode for
the homepage activity.
Change-Id: If7408c12684be65137e04ae3bb4137204c2d77e0
Fixes: 117508596
Test: robotests, visual
- Add BottomNavigationView which has two tabs
- Remove BottomSheet in layout files
Change-Id: I493290fa9dee0566c73c5c9d7fbba10b71b4e2b4
Fixes: 113266753
Test: visual
When requestCode is 0, we will not finish activity.
Change-Id: Ib630951739031b05c83efe189875a4a41c8e51ec
Fixes: 113372155
Test: make RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.password"
Index is already handled by SettingsIntelligenec. No longer needed in
Settings.
Change-Id: Id43fb3100dc2759185744441cff8cb9cd2d2da20
Fixes: 69808376
Test: robotests
This moves SearchIndexableResources to be supplied by FeatureFactory
rather than its own singleton, which in effect allows OEMs to supply their
own, in the case where they have their own classes they want to be
indexed (or, remove certain classes that used to be indexed).
Bug: 72179744
Test: All tests pass.
Change-Id: Ia06b2026df7eca4c53b44a5a589c4aaa0b69d96c
Connect the SliceIndexing data to the SliceProvider,
such that a query to SliceProvider can build a Slice
via the indexed data from SlicesIndexingManager.
We take the key from the Uri supplied to the SettingSliceProvider
and find a potential matching row in the indexed data. The
matched data is then used to Build a slice for the caller.
Bug: 67996923
Test: robotests
Change-Id: If51bfd1a05c3f3817ae720554f95a98fc7b002e1
Also moved all other flags in a common file so we can track them more
easily.
Bug: 68825426
Bug: 64938328
Test: rerun robotests
Change-Id: I3fc805054cb960bedd965b1b907be759df50b95d
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
Convert input device search into a search query loader
And remove old logic from DynamicIndexableContentMonitor
Change-Id: If652b1ea7c8add9185bbd025055e14925d3a8eec
Bug: 64310452
Bug: 63831980
Test: robotests
This is necessary to kill DynamicContentMonitor later
- Removed all logic related to indexing accesiblitysetting from the
monitor class and AccessibilitySetting page itself
- Created a loader to search against A11yServices at runtime
I noticed adding a loader in SearchResultsAdapter is rather manual. It's
something we should consider refactor in the future.
Bug: 64310452
Test: robotests
Change-Id: Iff31aff65ce000991229433f294e2ec69af99da2
- This allows the ranking implementations to prepare for predictions and
avoids latency on the first prediction call.
Bug: 38197948
Bug: 37312700
Test: RunSettingsRoboTests
Change-Id: I1878b14765ad7cede5648fa1c7f29c419c2e5535
- 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
No longer used given that we don't show the search icon on any page.
The main settings page now has the search bar.
Change-Id: I9535028298739467e7fa9c75d1a2fb2b2fa3251b
Fixes: 62230804
Bug: 37477506
Test: robotests
- 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
