InputDeviceReaderThread could be killed if a key or touch event
was received before initiation made by PolicyThread was made. To
solve this, the start call for the InputDeviceReader thread was
delayed until initalization of the PolicyThread was done in
the WindowManagerService.
Change-Id: Ifa7de7ccfadd66ecc2b14c6273e9be32b8e0cb4a
When WindowManager reports "Key dispatching timed out"
it prints out information about the window state that was
present at the time the key was sent to that window.
There is a minor error in the class representing the
recorded window state so that the currently focused window
is printed instead of the recorded focused window.
Change-Id: I29a5471ef725e30f812ffd57fd4597ce81c0c7f2
Remove the ProximityAlerts update Receiver when the last ProximityAlert expires.
Fixes issue 6900.
Change-Id: Ida1970c084e71df47b204c64986a065cb75d0c13
Previously the key event repeat count was always zero when the repeated
key down events was generated by the input device in the Linux kernel.
Change-Id: I86b7fd2a75880bc54d052ef404c3654b7ed14c52
LocationManagerService was just checking if the string of (comma-separated)
Location Providers contained the provider we were interested in. This works
fine in normal cases, but breaks if we add a provider such as test_network.
Enabling test_network causes LocationManagerService to think that the network
provider is also enabled.
The code in Settings.Secure.isLocationProviderEnabled() checks for the commas
in the string as well, to make sure that a provider name which is a substring
of another provider name won't cause problems. It also centralizes the code
which reads the string.
Signed-off-by: Brad Larson <brad.larson@garmin.com>
Change-Id: I00dfe7c2b09739ed4c8ed07c6167e409b0bf7d13
Newly created dim surface has alpha set to 1 (opaque),
but it is assumed in dim animation code that it is 0 (transparent).
When new dim surface is created and expected dim value is calculated to 0
then alpha is never set making screen black (dut to default aplha=1)
when dim surface is shown.
WindowManagerService (WMS) can wrongly report windows visibility due
to wrong handling of "starting windows".
"Starting windows" are special temporary windows that are displayed
while the application is starting.
Sometimes "starting windows" are considered when checking visibility
what leads to not reported or wrongly reported visibility status.
If visibility is not reported correctly some internal flows are
not executed and WMS internal state can be wrong.
Several functions operate on variables to which access needs to be
synchronized. However, it happens that the functions in question
are only ever called from places which have already synchronized.
Therefore, nothing is really wrong, but the functions ought to
have 'Locked' appended to their names, to indicate that it is the
caller's responsibility to synchronize before calling them.
Change-Id: I44e7dc0dff6da9436677cb10908dce41ffeba195
There exists a race condition when starting a process that recently has died.
If the ActivityManager receives the death notification for the died process
after the new process has been started but before an application thread has
been attached to the new process will the newly created process be removed
during the cleanup of the died process. If this happens when sending a broadcast
could it result in an ANR.
This is solved by doing the clean up before starting a new process that uses
the same process record.
Fixes a memory leak when input methods are switched. Uses a variety of methods
to avoid holding a reference to the InputMethodService which created the binders,
which was leaking those InputMethodServices.
See http://code.google.com/p/android/issues/detail?id=6661 for reproduction steps.
Merge commit 'ee3bbefd34fd5330ebbc59175a328197ab7526af' into eclair-plus-aosp
* commit 'ee3bbefd34fd5330ebbc59175a328197ab7526af':
Don't crash the system process when apps give us a bad foreground service notification.
This is a new implementation of TTY support.
Previous implementation in commit aead64def1fe58c95c086a0ca00cf0b13fa32ef1 is reverted.
The new method does not rely any more on the kernel headset driver to send a UEvent containing
current TTY mode.
when injecting a Key, Pointer and Trackball events into the UI across
applications, the corresponding methods throw SecurityException with
incorrect permission message.
INJECT EVENT permission should be INJECT_EVENTS
Merge commit '08be55b8ea917a5273c135a7bdc73e41c8524c05' into eclair-plus-aosp
* commit '08be55b8ea917a5273c135a7bdc73e41c8524c05':
Add null checks when scanning a package.
Handle TTY mode change events received by HeadsetObserver and send information down to AudioHardware with AudioManager.setParameters()
Use setting "tty_mode_uses_heaset_events" in core config.xml to indicate if the product uses this particular
method of indicating the TTY mode change.
Merge commit 'cc4b4016e4b86db012f94bb889e5ca61ff362171' into eclair-plus-aosp
* commit 'cc4b4016e4b86db012f94bb889e5ca61ff362171':
Fix the reporting of NO_CONNECTIVITY.
A refactoring of handleDisconnect instroduced a bug - we were reporting
NO_CONNECTIVITY after any non-primary network (supl, mms, hipri) was lost.
bug:2395006
Change-Id: Ifa9e008872ec646981a35f2c316120cb9685a6a4
Merge commit '5381e4ef4ef1a05b25fa39ff942f4a95e0ae4750' into eclair-plus-aosp
* commit '5381e4ef4ef1a05b25fa39ff942f4a95e0ae4750':
Refine fix I53e91db7 to apply only to wifi network
The original fix eliminated duplicate wifi connectivity changes stemming from
location provder scan's for APs. These would generate two DISCONNECTED broadcasts every
two minutes and many apps mis-interpreted them.
The fix was to ignore notifications where the major state was the same as the previous one
for each network. Unfortunately the state of per-apn notifications on cellular is hacky
and so the wifi fix was breaking mms (mms when you're on cellular with a common default+mms apn does
not generate a disconnect notification (apn still connected) so subsequent connect notifications
get dropped as duplicates).
This change refines the previous change so that it only applies to wifi networks.
bug:2392061
Change-Id: I05d8a46a4b55f8d28df8af12e05284e5e68bfc02
drno: ryanpc
Merge commit 'a59551bade6a7b0c916c277f044de79c6af1bd22' into eclair-plus-aosp
* commit 'a59551bade6a7b0c916c277f044de79c6af1bd22':
Fix issue 2388215: Audio not routed to 3.5mm Headset after removal/insertion.
The problem occurs if the delay between the headset removal and insertion is less than one second.
In this case, as the headset disconnection intent is broadcast with a 1 second delay to allow music to pause
before updating the route, the connection intent is broadcast before and is ignored, leaving the system
in a state where the headset is considered disconnected.
The fix consists in inserting a delay before broadcasting the connection intent if a disconnection
intent is pending broadcast.
Merge commit '9fdf82e080ea20086378e751ace245a4a1b022dc' into eclair-plus-aosp
* commit '9fdf82e080ea20086378e751ace245a4a1b022dc':
Try to switch to another default net on connection failure.
This shouldn't be required, but there seems to be something odd going on
in wifi and it doesn't hurt to try other available options. Makes a
connection failure case work like a disconnected case.
bug: 2378462
Merge commit '48ef378d01b3ace349cbb6ba564276b854d872c9' into eclair-plus-aosp
* commit '48ef378d01b3ace349cbb6ba564276b854d872c9':
DO NOT MERGE Avoid wifi disable in a UNKNOWN state
Merge commit '1a337547d5377c57dbb10a24d4d73ad6bda829ea' into eclair-plus-aosp
* commit '1a337547d5377c57dbb10a24d4d73ad6bda829ea':
Add bugreport info about network feature use. DO NOT MERGE
Backported from master change Ib9285359.
We've had a couple bug reports showing the effects of a left-live feature request.
We need a bit more bugreport-time logging.
bug: 2323226
bug: 2377507
change-id: I296b2887101c260aea678bf6db91144535cbad7e
