am: c1699a9
* commit 'c1699a9f4cf679ebc87e5b5bc99dd07446950be7':
Populate RangeInfo correctly when acquiring from pool
Change-Id: I0227f6b9a842fa1e63827cda51e0cb5a435e278e
am: 9e31b3f
* commit '9e31b3fd817aed28d9afd712fa49ec9d6fc11329':
More work on issue #26390151: Add new JobScheduler API...
Change-Id: I7c227898d175c15219192fc42c5e4eb5121e9517
am: 1dfe35b
* commit '1dfe35b8a797f921d095beeaf1018f7a987e8343':
Skip to end for 0-duration animation
Change-Id: I22f0cbf98b69b24b07de001bfebb86ad06c2170b
USER_PRESENT is sent via the background queue. A delay
there can cause us not to recognize that the user has
unlocked and prompt for the credential again, when trust
or fingerprint would be sufficient.
Also removes an obsolete reference to USER_PRESENT from
TrustManagerService.
Change-Id: Ie8d1a180170df5f0c8f9e71660504fd71eeacd99
Fixes: 27830458
am: 651e09f
* commit '651e09fdc1b4c26dc7661e1ab127276656ece041':
Make ResolverActivity respect selector intent when making filters
Change-Id: I4bf1b16e6afb07c7c9bd0172539efa32dc14724e
Repeating a 0-duration animation makes no sense. In the case of
battery saver mode, all animators are set to 0 duration, and
repeating the 0 duration animations not only waste battery power
but also potentially produce flickers on screen. In this CL,
0-duration animations are skipped to the end, regardless their
repeat count.
Bug: 25451472
Change-Id: I20f9dc2f0ff9c027782a8363ff4cf4a4d390736c
am: 11aade9
* commit '11aade9f6e82844d494c43a5ad0bbae87cbf9601':
Camera: update expectation of post RAW sensitivity control
Change-Id: I87aada74f3c4780a037872af737b61b1e2c6bb74
For pre-N, we have inconsistent behavior between ValueAnimator and
AnimatorSet in the case of calling end() when already ended:
ValueAnimator would start() and immediately end, whereas AnimatorSet
would be no-op. We made a decision to be consistent within Animation
Framework from N forward, which means that AnimatorSet will have the
new behavior of starting and immediately ending just like
ValueAnimator. This new behavior will be guarded by an API check.
Bug: 25601129
Change-Id: I2d952a93d8521c547ec8cde173c80d1d8ead0639
am: 3c58709
* commit '3c5870912b6dc20e13c3af5e078a600b88904e99':
Make WifiScanner state not static and use ConnectivityThread
Change-Id: Ia2c6bb955461884e88d13af885e0011fcafec7b5
...for monitoring content providers
We now have some delays before reporting URI changes, to allow
them to batch together.
Also clean up debug output, and fix some issues with how we
were managing the content observer state.
And while I am here, fix the device idle and app idle controllers
to no longer maintain their own list of jobs, but just directly
iterate over the JobStore.
Change-Id: If3fdff23c00c2f1b99901a9be096d851562d3439
We now keep track of how long each app has been running a job
for, in 30 minute batches. If it is running jobs frequently,
we will bump down the priority its jobs run at to allow other
jobs to run before it.
Currently we count both pending and active as the job running,
which means that an app that has jobs waiting in the pending
queue will count against its abuse prevention. This could
allow starvation -- if we bump down the priority of an app's
jobs and the system is so busy continually that they sit
in the pending queue a lot -- it could never recover. But I
think that is okay... if we are really in a state where we
are continually running as many jobs as possible, we probably
have other larger issues.
Change-Id: I838aa4b5840e91df49a1e17b53188d6e4a66a6d1
am: a63d2db
* commit 'a63d2db09978387b2bfdd849034dc73d43647ded':
Fall back to setting the level of the entire progress drawable
Change-Id: I4f1c109fc925e9d576fca9d7db4de6a43c3eedee
am: 3fb1c81
* commit '3fb1c81394f98b025b488774916b7580f9e31dab':
Update surface insets on window elevation changes.
Fixed bug with cropping out drop shadow for pinned stack.
Change-Id: If788ed4af5292b76576c7abd728633f20cc6eb93
When the ResolverActivity makes a filter after an intent is chosen,
either for remembering last used or an "always use" choice for the
user it doesn't consider the selector in the intent if present.
This means that when a resolver activity is launched for an intent
with a selector, the selector is used for resolving preferred
activities, and for populating the list, but when the same intent
is sent again it doesn't match the filter created by the previous
ResolverActivity.
This in turn means that the user will get another ResolverActivity
even if "Always Use" was chosen the last time.
Bug: 28129216
Change-Id: I29be7010e7c890caf9789673b3c3f821ba362761
am: 52546e4
* commit '52546e46353f455d6a5bd070da6095868d7fc8bd':
Crash early when requesting a keyboard shortcut helper...
Change-Id: Ia1be80e54af4c04af0c33ef2d03f7fc4e8dfee84
am: 1271cef
* commit '1271cef419bdb7577f64b1dfa05d5678df706ef5':
API polish in DPM for organization color and name methods
Change-Id: I6073662932fc256fc4860a19c4d45b1f9fcf9ced
