This reverts commit 8390b2ac85765e768d4b685077a96e6395d208b4.
The build break should now be fixed by
cbb1ba7f493116882b79578ec68646366f29cde4
Change-Id: I9bf21cc6dbdb5d515a665384dc6dfa464c3e6e2e
This adds the ability to promote private fields to public ones to
enable layoutlib to access them. This was first added in change
b556decf75b2b084e1aed54ac7fa23a141eedb7f, but reverted in
847b0d3ad22a47e0bca3d8bc8168fea7a0ba2f80. This is essentially a revert
of the change again, but without the SimpleMonthView related stuff.
Also, promote the Choreographer's field as is needed to support
animations.
Change-Id: Iee45a465c7a1cadd362c1841385941e6232e4900
For some markets we have to allow the user to review permissions
for legacy apps at runtime despite them not supporting the new
permission model. This is achieved by showing a review UI before
launching any app component. If an update is installed the user
should see a permission review UI for the newly requested
permissions.
To allow distinguishing which permissions need a review we set
a special flag in the permission flags that a review is required.
This flag is set if a runtime permission is granted to a legacy
app and the system does not launch any app components until this
flag is cleared. Since install permissions are shared across all
users the dangerous permissions for legacy apps in review mode
are represented as always granted runtime permissions since the
reivew requirement is on a per user basis.
Whether the build supports permission review for legacy apps is
determined by a build constant allowing us to compile away the
unnecessary code for markets that do not require a permissions
review.
If an app launches an activity in another app that has some
permissions needing review, we launch the permissions review
UI and pass it a pending intent to launch the activity after
the review is completed.
If an app sends a broadcast to another app that has some permissions
needing review, we do not deliver the broadcast and if the sending
app is in the foreground plus the broadcast is explicit (has a
component) we launch the review UI giving it a pending intent to
send the broadcast after the review is completed.
If an app starts a service in another app that has some permissions
needing review, we do not start the service and if the calling app
is in the foreground we launch the review UI and pass it a pending
intent to start the service after the review is completed.
If an app binds to a service in another app that has some permissions
needing review, we schedule the binding but do not spin the target
service's process and we launch the review UI and pass it a callback
to invoke after the review is completed which spins the service
process and completes the binding.
If an app requests a content provider in another app that has some
permissions needing review we do not return the provider and if
the calling app is in the foreground we show the review UI.
Change-Id: I550f5ff6cadc46a98a1d1a7b8415eca551203acf
Added a falsing check with FalsingManager in the case when quick
settings are fully expanded without flinging.
Change-Id: I2af07b5732f98bd45471ee33c51273a63b42b87e
- Use expanded view instead of HUN when possible
- Remember partial replies
- Back properly closes IME without closing shade
- Fix broken reorder animation
Bug: 22452379
Change-Id: Idb6ca8aed27cfb1f3d9b46f59e148b1b3b112fa7
Without this touch events on the input method will trigger focus change
if there is a window underneath the input. When focus changes, the input
method will go away too.
Bug: 25930832
Change-Id: I532cb9e78f6fe37b1ddfada75594fc695898a090
Remove code duplication in SelectionStartHandleView and
SelectionEndHandleView by introducing SelectionHandleView.
Change-Id: I4486019714b13d184a72cf7ee60c346c4d8b5f5a
Now that the activity manager keeps track of per-uid process states,
we can push that already rolled-up data into battery stats to directly
track the times in those states.
The problem with the reporting was actually that we weren't dealing
correctly with negative process states, which is now fixed. (It was
interpreting them as FOREGROUND rather than not running.)
Also split out a number of new states -- TOP, FOREGROUND_SERVICE,
TOP_SLEEPING -- from FOREGROUND. This should allow us to get a much
better idea of how much an app has been actively in use: TOP is when
it is directly visible to the user or in use by such, FOREGROUND_SERVICE
is when it is running in the background in a way the user is aware of.
Also when reporting these numbers, they are no longer added together as
reported but kept as separate times.
Change-Id: I6d307503a4b4ad5c0d5d49305ef63f8eb858e2c9
Also, rename "ManagerRootActivity" to "DownloadsActivity"
since because...well, it is almost always Downloads
and is specialized for this case.
Bug: 25809806
Change-Id: I496d34393d269d2120c8e214413cb87df8bf171d
We should ignore orientation change requests only when a resizeable
activity is not in a full screen mode.
Bug: 25935368
Change-Id: I53bada8bbf0b429b1d48707f65da488e0edeb799
The majority of the test failures were around the method assertInstall()
failing a check for a symlink between the data directory in /data/data/
to the application directory in /mnt/asec/. There are a handful of other
failures that will be dealt with separately; those have all been suppressed
from running.
Also took the opportunity of adjusting some of the tests to ensure the
device is properly cleaned up. Packages remained installed after a failure.
Bug: 18048725
Change-Id: Id8f6ac53cfe17de43b5d527993d57812b1a63bef
The status has always been there in error cases, it is now also visible
in non-error cases.
If the progress is not set, no progress bar is shown.
Bug: 24135025
Change-Id: Iea23f45d236365433c6f6739597833d236ed6d19
