This fix forces the path through the updateLightsLocked method to turn
the screen on immediately if mWaitingForFirstLightSensor is true. Also
do not clear mWaitingForFirstLightSensor if mPreparingForScreenOn
is true. Wait until it turns false.
Fixes bug 6612418.
Change-Id: I03407e748cce4906a73de1f15df1654649b133c4
...for a smoother OOB experience
Way provided.
Put your defaults in system/etc/preferred-apps/*.xml.
Figure out what to put there with "adb shell dumpsys package preferred-xml".
Bug: 6680894
Change-Id: Ia06bb0061876274a5f80bf06d1ba5ad155edc323
- Create class to transfer state from WindowAnimator to
WindowManagerService.
- Detached wallpaper state was shared between the two classes. This
CL isolates it.
Change-Id: I7bcee348bf9f9f8f0228f36c53d75e5c92fd84cb
Currently just grabbing the window state but we could grab
other things as part of the last ANR report.
Bug: 6680398
Change-Id: I23aa70907b1bdcb21c8acc556fde196ca790ef6a
...in Developer options is on
Don't respect stay awake while on as long as a time to lock limit
is being enforced. When we start enforcing one, make sure the
setting is off (since we won't be respecting it anyway).
Bug: 6664140
Change-Id: Id07cb528afa0c64c7766341841c51771f507121d
Call noteWifiScanStartedFromSource() when a scan is started.
Call noteWifiScanStoppedFromSource() when a scan is finished.
The current implementation tracks to UID that requested the scan, and
correctly tracks the duration of the scan. It ignores scan requests
that occur when a scan is already in progress. It does not distinguish
between active and passive scans.
Repurpose all the noteScanWifiLockAcquired/Released() plumbing
for WIFI scan tracking. The WIFI scan locks were never reported
to the user. Use noteFullWifiLock() when WIFI scan locks are used -
this makes sense because the power draw for a WIFI scan lock
should be about the same as for a full WIFI lock.
Bug: 6642581
Change-Id: Ida6e87992853698545b89f875c973a239218317d
Weren't cleaning out any ActivityOptions that are still attached
to a finishing activity.
Bug: 6636731
Change-Id: If0520bbcbf1d4ce19d46ff769918893cefda9c87
People generally expect, if they are using FLAG_KEEP_SCREEN_ON,
that the screen won't immediately dim after it is cleared, even
if it has been passed the user activity timeout since the last
user interaction. So include the flag to reset the user activity
timeout when releasing its wake lock.
Change-Id: If7a8fea8faef3edbf13dff10a2f248adc9e3ff0b
The foreground activity is stopped when the device goes to sleep,
and started again when the device is unlocked. We now distinguish
this case from a "normal" stop, and do not finish() a foreground
noHistory="true" activity inappropriately when the device sleeps.
We also detect the case where an activity is started while the
device is still asleep, in which case the foreground noHistory
activity is cleaned up as part of bringing the new activity to
the foreground.
Bug 6657549
Change-Id: I9c6a0830aed0e47e4207b62803b90067c8486112
Tethering was re-evaluating everything on any connectivity change.
This was causing problems when mobile data was not available as each
re-eval was again requesting a connection which would fail and loop.
Ignore FAILED states to break this cycle in a minimal change.
bug:6668233
Change-Id: Ia1dfc6abff1fe464e9501b50185cdb8d0fbb7ff6
