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 VpnConnectingError.java.
+ Broadcast the error returned by daemons.
+ Add error codes to VpnManager.java.
+ Add error code to VpnManager.broadcastConnectivity().
Patch Set 4:
+ Replace VPN_UP with VPN_STATUS in response to ip-up-vpn changes.
+ Make VpnServiceBinder a foreground service so that it won't be
interrupted by the system.
Patch Set 5:
+ Remove the support of returning 0 from daemon and restart socket in
AndroidServiceProxy.
* 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.
The locale picker now wants the locale to always have a country, not just
a language, so having something for the country is necessary to let these
be chosen.
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.
