This patch adds an event class derived from IpConnectivityEvent that
records parsing errors of DHCP response packets.
Change-Id: I19516cf05e3419c4262e3236899e52987e5f2264
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
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
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
...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
The view should be showing a combined list of "downloaded"
+ "visible in launcher" apps. However, if FBE and work callenge are
enabled, after a reboot the direct boot unaware apps are filtered.
Reason is that PackageUserState#isMatch assumes at least one of the flags
are specified and expects system to derive the aware/unaware flags
according to the user's lock state if neither of them is specified.
Bug: 28004355
Change-Id: Ia05edb0530023597fd219eb5e59cd71752efd279
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
Lens shading correction should be full correction that
corrects both color shading and vignetting.
Bug: 18175853
Change-Id: Ia552345b2bd78b1b2eed2472096ebae80680d70b
The goal of this CL is to enable
InputMethodSubtype#getLocaleDisplayName() to return more natural locale
display name in terms of capitalization rules.
The key idea here is to use LocaleDisplayNames#localeDisplayName() with
an appropriate DisplayContext.CAPITALIZATION_FOR_* parameter rather than
relying on Locale#getDisplayName().
Bug: 22845728
Change-Id: If105082ce703db7a86738455db7e9fb37f3c6fe8
