ActivityInfo was missing initialization for the
documentLaunchMode flag in the copy-constructor
and the Parcel constructor. The copy-constructor
is used in multi-user/profile mode to create a
seperate instance of the ActivityInfo per uid
and this was manifesting in the linked bug.
Bug: 21590916
Change-Id: I6f71d94ec32ec6326d23c9b62e9d8d319e2fa25e
(cherry picked from commit 3e2e011785)
In rare cases, we might have created a network policy before an IMSI
was available. Because this policy is persisted, and we incorrectly
think that it always applies, we end up annoying the user when data
usage goes over the 2GB default warning threshold.
This patch fixes the network matching logic to ignore these empty
network policies when present.
Bug: 24972775
Change-Id: Id26499b6716121dddf0f2c05b848b0bed5995e72
Bug 24993183
The bounds for the drawable weren't being set, so the
drawable was never drawn to the correct size.
Change-Id: I992951f28ee6fac2ce8752d2dc0e23f51d3cf584
(cherry picked from commit f2a3703696)
Remove the partial fix [it did not work for child fragment managers]
and replace with a more general fix that works with all fragments.
Bug: 23838271
Change-Id: I88b465f6a06a6ad627b9651b9e2eea41fae08972
When we restore a fragment [i.e. on configuration change], we need to
make sure the host is set prior to calling into lifecycle methods
such as onInflate(). These use data contained within the host.
Bug: 22512520
Change-Id: I709365a858cfc555ec5b7fc200629fa8d022faad
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
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 0842fe87b2)
