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)
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
Support for loading the pre-compiled binary format for hyphenation
patterns.
Bug: 21562869
Bug: 21826930
Bug: 24570591
Change-Id: Iaeaa9c9ac9dac236af6b0d7894c2e2396bc8447d
(cherry picked from commit 091dba2de1)
Previously, a native pointer was returned. After this change, callers
should call getNativePtr() if they want to get the native pointer instead.
Bug: 21492297
Bug: 24570591
Change-Id: I745bd88e6e8c86078fffb07f90f8d8f24215410c
(cherry picked from commit e7eac6f540)
This makes it so that the socket cannot receive datagrams from
anybody except the DHCP server. This does not improve security,
because we never read from the UDP socket anyway, but it does
make ListeningPortsTest pass.
Bug: 23906864
Bug: 23933386
Change-Id: Ib090273a417f7eb2ac1ee3309260249b72fb8345
When an app doesn't define installLocation, the default behavior
should be to treat it as internal only. This matches all the
published developer documentation.
Without this, apps could be unwittingly be moved to adopted storage
devices.
Bug: 24771264
Change-Id: Iaf38ab45329aad6cb5d6deac81fb1781f680189b
This change grants Android Wear system components default
permission.
I have also added a new Intent category to help identify
the main Home handler on Wear.
BUG: 23419042
Change-Id: Ie669a9908bd3b03498f75c5ca22c0fddf52a5203
In the case of scaled SurfaceViews with a fixed size.
It is possible for the surface layout size to change
without a change to the surface size or position. In this
case we need to inform the window manager so it can update
frames and scaling. This has presented in Camera and required
workarounds such as changing the fixed surface size to trigger
an update (leading to visual artifacts).
Bug:23974105
Change-Id: I195aa0832907c32874b294101b56e198e853dce5
(cherry picked from commit a8fe43f09c)
