Fix leak in TransitionInflater

A static map in TransitionInflater keyed off of Context instances,
which could cause contexts/activities to leak over time. This
fix removes that map and simply creates a new inflater each time.
The savings of the cached inflater was minimal an unnecessary, and the
intended sharing is in the context embedded in the inflater anyway.

Issue #11436919 leak in TransitionInflator

Change-Id: Ic05ca47f57723bd572bb6143df4035d66eedf5ad
Cancel current work in PrintDocumentAdatper if printing is cancelled.

Layout and write may take some time during which the user can
cancel printing. Currently we wait for the last operation,
being write or layout, to complete before closing the print
dialog. Now in such a scenario we request a cancellation of
the ongoing operation.

bug:11329523

Change-Id: Ia9d747163cc73509369a86c8b5afc83b7ee54859
Remove deprecated API calls to KeyguardManager from statusbar

Fixes bug 11448304

Change-Id: I3049a20d9320af0425d7a8f08d5aa208e470e292
Merge "Fix leak in TransitionInflater" into klp-dev
am 5747919f: Merge "Fix leak in TransitionInflater" into klp-dev

* commit '5747919fed5180956387c50cb03671b9e67be1d5':
  Fix leak in TransitionInflater
Merge "Cancel current work in PrintDocumentAdatper if printing is cancelled." into klp-dev
am df52471c: am 5747919f: Merge "Fix leak in TransitionInflater" into klp-dev

* commit 'df52471c994f2374ae87ce52dbad61b43e7285e8':
  Fix leak in TransitionInflater
am 6ce161d1: Merge "Cancel current work in PrintDocumentAdatper if printing is cancelled." into klp-dev

* commit '6ce161d1762a1c74b1ed6931c1d54f1f553267b0':
  Cancel current work in PrintDocumentAdatper if printing is cancelled.
am eccfe65f: am 6ce161d1: Merge "Cancel current work in PrintDocumentAdatper if printing is cancelled." into klp-dev

* commit 'eccfe65f9daf459342ebc658b8a40584dfcea016':
  Cancel current work in PrintDocumentAdatper if printing is cancelled.
Better enforcement in DocumentsProvider.call().

Use ContentProvider.enforceWritePermissionInner() to handle all edge
cases around checking if caller has write permissions.  This fixes
bug where call() would throw if caller and provider were the same app.

Bug: 11464234
Change-Id: Iace8e0e4243d56ed1cdcc9680383103975107036
Merge "Remove deprecated API calls to KeyguardManager from statusbar" into klp-dev
am 43ef1c8c: Merge "Remove deprecated API calls to KeyguardManager from statusbar" into klp-dev

* commit '43ef1c8c34c6dd7c7ae75ac2c1b9bfdc15405b04':
  Remove deprecated API calls to KeyguardManager from statusbar
Set persist.sys.dalvik.vm.lib at system server startup

Bug: 11463182
Change-Id: I4409e84570c4e27bf8da36d0aca87812a1c032a6
am aa8dbf11: am 43ef1c8c: Merge "Remove deprecated API calls to KeyguardManager from statusbar" into klp-dev

* commit 'aa8dbf111444435b6071f7b226af5a7bb2a56c52':
  Remove deprecated API calls to KeyguardManager from statusbar
gcam: Avoid leaking repeating CaptureRequests.

Bug: 11352359
Change-Id: I598416c08c0a7c3e5a8054a4d80ed29d82870bd2
update HCE doc images to dac stencils

Change-Id: I57a1b393340c34bfaa66418957cf673a64e69890
Update the PdfDocument docs with unsupported operations.

The PDF generating canvas we use does not yet support all
drawing operations. This change adds docs which operations
are not yet supported.

Change-Id: I8d5ee8c1e2a473ba783b5e62f23ab90a54bbf106
(cherry picked from commit 8db45b844b5482cf61839404c0f6847e053de817)
link fixes

Change-Id: Ieb7e7f7f3997edca75399b2240e9c8043f3e0129
Uninitialized UiAutomationConnection incorrectly enforces caller id.

When a client of a UiAutomationConnection is set it remembers its UID
and allows subsequent operations only from this UID. The connection
If the connection was not used, i.e. its client is not set, and an
attempt to destroy it is made the connection enforces the caller UID
to be that of the owner but it does not have an owner yet. Now if the
destroy method is called on a connection that is never used (has no
client) we do not enforce caller UID.

bug:11465888

Change-Id: I739dfc45e772ea970b6ab384e4420184724333a3
Fix issue #11168649: LRU logic for Chrome renderers seems...

...not to work on KitKat (was: Janky exit animation)

Reworking the LRU list (splitting it into an activity vs. empty
section) accidentally broken the old behavior of "client activity"
processes being prioritized with activity processes.  In fact, we
were no longer marking "client activity" processes at all.

In this change, we rework how we manage "client activity" processes
by putting them on the main activity LRU section.  This is generally
simple -- ActiveServices now keeps track of whether a process is
a "client activity" process based on its bindings, and updateLruProcess
treats these as regular activity processes.  However, we don't want
to allow processes doing this to spam our LRU list so that we lose
everything else, so there is some additional complexity in managing
that list where we spread client activity processes across is so
that the intermingle with other activity processes.

The rest of the change is fairly simple -- the old client activity
process management is gone, but that doesn't matter because it wasn't
actually running any more.  There is a new argument to updateLruProcess
to indicate a client process it comes from (since we now need to update
this based on bindings) which is just used to limit how high in the
LRU list we can move things.  The ProcessRecord.hasActivities field is
simply removied, because ProcessRecord.activities.size() > 0 means the
same thing, and that is actually what all of the key mechanisms are using
at this point.

Finally, note there is some commented out code of a new way to manage
the LRU movement.  This isn't in use, but something I would like to
move to in the next release so it is staying there for now for further
development.

Change-Id: Id8a21b4e32bb5aa9c8e7d443de4b658487cfbe18