If provided the extra entropy will be added to the device before calling
finish. If entropy is provided and the device does not support supplying
additional entropy then finish will fail with KM_ERROR_UNIMPLEMENTED.
(cherry-picked from commit 9ce30624a448f439e19960d0dd88103c04676e7d)
Change-Id: If26be118bf382604f6f8e96e833b76e6f9e94d58
Keep a reference on active Ringtones to avoid garbage collection
before playback is complete.
Bug: 11366759.
Change-Id: Icb04da427c20e0b4657e9e8b13b3ecab98e5a333
Previously going to the full shade and expanding notifications
where disabled when QS was expanded even though there was enough
space to allow it. This is now allowed again in order to have
a consistent experience.
Bug: 19712809
Change-Id: Ie756d9c3fbf9dc2e60a05d02f0f4cc5dd6c7ebe0
Now the preview clipper animation and our own circle drawing
are in sync again when launching an affordance!
Bug: 21440634
Change-Id: I96cda04926fb9ae62db6690ddebaf73df38e9ca9
When a notification came in dreamMode and would become a HUN
we were firing its fullscreen intent imediatelly. If that notification
got updated again a moment later, it would also show an additional
HUN even though we just launched the fullscreen intent. This is very
troublesome to handle on the app level, as the notification state
is the same. We are now introducing a cooldown for HUNs when it just
launched a fullscreen intent.
Bug: 19377091
Change-Id: Ib32341c8983f0e977354432ea8d8e98909a13829
It is possible for deadlocks to occur when sending/processing
PendingIntents due to components like AMS holding global service
locks when dispatching the broadcast without specifying an
handler and the receiver calling back into AMS.
We now set a default handler to process the broadcast on if we
are in the system process and a handler wasn't specified.
Bug: 19502993
Change-Id: Iccde32c6c1df997784155bc41ef39e52ee0f7243
This patch consists of two broad changes :
- don't "force" dex2oat when installing a new app. this should never
be necessary because we will always compare checksums.
- when staging a new install, we "inherit" (hard link) all compiled
oat files from the previous install. this will ensure that we compile
only those files that have changed, and not all of them
bug: 20889739
Change-Id: I3e14335f3bcfe76d1d24d233f53a728a6d90e8a1
Contrary to the expectations of the code, IoUtils.closeQuietly()
does not unblock system calls. So mReceiveThread.halt() was not
actually stopping the receive thread.
This wasn't actually a problem, because after "stopping" the
receive thread, either the interface would go down (interrupting
the previous receive thread with ENETDOWN), or a packet would
arrive to both the old and new receive threads, stopping the
old one. But the lack of a "stopping receive thread" message at
the expected time was confusing.
While I'm at it, also add the string for CMD_TIMEOUT.
Bug: 19704592
Change-Id: I74732429118af780453028898148519b294fa9d3
It turns out that IMMS#SettingsObserver has monitored
only main user's the secure settings. As a result, when the
secondary user changes enabled IMEs in the settigs app,
IMMS only updates internal enabled IME lists only when
the user is switched for secondary users. If a secondary
user enables or disables IMEs at the settings app, such
changes are not correctly notified to IMMS.
This CL addresses above inconsistency by explicitly
specifying the user ID when calling
ContentResolver#registerContentObserver().
This CL also allows dumpsys to contain internal state of
IMMS#mSettingsObserver in case we need to diagnose
problems only with bugreports.
Bug: 19340792
Bug: 19587437
Bug: 21612582
Change-Id: I34b437928c147e9fdbe935f725624cc97c816cb3
In order to diagnose IME issues in multi-user / multi-profile
environment, internal state of
InputMethodSubtypeSwitchingController needs to be included in
the bugreport.
Bug: 19340792
Bug: 19587437
Bug: 21612582
Change-Id: I34aca2c1a4330ec08b5e40441e631809a8bb844e
This CL changes nothing but adds more logging points in IMMS when
switching users and IMMS#DEBUG==true.
No impact in production code.
Bug: 19340792
Bug: 19587437
Bug: 21612582
Change-Id: Ibaeb77ae50d246fc322cb023da7750d7415a58ab
The initial implementation of toDhcpResults attempted to get the
leased IP address from ciaddr if yiaddr was 0.0.0.0, but it never
actually did so because a) it used == instead of equals(), and b)
the parsing code never populated mClientIp for a DhcpOfferPacket
or DhcpAckPacket.
Fix this and add a test for it.. Technically DHCP does not use
ciaddr (only bootp uses it), but in 5.0 we would use ciaddr if
yiaddr was 0.0.0.0 and a bit more compatibility shouldn't hurt.
Bug: 19704592
Change-Id: I1f58555f0c10b9c576995a6edb759a83d8938ea0
These helped once; but now this is just noise. Also
given that GMSCore starts/stops scans many times it is
taking too much of log real estate.
Bug: 20416721
Change-Id: I965ed919afbac56e123e8d019be84d7d33abf3f9
Prevents a race condition that could lead to leaking the home screen
if Keyguard is too slow at pushing its state to the window manager while
booting.
Bug: 21128921
Change-Id: I992066c2c4e1bc4f797776c7804408a53b658b03
