First step in adding activity specific information to displays.
Replace CompatibilityInfoHolder with DisplayAdjustmentsHolder that
holds an activity token in addition to the CompatibilityInfo.
Change-Id: Ie113cd8dd9c62e0b5311204e039a4829096bea68
Invalidating a view property (alpha, rotation, etc.) causes an
invalidation process that does not work correctly when the view is
in a ViewOverlay. Specifically, if the view is not directly in the
overlay, but is instead inside a hierarchy which is within the overlay,
then the invalidation process stops at the ViewOverlay itself, because
the ViewOverlay has no "parent" view.
The fix is to override the invalidateChildInParentFast() method, just
like we override invalidateChildInParent(), to forward the invalidation
to the host view.
Issue #9389230 Animations not running for nested views under ViewGroupOverlay
Change-Id: I03fcef10ed1c8a91cb26d5d9d6945634b0b695b5
Bug #9404946
The Calendar app destroys one of its popup windows during a draw
traversal. Without this patch, we end up with no current context
nor surface after we're done gathering display lists. This means
that all of our EGL/GL calls will either fail or have undefined
behaviors. This could explain the PBO crash we are seeing with
the monkeys. Without a proper GL context, the driver returns NULL
when we map the PBO in CPU memory.
Change-Id: I210cf724be73da909a7621f807298a9f4a58e61d
Transitions used to be three phase:
- captureValues(): get all relevant property values in the
affected view targets
- setup(): set appropriate start values for affected views
prior to any transitions being played
- play(): create/play Animators for affected views
Now the second and third phases have been collapsed (and named
"play()"). This single step sets initial values for target views
and creates any Animators that should be played during the transition.
The transition mechanism stores these Animators and then starts
them at the appropriate time in the overall transition.
Issue #9507585 Transitions: Simplify Transition.play() design
Change-Id: I3fc67599b38fe49eee885dc5d32444db90b7703b
We now keep track of the time actually process run independently
of the time packages run in process, so we can give an accurate
summary of how long each physical process runs.
New command line options can be supplied to restrict printing to
a specific package, dump in a new csv format, control what is
printed in the csv format, and print a checkin report.
Add toString methods to ArrayMap and ArraySet.
Change-Id: I47b8f68472592ecc0088c5286d3564aa615f4e0a
If a service component is defined in a new secure setting,
SystemUI will attempt to use that service as the status bar
provider.
Falls back to the existing in-process implementation configured
in the product config if the setting is missing or invalid.
Nothing changes yet from a permission point of view. Alternative
system bar implementations still require the status bar permission.
Also nothing changes from an api point of view. Alternative
system bar implementations use the existing IStatusBar interface.
This simply enables testing alternative system bar implementations
installed from other trusted, platform-signed packages.
Known caveat: the setting is stored per user, multi-user changes
will be handled in a future CL.
Change-Id: I0413df185f7e75f77ad2ae1bc3689306d5e6e0fb
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
This change adds simple APIs that enable an Android application
to generate a PDF document by drawing content on a canvas.
Change-Id: Ibac93d7c37b01a376ce7c48238657d8c7698d588
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
- related to the previous change for saving the scroll position
- also related to bug #9463581 NPE observed while launching News&Weather app from all apps tray
Change-Id: I9f2f8a246e793eefa1cf510e15a56a1058fb9c18
This change enables applications to create a private virtual
display that renders its content to a surface of its own creation.
The display is private in the sense that only the application
that owns the display is allowed to place windows upon it.
Mirroring and blanking is also disabled for these displays.
Bug: 9192512
Change-Id: I852ea07f0c7df1d244e354e3daca3a6960285ca0
We fire view subtree mutation events every X amount of time.
It was possible that the runnable that fires an event to be
scheduled more than once while this should not happen. As
a result there was a crash since we did not expect to have
a second run and nullified a reference.
bug:9422804
Change-Id: I914e163b026cd217e1536ab0ed3a6b11113c2c73
