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
We cannot pull the "retain loader" state from the Activity; an Activity may
not always be hosting a Fragment. Instead, save the "retain loader" state
inside the individual fragments.
Bug: 23838271
Change-Id: I8358183a7689b5a571ea7be03d769186b2812600
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
Use the existing PointerEventListener infrastructure to listen for
gestures that look like flings and hint to the power system when they
happen. Since we don't actually have a bound for the fling like a
regular application would, limit them to five seconds and refresh
every time a new fling is seen until the five second time period is
up.
bug 24059298
Change-Id: I5757a1e88f2ab2ef08cccefa8221d809ae71bb6f
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)
Previously, size of of oat directory was not counted by the getsize command,
because base APK location was passed as apkpath argument.
Bug: 23896047
Change-Id: Ic7b6b725785ff2e2a0cf3887ba68c162b23b1212
Views are not synchronized with adapter state until a layout pass
occurs, which may cause an OOBE if a list item is removed and an
accessibility node is obtained before the next layout pass.
This CL caches the item's enabled state on the bound view's layout
params, which allows us to avoid relying on the adapter to populate
accessibility nodes. It also aborts actions if the target position
is no longer valid.
Updates the documentation on AdapterView to reflect that the result
of getPositionForView() may not be synchronized with the adapter.
Bug: 23943664
Change-Id: I90ca946bead1d87a179eab1c2f482a54bcce9c38
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
So the lockout reset exactly fires after 30 seconds, independent
of whether the device was in deep sleep.
Bug: 23668918
Change-Id: Idea1a877c395897c1fd075cf98edf41c8b1f4082
For each runtime permission we have an app op to toggle the
permission for legacy apps as they cannot handle permission
revocations. We were lacking an app op for get_accounts
which prevented the user from controlling access to accounts
regardelss that they change the state of the permission
toggle in the UI. Even worse the permission UI is written
with the assumption that every runtime permission has an
app op and as a result revoking the contacts group (if the
app requests the get_accounts permission) is reset back to
allowed in the UI.
bug:23854618
Change-Id: I9e3f9bfeb320bed561d718db99ee285915d5701b
This is necessary because currently the wifi code just returns
whatever hardware-specific integer it gets back from the HAL,
which is bad because that will be interpreted by the caller as
one of the error codes defined in this class.
In parallel we'll also modify the wifi code to return this new
error code if the hardware returns an error.
Bug: 21405946
Change-Id: Ic9fa1193ced69a4e7ff543e397221c89b10a5a13
Adds the colorTransform field, which defines a vendor-specific color
transform (e.g., wide gamut, sRGB, etc.) to the PhysicalDisplayInfo
class, and populates it from the corresponding field from
ISurfaceComposer.
Bug: 20853317
Change-Id: Ic59ca5142bdaa73c42d9c044d7aae345255f1dad