Previously, Fade transitions did not work correctly on hirearchies; they
only handled individual views. in particular, they would side-effect all
fading views by removing them from their parent to fade them out in the
overlay of the scene root. This worked for the fade-out transition itself,
but caused problems when those same hierarchies were added back in and
another Fade was run on the hierarchy, because now all of the views inside
that parent node had been removed, so they didn't fade in at all.
The fix was to add logic in Visibility to detect when a disappearing
view was inside a hierarchy that was also disappearing, and to skip the
fade on the views inside that hierarchy, leaving only the top-most
disappearing view to be faded out, thus preserving the hierarchy under
that faded-out group.
Along the way, there were various cleanups, fixes, and refactorings in the
transition code, and slight API modifications.
Issue #9406371 Transitions: Removing view hierarchy not working correctly
Issue #9470255 Transitions: Separate different transitions by Scene Root
Change-Id: I42e80dac6097fee740f651dcc0535f2c57c11ebb
Since telepony.registry is a real system service notifyNow
parameter doesn't need to be conditional as telephony.registery
will never go away.
This is different from most of the other TelephonyManager
methods which are used to invoke methods on the phone service
which implements ITelephony and is implemented by
PhoneInterfaceManager in the phone application. Since the
phone app is not a system service it can and does go away when
it crashes.
Bug: 9393863
Change-Id: I1a8afc12b0e139e72f05820e49f3d996aec2b52a
* commit '40f20235380b245ec29b09e10792047b9b01d6f1':
Revert "wifi: Get full scan results"
add ViewGroup's layoutMode attribute to public resources bug: 9359960
This change adds simple APIs that enable an Android application
to generate a PDF document by drawing content on a canvas.
Change-Id: Ibac93d7c37b01a376ce7c48238657d8c7698d588
Since telepony.registry is a real system service notifyNow
parameter doesn't need to be conditional as telephony.registery
will never go away.
This is different from most of the other TelephonyManager
methods which are used to invoke methods on the phone service
which implements ITelephony and is implemented by
PhoneInterfaceManager in the phone application. Since the
phone app is not a system service it can and does go away when
it crashes.
Bug: 9393863
Change-Id: I1a8afc12b0e139e72f05820e49f3d996aec2b52a
Allow the appropriate WebView to be preloaded in the zygote by
constructing the currently selected WebViewFactoryProvider when the
WebViewFactory is preloaded. At runtime, if the preloaded provider is
still the current selection, the preloaded instance is used, otherwise
the provider is loaded at that time.
This change also removes "graceful" fallback from the experimental
WebView to the classic implementation: if the option to use the
experimental WebView is selected and it could not be loaded
successfully at the time a WebView is created, an exception will be
thrown, rather than allowing execution to continue with the classic
implementation, as the fallback may mislead developers who do not
examine logcat output in detail.
Change-Id: I0cd01c784d7048abeac55ab5863ca16b8fd9ecf2
