bug:17600162
Transparent draws are not safe to reject for all xfermodes other than
clear. Now, to be safe, only perform the rejection for SrcOver draws
since other modes are fairly uncommon.
We could specifically determine whether the xfermode could change the
output given a transparent input, but there's little to be gained from
the additional complexity.
Change-Id: Ia699ac4bdc4da3353955840b53f1922d3cb1d85d
Seriously, don't look at this. It is so dumb.
Brought up by issue #17307700: retarget a relinquished
task is not working
Change-Id: I947438d3502f75510e2974211bb78d31008eaa90
In some network, deactivate PDP connection cause releasing of RRC connection,
which MM/IMSI detaching request needs. Without this detaching, network can
not release the network resources previously attached.
So we are avoiding data detaching on these networks.
Bug: 16207801
Change-Id: Ib2ccc04d67f313e1241872b17ab38416607b0b48
The documentation implied that you could override
Resources.getDrawable(int) to load custom drawables, which is
not the case.
BUG: 16635905
Change-Id: I06c0febe2d6d4194ef5a31f167b378fe311b7a2d
There exists a lifecycle regression where launching an
app from the lockscreen (camera, etc.) causes a series
of onResume, onPause, onRestart, onStart, onResume.
This CL reverts the behavior to what it was in KK, which
is to say that the Launcher is first resumed/paused, then
the Activity being launched has a simple onRestart,onStart, onResume
lifecycle.
Bug:17459745
Change-Id: I04091d2f86a929ee972c8d6debc1beb033c135a8
User should be able to dial 0 or 00 in AT&T network.
The code should not be taken as MMI Code.
Bug: 17314389
Change-Id: I7132f08b633c6539dc0dd4e2d7865adcda795913
Bug: 16978006
Don't HWUI-accelerate KeyguardScrim
Aggressively trim memory as soon as a ViewRootImpl
dies or has its visibility changed.
Change-Id: Ie1b7c9d30653456bd2e9f309128174f972999368
TouchUtil's drag method tries to sync after sending
each event which is not necessary. Sync are slow so
removing them greatly improves test running time.
Bug: 17323559
Change-Id: Ia4ed02b2af44da0d821d93d28f963005d9d7ea79
In the spooler we have the renderer reading a file to visualize
content and the app writing a file to produce the content. Since
we have to swap the file under the renderer we have a mutex file
provider that both parties can request, use when released, and
release when required. This enables us to request the file which
closes the renderer and when the renderer is closed ask the app
to write some more pages, then open the renderer, and so on. The
mutex file provider was throwing of a thread that does not own
the file thries to relase it which is not needed, this should be
just a nop.
bug:17607134
Change-Id: Id6a2ce92d70077f57978b95315648faf02c13c68
Decouple events from alarms in the zen interception function,
and default the new allowEvents to true.
Bug:17580878
Change-Id: Iff10df385206ad73c3423ff118c79e94a10918d9
There was some code here locking on the lock object instead of
the main activity manager lock...!!!
Change-Id: Ic85151fbef915f6fb8fd5ce3c1a7e9b810412cb6
Try to catch any cases where we remove a ProcessRecord from the LRU
list when it may still have a process associated with it, report
that this happened, and try to make sure the process is killed.
Change-Id: Icd74439caba5e1c283c01a49a46dae926a00ba71
When restoring app widget state from XML we read all providers,
hosts, and widgets and only after reading all hosts and providers
for all members of the group we hookup the widgets as they may
cross profile boundary. To esntablish the host-widget and provider-
widget relation we use a tag for the host and the provider that
are assigned before saving the state to XML. When restoring we
are using the tags to match widgets with hosts and providers. The
bug was that we were not clearing the tag of all hosts and providers
before reading from XML as we want the only tags that are defined
to be the ones we are reading. This resulted in wrong app widget
restore for a secondary user.
bug:17505027
Change-Id: I035d8f13142c6b9dbc9d658b82390f9cd8d75e0d
