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 9761ab2a64)
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
