use by SearchDialog. SearchDialog wants to be able to say a dropdown should
not always be visible but still let it ignore outside touch when it does
show.
Fixes http://b/1997170
Sometimes when searching, some of the suggestions had no left padding.
The left-hand side icons were flush with the left edge of the screen.
The problems was that setting a StateListDrawable as a background
will always set the padding of a View, because of a problem in
DrawableContainer.
DrawableContainer.DrawableContainerState.getConstantPadding()
will always return a Rect if mVariablePadding is false, which
makes DrawableContainer.getPadding() return true, which
causes View to change the padding.
As a workaround, we use setVariablePadding(true) on the background
that we create.
Fixes http://b/editIssue?id=1984813
the search manager at that point.
Still works:
- hitting search when a managed dialog of an app is showing will dismiss
the dialog and start in-app search (if it supports it), falling back
on global search
- hitting search when a dialog of an app (not managed by the activity) will
dismiss the dialog and start global search
- hitting search when a system dialog is showing will just dismiss the dialog.
Now that the search manager service handles hiding (not dismissing) and reshowing it
when the user hits back after launching a result, search manager can't cache
"mShowing". Also noticed a few other minor problems that was hosing the handling
of pause / resume to reshow the dialog, like moving some logic to onHide instead
of onDismiss.
Before, Drawables for cached icons were reused. This is not good,
since they can then share mutable state information. This change
copies all Drawables when getting them from the cache, storing
only the constant state in the cache.
Hopefully fixes http://b/issue?id=1984813
IME again when the user presses right or left from a query-jammed
suggestion to continue editing. Previously we required the user
to press on the text field again in order to get the IME to show.
We accomplish this by factoring out the code to 'ensureImeVisible'
into a separate method and calling that from SearchDialog.
Fixes http://b/1976338
HTML parsing of search suggestions is still a major
CPU hog in the search dialog. This change first
checks if the text contains any HTML markup
(by looking for < and &) before bothering to
treat it as HTML.
Before, SuggestionsAdapter parsed every HTML formatted
string three times, to support state-dependent colors
in <font> tags. Now that there is support in Html
for color resources (added in
https://android-git.corp.google.com/g/7441),
we can get rid of this code.
Also, SuggestionsAdapter had a special purpose view
for drawing background colors when suggestion items
were not selected or pressed. This change replaces that
code with a StateListDrawable of ColorDrawables.
Before this change, HTML parsing used ~17% (uncontrolled benchmark,
just did some random searching) of the system_process CPU.
This change should reduce that by 2/3, i.e. about ~11% total
system_process reduction.
This change adds checking that the searchdialog is initialized
properly to a few key event listeners where it was missing
before.
Also makes sure that the search dialog is not shown if the
global search is requested but the global search provider
cannot be found.
Should fix http://b/issue?id=1982128
"Device rebooting after search results"
where SearchDialog.onKeyDown() threw an NPE
call the hidden showSoftInputUnchecked method to show the IME in SearchDialog#show(),
override onWindowFocusChanged in our subclass of AutoCompleteTextView so that whenever
it gets focus, we call the public showSoftInput method, passing in the ACTV, which is
the correct way to do this.
This fixes http://b/1930989.
This adds a new API with the activity manager to find out about movement between
activities. For my sanity, the old IActivityWatcher is now renamed to
IActivityController, and the new activity movement interface is named
IActivityWatcher.
This changes the search manager itself to use the new API to manage its state.
Note that there are still problems when going back to the search dialog after
it was hidden -- the suggestions window no longer appears until you explicitly
dismiss and re-show it.
New left-hand side icon fallback logic in search dialog:
1. If the search dialog gets no icon column, it shows no
icon (like before). This would handle the case of in-app
search where the provider does not include icons.
2. If the icon column is empty, or there is an error converting
the icon id or URI to a drawable, the search dialog identifies
the suggestion source by looking at the
SUGGEST_COLUMN_INTENT_COMPONENT_NAME.
3. If SUGGEST_COLUMN_INTENT_COMPONENT_NAME is empty or not set,
the current searchable activity is considered the suggestion source.
4. Try to get the activity icon of the suggestion source.
5. Fall back to the application icon of the suggestion source
if there is no activity icon.
6. Fall back to some generic icon if there is no application icon.
Fixes http://b/issue?id=1905757
android.app.SearchManager implements
DialogInterface.OnDismissListener and DialogInterface.OnCancelListener
and thus exposes the methods onCancel(DialogInterface dialog) and
onDismiss(DialogInterface dialog). This was used by the SearchManager
to register itself as a listener on the search dialog, but is no
longer used.
This was an implementation detail that leaked into the public
API. Removing them would change the API, so they are deprecated instead.
Fixes http://b/issue?id=1962203
Restore runs during the SetupWizard, before the phone is usable per se, so we
want to avoid presenting the usual "Application whatever has crashed..." dialog
to the user in the middle of that process. This change modifies the exception
handling around agent bringup so that agent-originated exceptions are caught and
a null agent binder reported to the backup manager.
There are three points during this code sequence at which an exception can be
thrown due to application-code error:
+ the app's manifest can name a nonexistent or malformed BackupAgent class,
incurring a VM-level exception like ClassNotFound or BadCast.
- the agent's onCreate() method could crash/throw.
- the agent's onBind() method could crash/throw.
The new code arrangement here puts a try/catch around all of these possible
failure points. When the code is invoked for backup, any caught exception is
merely rethrown. During restore, however, execution is allowed to proceed
through reporting the app's agent binder back to the activity manager. If any
exception was thrown, this reported binder will be null, i.e. a clean failure
notification to the backup manager.
What this code does *not* do at present is tear down the app when an exception
has been thrown. This is happens if the exception is allowed to propagate.
Doing so cleanly is problematic, however, in circumstances where mutiple apps
and agents share a process. Leaving the background process around until it is
torn down by the usual policies is probably the safer course at present.
We support a ColorStateList reference now as a valid font color value
in the given html and manage html strings for all supported states
which we dynamically set while drawing the items.
This will get checked in along with changes to GlobalSearch,
EnhancedGoogleSearchProvider and Browser to make them use the new
model.
Bug: http://b/issue?id=1865037
Before it was hidden in cancel(), which does not get
called when the search dialog is dismissed by clicking
on a suggestion.
Fixes http://b/issue?id=1967633
Details:
- Add a new SearchDialogWrapper class that makes sure
all access to the SearchDialog is run one a single thread
other than the main ServerThread.
- Don't save/restore seach dialog state in Activity.
This resulted in lots of calls to the SearchManager
throughout the life cycle of all activities, for
the questionable benefit of restoring the search dialog
in a few cases.
- Remove search UI state save/restore, and the isVisible()
method from SearchManagerService. They are no longer used,
and were tricky to implement since they return values from
the search UI thread to the service.
- Handle configuration changes in searchDialogWrapper instead
of calling through from Activity.
Fixes http://b/issue?id=1938101
TODO:
- Activity.performPause() calls stopSearch(). This call may not happen
until the new activity has been started. If the new activity starts a
search immediately, this search could be cancelled by the old activity's
call top stopSearch().
If provided and true, URLs entered in the search dialog while searching within this activity would be detected and treated as URLs (show a 'go' button in the keyboard and invoke the browser directly when user launches the URL instead of passing the URL to the activity). If set to false any URLs entered are treated as normal query text.
The default value is false. This is an optional attribute.
A restricted Context is a special type of Context that prevents specific features
from being used. For instance, android:onClick, used by View, can be dangerous when
used from within apps widgets. By using a restricted Context to inflate apps widgets,
widgets providers are prevented from using android:onClick.
did not seem to expand to show the corpus selectors. (http://b/1906643)
It turns out that when the trackball was used to select this item, onItemClick
was getting called on the listener twice in AutoCompleteTextView#onKeyUp:
once when we call onKeyUp on the DropDownListView, and once a little further
down when we call performCompletion(). In our case, performCompletion() is
useless since it was intended for normal AutoCompleteTextViews which populate
text into the TextView when an item in the list is clicked, but we do not
rely on this. So the easiest fix is just to make performCompletion() do nothing
in our SearchAutoComplete subclass.
On invoking the search UI, the drop down list box with past queries and shortcut items
appears after a few hundreds of milliseconds on screen. This was because we were
displaying the drop down within the onFilterCompleted callback after the list box filtered
the items based on the given query text. While that code path is necessary, for the first
invocation of the search dialog with an empty query we can show the list box before the
text stuff happens. This change does that, issuing an async request to show the drop
down after pending events have been processed.
Without this change, on an average it took 350ms for the code to show the drop down.
With this change, on an average it takes 150ms.
update config changes in Resources.mSystem
Since Resources is preloaded in the zygote, system resources in Resources
need to be updated with config changes every time an application is started
