* 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 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
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
The platform grants runtime permissions by default to apps on the
system image that provide core device use cases which a user expects
to work out-of-the-box. We are now adding a test to ensure that
OEMs cannot pregrant premissions on non approved components.
bug:23043018
Change-Id: Id76717cce0ee59678956bd0be347d3c045fe4c51
When long pressing on an empty Text field with the system language set
to RTL, the "paste" popup was not showing up.
The Floating Toolbar requires a content rect to determine where the
text is and place itself close to it. In the case of an empty field,
we create a "fake" content rect by taking the placement of the cursor
+1 pixel to the right. In RTL languages, this +1 causes the content
rect to be considered off the bounds of the view, as the cursor is
aligned to the right, and hence the Floating Toolbar is hidden.
After making the rect a 0 width rect, we ran into the issue that
it was considered out of bounds due to the calculation ignoring rects
that simply touch the edge of the view's bounds.
BUG: 22540083
Change-Id: I29c79b701f586970b2611178233eff082b802ec1
Removes overlap from the color views which resulted in subotimal looks
when both color views were translucent and the nav bar was on the right
edge.
Also fixes a bug introduced in I2df7092a91eceeb815367ef917dd7289f4f2b27e
where the navigation-bar-on-right-side case got forgotten and caused
flickering in landscape when IMMERSIVE_STICKY was set but the navigation bar
was visible.
Bug: 22876533
Change-Id: I449a82eb3dc3f7b5051f26b37b362a196b4ff63a
