An initial sorting step before applying modifiers to the ChooserTarget
scores provided by apps was backwards, causing subsequent target
scores to be heavily penalized. Targets are then heavily influenced by
the lowest score in the set relative to the targets from other apps.
Bug 25013559
Change-Id: I39d5d7c601712fc6a19e694d5846d2c8d17a214f
Adding a new carrier config key to specify the gap between the DTMF
tones sent out to the network. Setting it to 100ms by default.
This is based on a similar set of changes for IMS calls: ag/747865.
BUG: 19118840
Change-Id: Ifb64fe406509fe7c401ad1c4b4e906d6643e327b
With the original logic, if an app creates a system window, when the
user goes to home screen, the system window will be still there and
become unable to receive input events, because the system window will
be also changed to the stopped state with the app window, and the
current logic of ViewRootImpl forbid a stopped window receiving input
events.
This change prevents assigning the token of the app window to system
windows created by the app, so that when the app goes to the stopped
state, its system windows won't be affected (can still receive input
events).
This change is related to the following changes:
a5d29971f815ed2754a3c3672cd3f741725dedc3
Bug: 24967303
Bug: https://code.google.com/p/android/issues/detail?id=189710
Change-Id: I515e47bafcf39a2b1bdf92f11f623bef8fb6263c
Previously, paragraphs with ImageSpans in their middle would continue to
carry the height of the image into the line height of next lines. This was
a regression from L.
The bug was due to StaticLayout's out() method almost always
modifying the value of its parameter "fm", although that was only
intended when there were LineHeightSpans in the text. The method
generate() was assuming that it can restore fmTop etc to metrics of
the current span by setting them from "fm" after out() was run, while
"fm" was modified by out() and its original values was lost!
The fix makes sure to set chooseHt back to null if there were no
LineHeightSpans, so out() would not modify "fm" unless necessary.
AOSP bug: https://code.google.com/p/android/issues/detail?id=188042
Bug: 24548073
Change-Id: I0d00af384c35a9d863377972318da9db7668118f
BUG: 24385082
BUG: 23144425
BUG: 18117279
Run jobs with connectivity constraints as soon as the developer-allotted
delay has expired, rather than waiting for the override deadline. This
is more in tune with what developers expect, although it reduces the
amount of batching the scheduler can theoretically do.
This will also have the side effect of fixing several failing cts
tests that started breaking b/c the signal to 'run connectivity
jobs early' was removed in M and nothing was put in to replace it.
Change-Id: I7e63c2b62f2882ee906f748445bbf10c32e19c5f
(cherry picked from commit aa9843198dec910a581bdc509d3937a9ea6ceca9)
The SystemUI visibility listener in DecorView
gets called between the measure and layout passes
and is therefore not allowed to change layout parameters.
This change makes sure that changes to the color view
layout parameters are applied eagerly when the insets
change instead of waiting for the views to become visible.
Bug: 24614374
Change-Id: If9df18f582163d0869c28a852c36697b1ce50621
Unlike the implementation in LMR1, this is a countdown condition
(a countdown until the time of what was the next alarm when the
rule was created). The rule will not change if alarms change.
Also, alarms up to 7 days in the future will be considered.
Bug: 21648799
Change-Id: Id7fa9dbdbad1539e4da19b1d0e0c4395bb13e6cb
(cherry picked from commit 0842fe87b27b9e4a7aecfec25b93dba2d39f398a)
Ensure the clip rect taken from transformations is cleared
when there is no transformation. Normally the failure to
clear the clip would not cause a problem, as the final clip
would be equal to the window size. However, in the event that
the window scale goes on to change (WindowState::m(H/V)Scale that is)
the clip will now be specified at the inappropriate scale (notice the
way the clip must be divided by H/VScale as SurfaceFlinger will apply
the surface transform to the clip).
Bug:24298694
Change-Id: I4548e8ecea8d66d4942e99823653a7b05f87cea0
(cherry picked from commit 2f0fe62c5426533ccdf9ec7ef28027c367286979)
Update storage related docs on Context to be consistent, and to call
out relevant Environment methods. Start calling it "shared" storage,
and only mention external for historical reasons. Mention that there
isn't much benefit to using emulated storage over private data
directories to help guide developers to safer locations.
Point out which paths can change over time, so developers know to
only persist relative paths.
Update Environment docs to reflect how they behave for the new
class of adopted storage devices.
Bug: 24251945
Change-Id: Ie5ab337649b4740dfd7594997bbb19c4969cfd2f
