BUG: 24385082
BUG: 23144425
BUG: 18117279
Run jobs with connectivity constraints as soon as the developer-allotted
delay has expired, rather than waiting for the override deadline. This
is more in tune with what developers expect, although it reduces the
amount of batching the scheduler can theoretically do.
This will also have the side effect of fixing several failing cts
tests that started breaking b/c the signal to 'run connectivity
jobs early' was removed in M and nothing was put in to replace it.
Change-Id: I7e63c2b62f2882ee906f748445bbf10c32e19c5f
(cherry picked from commit aa9843198dec910a581bdc509d3937a9ea6ceca9)
Ensure the clip rect taken from transformations is cleared
when there is no transformation. Normally the failure to
clear the clip would not cause a problem, as the final clip
would be equal to the window size. However, in the event that
the window scale goes on to change (WindowState::m(H/V)Scale that is)
the clip will now be specified at the inappropriate scale (notice the
way the clip must be divided by H/VScale as SurfaceFlinger will apply
the surface transform to the clip).
Bug:24298694
Change-Id: I4548e8ecea8d66d4942e99823653a7b05f87cea0
(cherry picked from commit 2f0fe62c5426533ccdf9ec7ef28027c367286979)
This will not destroy the surface but will free up everything else used by
ColorFade when the screen is turned off. When it is turned on the surface is
dismissed.
Bug: 24371570
Change-Id: Iba455cdf225a68b320896f8b35d1e873e694b1e3
No longer dexopt all system apps and boot listener user apps.
Bug: 23628238
Bug: https://code.google.com/p/android/issues/detail?id=186589
(cherry-picked from commit b84cb9e9719855d56ea74c2eb7afc49034c0e66f)
Change-Id: Id1a1ca9f46777f9e62df3d4f25e98a2837fabf37
This is currently being hit because Settings does not clear the
always-on VPN configuration when the corresponding VPN profile is
deleted. This will be fixed in Settings, but there's no harm in
being robust to invalid configurations here.
Bug: 23625458
Change-Id: Id185a54d5892339197cd40026df5174debd957cf
This follows up Ia70b870723acf647e0c27f24aff91b40d6f85543.
In certain scenarios, only IMMS#mCurMethodId is cleared with null
while IMMS#mCurClient is still pointing to the last application.
This is problematic when IMMS#mCurClient matches
SystemConfig#getFixedImeApps(), because it means that the current
IME is to be fixed to null.
With this CL, IMMS#unbindCurrentClientLocked() is always called
every time when IMMS#mCurMethodId is cleared to null. Note that
clearing IMMS#mCurMethodId to null is a kind of hard-reset, where
unbinding IME client should make much sense in terms of robust
and predictable state management.
Bug: 18056075
Change-Id: I6c3186050592526fc95c5b27f18e2155acff5ebc
(cherry picked from commit e13a20faccf6f33aa43c9c1fa4c4ec2a79b86cfb)
If an app in a shared user uses permission A and B and these are granted
to the shared user and now an app update is installed that only uses A,
the shared user still ratains the B grant. A shared user should have only
permissions declared as used by its currenlty installed apps.
bug:24736912
Change-Id: Idea6c06bdc236fd481a860cddb379e6ce660ee87
Remove from whitelist as appropriate. Also be sure we can find whitelisted
apps even if they are not installed in the primary user.
Change-Id: I3ed13dca99b3ba177af8f7bd26a75258df9b6949
The callingUid can be different from that of the app been locked
(e.g. was launched from launcher) there by leading to the app crashing
when it tries to exit lockTaskMode.
Bug: 24146132
Change-Id: I03346fabd1d7e61b29178220c72f747a0600f5ec
When system has more than one built in display, displayReady needs
to be called for all built in displays when window manager is ready.
Otherwise, some system services, such as presentation, mediarouter,
etc, won't work on these displays.
Bug: 24103683
Change-Id: Ibf08074eff555c14a318236bd06e7b4855503140
BUG: 24341715
Failed jobs are rescheduled with no override deadline to avoid
running a failed job with unsatisfied constraints.
A periodic job always has an override deadline and the periodic
rescheduling code assumes this.
Hence a periodic that failed until eventual success would be
rescheduled in a bad state.
Change-Id: Id110b3522df2003506a9efdde4e719e1b9932106
(cherry picked from commit 1bde39ad1424008917e1191565f81e0b4617f2fa)
Fix a race condition where the wait index can be incremented inbetween
the while() loop and the lock
Fix when updateOrientation() is called: after the sleep, otherwise
the last sleep is useless.
Bug 24677424
Change-Id: I03770a0fc8af57f4696ebee7e9c9110e17c55a24
Processing ZenModeHelper.setConfig() synchronously in
ZenModeConditions.onConditionChanged() can cause a cross deadlock between
ConditionProviders.mMutex and AudioService.mSettingsLock.
Add a method to set Zen mode config asynchronously.
Bug: 24528290.
Change-Id: I9c1701ca6bef084527821175d84002b612241995
For devices that monitor orientation (primarily for channel assignment
to stereo speakers):
The com.android.server.policy.WindowOrientationListener API is more
power efficient than simply monitoring the device's orientation. When
supported, use it instead of android.view.OrientationEventListener.
When WindowOrientationListener reports an orientation change, start
a thread to poll the UI orientation, as its change may lag behind
the observed rotation. Gradually increasing delays between polls
are stored in a table.
Bug 24415763
Change-Id: I69bf68da6107af24cd02a48961dd17ceab557816
Send a POWER_HINT_INTERACTION to improve redraw performance when the
phone is rotated.
bug 24583227
Change-Id: I1978f0dfb9a25c00ad4da5b44d10410ad7412001
Clean up SCO forced usage and A2DP suspend state upon
SCO device or profile disconnection.
This is in case the Bluetooth Headset service does not
do it.
Bug: 24316765.
Change-Id: Ifc0305607c186be49b2eb42b7868647292e56137
This caused a but where WindowManager was blocked on this to perform a
layout, leading to delays in screen wake-ups.
Bug: 24383169
Change-Id: I42bc08dae9057060f09c301328bb4839a970c597
When a window has both the flag fullscreen and the dismiss Keyguard
flag, we end up in a state where we hide the status bar window but
all other windows, because mShowingLockscreen nevers gets set
correctly. Move it up so we always set it no matter whether the
status bar window was visible.
Bug: 22875357
Change-Id: I7953fe7100cc99fe8fb7424a9b311b4630426657
Previously the color fade layers would stay active until the screen was turned
back on. After this change, the layers are dismissed as soon as color fade
completes.
Bug: 24276564
Change-Id: I1f81b397d82d518c2bc921b22f7fe9fd066fc059
Propagate the boot status explicitly to installd so that we do not
have to rely on dev.bootcomplete, which isn't meaningfully set
when the device needs the decryption screen on boot.
Bug: 23898216
Change-Id: I9b34298caf70b1e5d40970cc0d04c469016a80a7
ActivityManagerService: In the case where we are launching
an application on behalf of a Content Provider request,
enforce a timeout inbetween the application attaching and
the content providers being published. Consider that a defective
content provider may block in ContentProvider::onCreate
indefinitely: in such a case the PROC_START_TIMEOUT has already
been removed as the activity manager must have called bindApplication.
In these cases, there will be nothing to wake threads blocking
on the (non timed) wait for provider to be published at the end of
ActivityManagerService::getContentProviderImpl. This can cause binder
threads to block 1 by 1 until eventually AMS runs out and becomes
unresponsive.
Bug: 22141958
Change-Id: I2226da5df5c79b37f0b896423b3c1eaa4a7ecbba
(cherry picked from commit da33c13434cb20a11b522374411a5b819503e4e0)
Private volumes with many large apps can take a long time to scan,
which currently happens on the main thread with several large locks
held, making it likely to trigger the system-wide watchdog.
This change relaxes this locking by scanning on the PackageManager
worker thread, and by only holding locks when required. In
particular, we release the installer lock between each scan to give
other apps waiting to dexopt a chance to breathe.
Bug: 24172036
Change-Id: Ie28d3ff72d6be28fa2f72c57d5e4146c768df89d
Use the existing PointerEventListener infrastructure to listen for
gestures that look like flings and hint to the power system when they
happen. Since we don't actually have a bound for the fling like a
regular application would, limit them to five seconds and refresh
every time a new fling is seen until the five second time period is
up.
bug 24059298
Change-Id: I5757a1e88f2ab2ef08cccefa8221d809ae71bb6f
