Refactor app movement code into the normal install flow as a new
flavor of InstallArgs. It copies both app code and data during the
copy step, and just updates paths during the rename step.
Measure free space before kicking off a move. Spawn a thread to
derive a hacky progress estimate based on free disk space counting
down.
Remove checkFreeStorage() and getLegacyNativeLibraryPath() which
nobody was calling. Fix deadlocks around package broadcasts, and fix
wrong lock ordering when loading packages.
Bug: 19993667, 20275578, 20370140
Change-Id: I7bbf14c924a724d6ebb8a41a02434750fa3302bc
Switch a few places to using android::canvas
instead of SkCanvas as well which eliminated
some JNI
Change-Id: I8f98b56442a06362b82b984cd1bd3a92398d8dbc
This converts KM_ERROR_CALLER_NONCE_PROHIBITED into
InvalidAlgorithmParameterSpec, as expected by the contract of JCA
Cipher.
Bug: 18088752
Change-Id: I6a01e2d7118c478b27a0d7a5a14a127de8913755
FingerprintManager internally creates a Handler which needs to be
bound to a Looper thread. Prior to this CL the Handler was bound to
the Looper of the current thread. This caused issues:
* Different instances of FingerprintManager could be bound to
different Looper threads.
* Callbacks from FingerprintManager were invoked on arbitrary
threads (or not at all if the Looper was there but wasn't running).
* FingerprintManager couldn't be obtained by apps on most non-main
threads leading to java.lang.RuntimeException: Can't create handler
inside thread that has not called Looper.prepare().
This CL fixes the issue by binding the FingerprintManager's Handler to
the Looper running on the main thread.
Bug: 20725228
Change-Id: I4a0382d6e11df9f23b8db9f0deec77369af31b5e
The FragmentManagerImpl is intimately tied with a FragmentActivity. In
many cases, we want to be able to create / manage Fragments outside of
a FragmentManager. This defines a FragmentController interface that can
be used by any class to host Fragments.
Bug: 19569654
Change-Id: I6816a5c1815122d206062b9f4584ad460b3d41dd
Stop assuming that a Java Bitmap has a SkBitmap* that
has some externally managed lifecycle, and instead switch
a bunch of users to accessing the bitmap by providing
their own SkBitmap* on which to set the (ref counted!)
SkPixelRef* instead
Attempt #2 to land this, original issue was in getSkBitmap
and should be fixed
Change-Id: I0fd9e193968b41e5597784140d56b4885906864a
FingerprintService is a lower layer of abstraction which should
ideally be accessed only via FingerprintManager from
AndroidKeyStore.
The main issue with the switch is that it requires a reference to a
Context. This is now obtained using ActivityThread's hidden API.
Change-Id: If921e169838ee2cc5c7690b8c8d8ea95c33248aa
A recent optimization assumed that layout_width and layout_height always
had to be defined to successfully generate layout params, but this is not
guaranteed to be true for custom ViewGroups.
Bug: 20267738
Change-Id: If09d346f30c0848b984b9137088f8f3b7617cd08
* MAC length is now specified as a parameters to the begin operation
instead of as a parameter at key generation/import time.
* KM_TAG_MAC_LENGTH is now in bits instead of in bytes.
Change-Id: I752fe232d11d3ac39a575a48948215d84ded8fb9
