Two separate implementation paths, one for Material look / layout, and
one for legacy / pre-Material one.
Bug: 28037149
Change-Id: Id1946802c0a93218d9eb0b73c81ad76dc027763c
am: 677b2c6
* commit '677b2c60aa5bd41b856762d223161220476844bb':
Skip to end for 0-duration animation
Change-Id: Ibc359887f4d96a84742e4369bb0059c1ece1afc1
am: 1dfe35b
* commit '1dfe35b8a797f921d095beeaf1018f7a987e8343':
Skip to end for 0-duration animation
Change-Id: I22f0cbf98b69b24b07de001bfebb86ad06c2170b
am: 7d7a075
* commit '7d7a075ec9257f8a93bd971df5d58a3b4f41c7f6':
Make ResolverActivity respect selector intent when making filters
Change-Id: I8e5dc2ace5949e58263bfb19dfae8f6c6a6d87cd
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: b2bbd21
* commit 'b2bbd2114d33c4804f2d53bfe0c5e17464d1c0e7':
Camera: update expectation of post RAW sensitivity control
Change-Id: I1b1030148e19ac308647b043bc2a5d7c56c86f53
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: 53560db
* commit '53560db137aeab0a25c6a81c61da4426a676ce37':
Make WifiScanner state not static and use ConnectivityThread
Change-Id: If2d49d771b63e0fd1bd96bdd976048da9435648a
am: 3c58709
* commit '3c5870912b6dc20e13c3af5e078a600b88904e99':
Make WifiScanner state not static and use ConnectivityThread
Change-Id: Ia2c6bb955461884e88d13af885e0011fcafec7b5
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: 147baca
* commit '147baca4aa2f595ee1c2e8bb53b1aed43d3d7ddd':
Fall back to setting the level of the entire progress drawable
Change-Id: If851161f3e26de46667006f2eb1522fd7c66fd37
am: a63d2db
* commit 'a63d2db09978387b2bfdd849034dc73d43647ded':
Fall back to setting the level of the entire progress drawable
Change-Id: I4f1c109fc925e9d576fca9d7db4de6a43c3eedee
am: 361124e
* commit '361124ef082a79ddae6ece153aebecac09f0fbd7':
Update surface insets on window elevation changes.
Fixed bug with cropping out drop shadow for pinned stack.
Change-Id: Iad5f58cc43ed5b24d23dcf878c941820b92a7ac8
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: f58d81e
* commit 'f58d81e640ac2d471259838af986b410f5cd2938':
Crash early when requesting a keyboard shortcut helper...
Change-Id: I2ef9f779a6295d90e9654738317ea39cd4f10870
