Play a sound and vibrate (by setting DEFAULT_ALL) only if the
user manually selected the network. This applies to both captive
portals and networks with no Internet access.
Bug: 24126143
Change-Id: Idf075d5c85f9f4b07a3431a25d1a3f7089cf1ee2
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
Add a remote call addBluetoothDevice() using AIDL.
This was needed because onBind() is only called once.
Bug: 23219556
Bug: 23760886
Change-Id: Id7554ca55d596352d11dbd6ae3e403138a29c864
Signed-off-by: Phil Burk <philburk@google.com>
(cherry picked from commit 7cd06c0b9e)
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 e13a20facc)
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
This will give an app an opportunity to learn whether an input port is busy
before the user tries to connect and then fails.
Bug: 22825043
Change-Id: Ifede60f166dfe66ea15453044fce06f4a8452b18
Signed-off-by: Phil Burk <philburk@google.com>
(cherry picked from commit b2355940e3)
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
This makes it so that the socket cannot receive datagrams from
anybody except the DHCP server. This does not improve security,
because we never read from the UDP socket anyway, but it does
make ListeningPortsTest pass.
Bug: 23906864
Bug: 23933386
Change-Id: Ib090273a417f7eb2ac1ee3309260249b72fb8345
* changes:
Support DHCP replies with multiple default gateways.
Accept DHCP responses from non-67 server source ports
Improve logging of DHCP parse errors using exceptions.
...user for service info
Now it does.
The actual change is basically one line, passing in the current user
when building the service info. The rest is more debugging output to
be able to see what is going on.
Change-Id: I451884e0780aac6ee92fd2cd520071894afdf586
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 1bde39ad14)
If recognition has been aborted, then the call to the sound trigger
device stop recognition has already occurred. The sound trigger helper
would then try to stop it again, which generates an error code for a
stop without a corresponding start event.
BUG=24677430
Change-Id: Ibf5d1da1a8eb06b677e428f047905d15fd5cf21f
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
