An old optimization in ViewRoot prevents updating a window surface
while a window animation is playing. SystemUI and other small system
components that blend these animations disable this for a smoother
experience. Disable it in ResolverActivity as well.
Bug 24989381
Change-Id: Iac7d1c7b1101ed8d2bc4c3557277a773ce871beb
An initial sorting step before applying modifiers to the ChooserTarget
scores provided by apps was backwards, causing subsequent target
scores to be heavily penalized. Targets are then heavily influenced by
the lowest score in the set relative to the targets from other apps.
Bug 25013559
Change-Id: I39d5d7c601712fc6a19e694d5846d2c8d17a214f
The SystemUI visibility listener in DecorView
gets called between the measure and layout passes
and is therefore not allowed to change layout parameters.
This change makes sure that changes to the color view
layout parameters are applied eagerly when the insets
change instead of waiting for the views to become visible.
Bug: 24614374
Change-Id: If9df18f582163d0869c28a852c36697b1ce50621
* Wait to start animations until all state has been initialized, as
the process of starting an Animator will set initial values,
triggering other events relying on the configured state.
* Correctly track underlying item indexes for columns.
* Do not over-extend the ResolverDrawerLayout when multiple rows
animate in.
Bug 24926885
Bug 24928706
Change-Id: I4772e1a0ba79b17b5dc19c778f3ef0cb5200c533
Dejank the process of bringing in new ChooserTargets from queried
services. Animate the service target rows in upward so that if the
user's finger is already headed for a visible choice we don't inject
something wrong right under them at the last second. Keep things sane
if the user is dragging the UI while we're bringing in new items.
To animate this, since we can't use RecyclerView from the framework we
treat the height of rows as a conceptual data set change for
ListView. To get away with doing this per-frame we pre-measure the
item height (which remains constant) instead of doing more expensive
wrap_content calculations. ResolverDrawerLayout is now aware of how to
account for a cheat-measured ListView to compensate.
Bug 24038066
Change-Id: I01414a5746815255ff948a6d0887bb5ad0897285
When a developer wraps an intent with Intent.createChooser(), they're
indicating that the user should always be prompted, instead of using
any "always use" defaults. A recent CL changed the chooser behavior
to ensure that UI is always shown in the case where there is only one
match.
However, this caused us to start prompting for the GET_CONTENT intent,
for which there is only ever one DocumentsUI system app. Since that
app delivers on the createChooser() contract described above, we're
okay automatically launching it.
Bug: 24464358
Change-Id: I0279d3343479c134a35f41ddf3cb4204d0ae6a90
In the longterm, we should move these synchronous writes
off the main thread, but in the short term, avoiding an unnecessary
write is good enough for the main case.
Bug: 24471234
Change-Id: Id996ff29e61410cd077760a06d7868a413ae88da
If the power profile was not set yet, the default sizes of
cpu freq arrays could have been too small.
Bug:24244089
Change-Id: Ic17a1e8f2058c51fbdda14db35b7b62f4880be00
Propagate the boot status explicitly to installd so that we do not
have to rely on dev.bootcomplete, which isn't meaningfully set
when the device needs the decryption screen on boot.
Bug: 23898216
Change-Id: I9b34298caf70b1e5d40970cc0d04c469016a80a7
Always connected devices don't have power_profiles,
so handle the case where the default cpu speed count of
1 is used on a device with more cpu speeds.
Bug:23776983
Change-Id: Ifdddad2f28eea5b730833622a6b6043b3086efd2
When two or more activities with the same user-visible label are
shown, we have traditionally shown the app name or package name if the
app names also match. This was to help the user tell the difference
between multiple apps publishing similar activities and avoid
unintentionally starting the wrong one. However, in the case of
explicit choosers (e.g. ACTION_SEND sharing) a few common collisions
occur in practice and falling all the way back to package name isn't
very helpful.
Instead, we now assume that the app icon, which the user has seen
before at install time, is unique enough on its own to disambiguate
these cases and avoid user confusion. We no longer show the app name
or package name as secondary text in the chooser.
In cases where an activity has a different icon from its containing
app, we now badge the activity icon with the app icon so that the user
knows which app a potentially ambiguous choice belongs to.
Bug 24113937
Change-Id: Ie54fbf77bfcc86e50768f93be2be0e53cf2ce7b5
Fix cases where we could try to unbind from a ChooserTargetService
that is not connected. This could happen if we still had stale replies
coming back after the activity was destroyed.
Always offer users an explicit choice in ChooserActivity, don't
auto-start a single option.
Make sure we don't allow a wedged ChooserTargetService to hold a hard
reference to the ChooserActivity via its internal result callback.
Bug 23152483
Change-Id: I7c8b1fc9559dcd477702ef582011b088b07d646b
(cherry picked from commit 9761ab2a645a4643bd20619c7c148ef07e0dd39d)
Generalize cpu clusters so we can measure frequency
and power usage across heterogeneous cpu clusters.
This also brings back reading of cpu-times for power calculation.
Bug:22773176
Change-Id: I9c794ae9756c782c0e971c7f5fcebbe70374b269
Gatekeeper retains lockouts after reboot, but framework
doesn't. This causes odd behavior on a reboot after a lockout
as gatekeeper refuses to check the password and the framework
thinks it's an invalid attempt. Reset the lockout deadline
if we notice the clock reset in the framework.
Bug: 23681267
Change-Id: I3127ccd8f205494af5a8ed2b44d4370c37cc2f8f
The GestureLaunchService now informs systemUI that a launch
has been requested and the systemUI, depending on its state
will launch the Camera in the correct mode, including
animations.
Bug: 22957192
Bug: 22958025
Change-Id: I815437c8bd33638245ac61a750f64af74fe3e1e3
This allows us to stop using approximate methods of attributing
cpu frequency time across apps and to use a more precise kernel
method that is aware of the time spent by a process on a given core
at a given frequency.
Bug:22773176
Change-Id: I3c34365fa8c73204f178a5610423901b13453d06
