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.
* changes:
Fix couple of issues in DatePicker The NumberPicker's listener needs to be invoked only if the current value changes when validating input. This removes the some unwanted duplicate calls to onChanged. Adjust day for month and leap years. note that updateDaySpinner directly sets the value on day picker and doesn't invoke the listener twice
The NumberPicker's listener needs to be invoked only if
the current value changes when validating input.
This removes the some unwanted duplicate calls to onChanged.
Adjust day for month and leap years. note that updateDaySpinner
directly sets the value on day picker and doesn't invoke the
listener twice
ViewRoot keeps a reference to the previously focused View and use this reference
when trying to scroll the window to the focused rect. There situations however
in which the previously focused view might have been removed from the view
hierarchy. This happens on Home for instance when you trash an icon, or with
ListView's items. This change ensures the previously focused view is still part
of the view hierarchy.
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
The initialization of SearchManagerService is delayed, which caused
problems when other services (e.g. GlobalSearch) start up.
This change makes the SearchManagerService components
initialize when they are first needed, or when the server thread
is done with its other processing, whichever comes first.
Fixes http://b/issue?id=1970975
* changes:
Add support in TextToSpeech for an audio stream type param and utterance ID specified as a hashmap param in the synthesis calls. Fix a bug where the cached parameters were not passed to the service when synthesizing to a file.
ID specified as a hashmap param in the synthesis calls.
Fix a bug where the cached parameters were not passed to the service
when synthesizing to a file.
Install an observer for the Location system setting and
move the Gears permission check to a slightly earlier time.
Move the logic into a separate manager class.
Also delete some whitespace and fix some style issues.
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
This is the problem where various things are listening for broadcasts
(such as battery status, PIN/PUK/Network) that an application can send
to cause harm to the system.
Solving this is tricky because many of these broadcasts are sticky,
and I have never figured out how to do permissions with sticky
broadcasts in a sane way. So instead, I am going to punt on the
general problem and just brute force it:
There is new a way for system components to declare specific
broadcast actions to be protected, which means that only the system
and the phone can send them. This is good enough for now. None
of it is exposed in the public API so we can make something a little
less stupid in the future if we ever need to.
