It was possible for other apps to request removal of the guest user
that was handled by an internal receiver in SystemUI.
Fix requires the broadcast sender to have an internal permission
so that only SystemUI can send that broadcast (PendingIntent).
Bug: 22671268
Change-Id: I63a8ced692e6d1cb2872b962ad247a827dbafbc6
Bug: 22667315
HWUI internally always assumes that RenderNode->properties()
has a fully-baked matrix. However, RenderThread animations violate
this and will perform an update of that matrix after they run. This
was missing in the fallback scenario where an animation was
running on a View that is detached from the tree.
If a RenderThread animation is started on an attached view, it becomes
detached, and is then re-attached it will crash in the staging
properties push. The fix for this is to move the call to updateMatrix
from animate() to animateCommon() so that the animateNoDamage()
path will similarly perform the necessary matrix update.
Change-Id: I4c899a6f68659342a6515f1d7f20d3c4af65caf0
Some carrier card has incorrect language file.
This is to disable loading language setting from SIM card.
BUG=22255379
Change-Id: I217a530758c8f9b3ee85c8a277096155e95bb060
We now keep the fingerprint running and switch to the bouncer when
the user successfully authenticated.
Bug: 21618072
Change-Id: If00061cb3914afd4d7a7d75964594484c792a890
Basically this is a copy of Iabef96921dd554ce3768fb18619cefc
for InputMethodManagerService.
As described in JavaDoc of Intent#ACTION_SCREEN_OFF and
Intent#ACTION_SCREEN_ON, one can use those Intents to be
notified when the device becomes non-interactive and
interactive. IMMS has relied on them to enable and disable
InputConnection between the IME and the application so as not
to allow IMEs to update text when the user does not present.
This is actually our design goal as documented in JavaDoc of
InputMethodManager.
An IME can never interact with an InputConnection while
the screen is off. This is enforced by making all clients
inactive while the screen is off, and prevents bad IMEs from
driving the UI when the user can not be aware of its
behavior.
The goal of this CL is to improve the timeliness of above
mechianism by introducing a direct communication channel from
PowerManagerService to InputMethodManagerService via Notifier.
Actually this is what InputManager has been doing since
Iabef96921dd554ce3768fb18619cefc3230b5fb0.
Reasons behind this change are:
1. There are several bugreports that imply those Intents can
dispatch tens of seconds after it is enqueued. This is
indeed problematic because the user cannot type password
to unlock their devices until queued
Intent#ACTION_SCREEN_ON is dispatched. This CL addresses
such an issue without waiting for figuring out the root
cause of the delay.
2. Intent#ACTION_SCREEN_OFF and Intent#ACTION_SCREEN_ON are
sent as a ordered broadcast, which may not be suitable for
tasks that require a certain level of timeliness, and what
IMMS wants is to enable users to start typing immediately
after the system.
This CL was originally authored by Seigo Nonaka.
Bug: 22423200
Bug: 22555778
Change-Id: I747c37ff6dd8f233faef43f2b5713a4320e848eb
If the user has a screen lock, the user is prompted to authenticate.
Otherwise the keyguard is dismissed.
Bug: 22694837
Change-Id: I783fc6f08fb21977aa4f1e884b0a4354a3154805
Also, switch to using a RelativeLayout from a LinearLayout. The change
will help in future when enabling transparent status and nav bar.
Change-Id: Ie4db5d28313f1c5ef775603788598a56409f92c7
Not all attr are added to R.attr. This results in some attr not being
found and hence a broken rendering. Fix the issue by adding all attr
referenced in R.styleable to the map of attr before adding any remaining
values from R.attr.
Change-Id: I1ebf8a394b9e1edbf7490e011833d20a00d38317
Need to look at a ServiceState to determine if we are actually in
a emergency only state.
Bug: 22619451
Change-Id: I06a2a6fab85ed2ce41d8f7cbb98a1f169ec61b33
Volatile doesn't provide any guarantees with respect to write
visibility, so it's possible that PowerManager will tell InputManager
about a change in interactivity state, but the actual dispatching
thread will never observe it.
Also, add logging about NativeInputManager state.
Bug: 22422588
Change-Id: Ifc3add992b9009d920d80a0315ff89c9574be20d
Bug: 22676664
If a task is queued on a worker thread that is busy
processing a task AND a trim memory signal comes along
prior to the initial task being completed then the
tasks that were queued prior to the exit request will
never be processed.
This is bad, as when those futures are used later on, such
as in trying to delete them from the cache, they will block
waiting for the orphaned task to be finished.
Simple fix is to just never stop the worker threads. Increase
RAM usage slightly as we won't reclaim that stack space, but
this cost is fairly small
Change-Id: I818b011f9bc6ba06942fdad81c27656bd97b42d4
