Because of the asynchronous behavior of keyguard, and incall explicitly
disabling keyguard, sometimes the window manager would wind up in a state in
which the "correct" app and activity window were shown, but focus was
recalculated "too soon," at a time when keyguard was just about gone but not
quite, and incall was not yet fully shown. In this case there was no currently
valid event target, but the final show of the incall window would not prompt a
focus recalculation, so that "no current focus" state would incorrectly persist,
resulting in spurious ANRs until some other phone activity forced a focus
update.
We now detect the problematic case when windows are shown, and make sure to
recalculate focus explicitly thereafter. This change does *not* fix the
underlying race conditions that have been resulting in mismatched state within
the window manager, but it does force a validation pass that puts things in
order so that normal operation can continue.
Change-Id: I8e7f5f0795f0042a0da074aeed385e3fbc210360
This fixes a problem that resulted in bogus battery statistics for the prox and light sensors
due to the sensors being enabled in an app's context and disabled in the system context.
Fixes problems reported in bug b/2211960
Change-Id: Ib0d3d9d06f043b386d3b8d494b9bad5bd40bb6e1
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fixes bug b/2198028 (testDirectionsFromScratchByTyping fails because of android.permission.ACCESS_WIFI_STATE)
Change-Id: I44e95981d805189ed6d906d388c5189ee788802f
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fixes bug b/2158297 (lock screen should time out after 7 seconds)
Change-Id: Ia3f7ef6464129ab78283923dbfd7f7472136e676
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fixes bug b/2202165 (Often I when pressing power to turn off I get the lock screen)
Change-Id: I53f8350203d57fbb5f143edc44985879caadd78f
Signed-off-by: Mike Lockwood <lockwood@android.com>
* changes:
Fix bug 2194213: Non-default system IMEs are enabled, but not initially shown in input method switcher. - Ensure system IMEs are put on the enabled list at startup/install. - If the default IME is not installed, choose another one whenever building input method list.
- Ensure system IMEs are put on the enabled list at startup/install.
- If the default IME is not installed, choose another one whenever building input method list.
* changes:
If we fail to persist the current settings and fall back to the back settings file when reading settings in PackageManager, we might rename the corrupted settings to backup(in case of power failure between the earlier write failure and file deletion) and end up loosing both files. So just clear up the corrupted current settings file if we have backup. The backup wouldn't exist if everything went well with persisting the earlier settings.
when reading settings in PackageManager, we might rename the corrupted settings to
backup(in case of power failure between the earlier write failure and file deletion)
and end up loosing both files.
So just clear up the corrupted current settings file if we have backup.
The backup wouldn't exist if everything went well with persisting the earlier settings.
We do this in both read and write just in case.
Fix problem with ignored sensor events right after screen turns on.
Do not flash button backlights when device is booting.
Process the first light sensor change after waking the screen immediately rather than debouncing.
Cancel mAutoBrightnessTask when light sensor is disabled.
Change-Id: Iffc5e090b239432b7643812fa8ecb5f69da1679d
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fiddle around with the offsets of wallpapers to have better defaults, and
update the offset when the currently wallpaper target is not setting an
offset itself.
Change-Id: I1864d098fb4813fb0c67857af8ebf398b35e6876
Track phone service state changes and use a separate timer for out-of-service
since the hunting can timeout on some devices.
Store the timeout value in the config.xml, as it is device/network specific.
Settings App will also change to use the hunting duration to compute the cost
of zero signal.
* changes:
do not merge Return valid package info for packages that have been uninstalled with an option to retain data and resources using the flag GET_UNINSTALLED_PACKAGES These packages do not have a package setting. just check the flag and return the required info from PackageParser.generatePackageInfo
We will use the System.SCREEN_BRIGHTNESS_MODE Settings value instead.
Add SCREEN_BRIGHTNESS_MODE_MANUAL and SCREEN_BRIGHTNESS_MODE_AUTOMATIC constants.
Change-Id: I01935be3fcb48cf76392d2c594205cb47babc5b2
Signed-off-by: Mike Lockwood <lockwood@android.com>
This thing needs to be rewritten. It's grown too complicated for what it's doing,
and I don't like the physics anyway.
Also, this leaves the bug where if you press back while it's animating down, the
animation is ignored. However it no longer jumps down all the way, it just
essentially ignores the back key.
Also, this makes the collapse get executed on the back key up event, so it works
with the swipe on the soft keys at the bottom of the screen.
Return valid package info for packages that have been uninstalled with
an option to retain data and resources using the flag GET_UNINSTALLED_PACKAGES
These packages do not have a package setting. just check the flag and return
the required info from PackageParser.generatePackageInfo
A new flag config_hardware_automatic_brightness_available indicates
that the device has hardware support for automatic screen brightness management,
while config_automatic_brightness_available now indicates that automatic
brightness mode is available in general.
If config_automatic_brightness_available is true but config_hardware_automatic_brightness_available is false,
then automatic brightness mode support in PowerManager support will be used.
Bug b/2015734 (Ambient light sensor support in power manager)
Change-Id: I6cd888252043dd63df3c25a1d14c21a04a91ad28
Signed-off-by: Mike Lockwood <lockwood@android.com>
This introduces some hacks in the framework to try to clean up the
data we are getting from the touch screen. There are two main things
being done here:
1. Look for changes in position that are unreasonably large, and
ignore them. This is intended to eliminate the spurious jumps that
often happen when releasing.
2. Add some simple adaptive averaging of the touch data. If the
difference between the last and next point is large enough, we
disable the averaging; otherwise we average up to the last 5 points.
The goal is to get rid of the noise of small movements so that things
like taps don't look like short flings, while still responding quickly
to rapid movement.
For averaging pressure, we also weight each averaged coordinate by
the reported pressure at that point. This is intended to keep the
coordinates closer together during a release, when the pressure is
going down and the accuracy decreasing. It may also result in some
other interesting artifacts, but hopefully nothing problematic.
Change-Id: I1369e9ab015c406946a45c2d72547da9c604178f
TokenWatcher.acquire() synchronizes on mTokens, not this,
so we need to synchronize on mKeyguardDisabled in disableKeyguard()
to synchronize properly with reenableKeyguard().
This should fix b/2180142 (Stuck in enable keyguard when receiving phone call)
Change-Id: Iad66a2748c7fbf2c516fdb8a00988696719ea80c
Signed-off-by: Mike Lockwood <lockwood@android.com>
The dock app is forcing the screen to a particular brightness level. This
causes the window manager to often call into the power manager with the
new brightness. This causes us to go in to updateLightsLocked() to figure
out and apply the real brightness to use. When the screen is off the
real brightness always remains 0, but even if it didn't change from the
last one we would start an animation which would when done put the system
to sleep and fight with the user trying to turn the device on.
Now, if the new target brightness is the same as the last one, we leave the
animation as-is -- either running or not as appropriate.
Change-Id: I067d55ea2b39e294c5d5291587a4d8727c0b8083
Since the StatusBarPolicy is run in the System Process and shouldn't therefore call into
the Telephony process we decided to make sure all the needed info was passed along with the
original notifications.
bug: 2173053
- Don't crash if the service's app process doesn't have a thread (this
can happen if we are currently starting the process and then try to
start the service again).
- Be more robust about deciding to start a service's process: try each
time it is started; the startProcess call will take care of ignoring
it if the process is already started.
- Fix some issues where we would leave dead processes on the low memory
list.
Change-Id: I490e01ba7b45adc191bab7ace377b6873e284897
Use ConnectivityManager.CONNECTIVITY_ACTION broadcast in LocationManagerService
to notify GPS when SUPL connection is ready instead of TelephonyIntents.ACTION_ANY_DATA_CONNECTION_STATE_CHANGED,
which is not sent in all cases.
Expand LocationProvider.updateNetworkState() to include NetworkInfo object.
Fixes bug b/2155661
Change-Id: Iee227ace7d536b36cf7973e3e6a8b7a621ce6565
Signed-off-by: Mike Lockwood <lockwood@android.com>
