Call out specifically that each helper must only consume the
prior-state data that it produced in the first place, not reading
beyond its own part of the state file.
Bug 25473872
Change-Id: I1f24a5738a799eb21d966510372a0f3852436166
The disk-friendly use of BufferedInputStream in state parsing was
actually breaking the state management system when multiple helpers
are involved in backup. The BufferedInputStream would blithely
pre-fetch 8K from the state file -- but that would consume some
state data that the dispatcher and subsequent helpers needed to see
in order to properly evaluate prior state themselves. The contract
here is that when using the helper mechanism, state-data consumption
must *only* consume as much data as the helper originally stored
into the file.
Switching to a direct-read stream instead fixes the problem by
avoiding read overrun. The rest of the changes are expanded
debugging output that made diagnosis possible.
Bug 25473872
Change-Id: I91de38dfec96f589700479f41ac26f144ba4463c
We achieve the desired result by prolonging the last frame of the
animation until recents tells that it drew its content. The CL also
includes cleanup that moves code that depends heavily on WindowState
fields into that class.
Bug: 24913782
Change-Id: I5ee5b18504dd4a86c24033d17eca21cd31936bca
When the calling user is a work profile and the device has
file based encryption enabled, show the work challenge via the
Confirm Credentials APIs before launching the requested activity.
A companion CL in Settings will add support to the Confirm
Credentials flow to read the given intent extra and fire it when
the authorization succeeds.
This is part of the Separate Work Challenge feature.
Note nobody will see this yet as the feature is conditioned by
file based encryption.
Change-Id: I303890095936b1fd1f6a99d645724dffba144345
These simple utility classes (used internally since Property was first introduced
way back in Jellybean) are the best way to avoid autoboxing when using the Property
approach to ObjectAnimator. But since their hidden, developers have to use the
autoboxing version (Property, the superclass) or know to come up with their own
primitive-optimized property subclasses.
This CL simply un-hides these two classes to make them usable outside of the framework.
Issue #21722783 Make [Int|Float]Property public
Change-Id: I7f3a456d108bf48587d711255d3577cce3ac5e24
Added mUsersLock - short-term lock for internal state, when interaction and
synchronization with PM is not required. Modifications to mUsers and
mRemovingUserIds must be guarded by 3 locks: mInstallLock, mPackagesLock and
mUsersLock. While reads can use mUsersLock.
Testing revealed that the following methods in UMS often cause contention:
- exists
- getUserInfo
- getProfileParent
They all now use a short-term lock mUsersLock for reads.
Bug: 24979571
Change-Id: Ie3a22ea7cbb450c7969800fe2a4a2b2516165e5b
Adding performLongClick(x,y) broke compatibility for widgets that
overrode the no-arg performLongClick() and expected to receive a call.
This CL ensures that the no-arg method is called and the (x,y) data is
preserved for use in the default implementation.
Bug: 25411884
Change-Id: Ib0a3fb02d4c08ef64ce3a7165aa83bf0688aa50e
Bundles cascading menu information and stores it in a stack representing
the hierarchy of added menus.
Bug: 23970448
Change-Id: I1621d9eb30ff173767b6ebad2a1977127c42d0ad
I think what probably happened is that since we only report an app
going in to the "interaction" state as an interaction event to usage
stats, apps that sit around in that state forever will only see one
interaction at the start and never again. So usage stats could start
thinking they are idle.
Fix this by having the activity manager report an interaction event
for such long running applications at least once a day.
Also, because it is correct and for paranoia by protected us another
way, system uids should never go in to standby.
Change-Id: I8a3805bfca86cbe78560488a649ecd07427da99a
