Adds parallelSetAll(int[], java.util.function.IntUnaryOperator),
parallelSetAll(long[], java.util.function.IntToLongFunction),
parallelSetAll(double[], java.util.function.IntToDoubleFunction),
parallelSetAll(T[], java.util.function.IntFunction<? extends T>)
from the upstream along with the corresponding tests.
Bug: 27540010
(cherry-picked from commit 4293e554db)
Change-Id: Iaa4a0749d8bb95ea8a0072a43bfbd6d6f459ff28
This attempts to reland previously reverted CLs [1][2] due to an
unexpected regression (Bug 27824691).
The Bug 27868748 we want to address by this CL is that currently
InputConnection#finishComposingText() can be called on the root view's
Handler no matter what Handler is associated with
ControlledInputConnectionWrapper. Actually the root cause of
Bug 6789252 is the same, but there we worked around it by not calling
InputConnection#finishComposingText() in certain situations [3].
With this CL we should be able to logically revert that workaround.
This CL also removes redundant IMM#mServedInputConnection. This is safe
because the following two fields have the same lifetime.
- InputMethodManager#mServedInputConnection
- InputMethodManager#mServedInputConnectionWrapper
We do not need to maintain both of them. This also allows us to use a
strong refecente in IInputConnectionWrapper#mInputConnection instead of
a WeakReference. To understand why this is safe, we need to understand
how things previously worked, which is as follows:
1. InputMethodManager#mServedInputConnection becomes non-null.
-> IInputConnectionWrapper#mInputConnection.get() is guaranteed to
be alive.
2. InputMethodManager#mServedInputConnection becomes null or another
object.
-> IInputConnectionWrapper#mInputConnection.get() may not be alive.
Since we know exactly when InputMethodManager#mServedInputConnection is
updated, in theory we do not need to use WeakReference here, and
with this CL we do not use WeakReference anymore. Actually the initial
commit [1] accidentally removed the last strong reference to the active
InputConnection and WeakReference could be null at any time, which was
what we observed in Bug 27824691.
[1]: I1181e067aa5bedbdf0c7ec1bcec479257aea511c
afb6558c8f
[2]: Ibe94f115e607a198d12ecd3d4e4f91a7d9469c98
16e2c7b59a
[3]: I66f51da1299532793ef8fa700f35b0811670f235
4e5184f929
Bug: 27868748
Change-Id: If2a03bc84d318775fd4a197fa43acde086eda442
To open files by using AppFuse, the provider needs to know the size of
file. Previously we cannot open 4G+ files because we cannot obtain file
size for such large files.
Now MtpDatabase contains correct size for 4GB+ file size. The CL starts
opening files by using AppFuse which obtains partial bytes by using
getObjectPartial64 operation.
FIXED=26840097
Change-Id: I1cb41972175c2b98f4aa76981decc6b3ad35486d
MtpObjectInfo contains object size as 32-bit integer and the provider
needs to invoke MtpDevice#getObjectSizeLong hidden API to get 64-bit
object size.
The CL switches to use MtpDevice#getObjectSizeLong hidden API if
MtpObjectInfo#getCompressedSize() returns 0xffffffffL, which means the
object size is more than 4GB.
BUG=27805369
Change-Id: I87ea02c09aa784246cf016def309d1f39ed20e90
If you use USB type C, you can charge Android from USB power or you can
supply power from Android to the other connected device.
Previously Android showed the notification saying "USB for charging".
The CL updates the text so that it shows the current power direction
explicitly.
Change-Id: Ic15ba70eaf8ade028283d8f490ac36e8d5e4db21
FIXED: 27706939
Adds documentation, renames Layout to WindowLayout and
splits #minimalSize to #minimalWidth and #minimalHeight.
Bug: 27528326
Change-Id: Idb440cb081a14ccdc83309284e906454633c4504
The purpose of the new StorageVolume API is to grant access to
volumes that aren't typically "visible" to a developer, so include
them in the returned results.
Also return the real mounted state instead of augmenting based on
the caller's storage permissions. Clean up API naming slightly and
return as List.
Bug: 27615770
Change-Id: Ida921a4b91e5af81e418e76f672d9108f45a9781
Now that CE data isn't available until after a user is unlocked, we
need to delay the PRE_BOOT_COMPLETED broadcasts. This is done by
adding a new RUNNING_UNLOCKING user state to the UserController
lifecycle.
We now track the last fingerprint a user was logged in under, and we
dispatch PRE_BOOT receivers when that fingerprint changes. To work
around battery pull issues, we only persist the updated fingerprint
once all PRE_BOOT receivers have finished. This is less granular
than the original solution, but it's still correct. We only consider
a user as "logged in" once it transitions into the RUNNING_UNLOCKED
state.
When starting a process, track if the user was "unlocked" when
started, so that we only spin up unaware providers in processes
started before user unlock.
Add generic IProgressListener to communicate PRE_BOOT progress and
strings up to lock screen. For now, LockSettingsService just blocks
until finished, but it could display these strings in the future.
Bug: 27220885
Change-Id: I349439776b885acd32f6a578d8951ffd95640be2
Making mZenModeController in PSB protected.
Bug: 27101250
Change-Id: Ibb3e66fb59b245aa293bbc32d1c1009ac1a0499a
(cherry picked from commit ac72fc49227fc02a919827a877637df4b0a65cf0)
am: 59d1c94
* commit '59d1c9430aa8b65febf1b77f99930328fd739844':
If the print spooler gets started onUserUnlock use less of a priority to have less impact on the system.
am: b5be5ec
* commit 'b5be5ec3b70c2c310601e9d035b4e8fd0db8b085':
Handle all configuration changes in PrintActivity as it cannot be destroyed synchronously.
