Introduces a new "blocked" state for each package. This is used to temporarily
disable an app via Settings->Restrictions.
PIN creation and challenge activities for use by Settings and other apps. PIN
is stored by the User Manager and it manages the interval for retry attempts
across reboots.
Change-Id: I4915329d1f72399bbcaf93a9ca9c0d2e69d098dd
Bug #9404946
Run another EGL context check after invoking user code to ensure
we have a valid context/surface pair before drawing the display list.
Change-Id: Iefb0ced7900ce0c54eb81b62d24ec00700bdce47
One problem this turned up is, because FastPrintWriter does
its own buffering, a lot of code that used to use PrintWriter
would fail -- if it pointed to a StringWriter, there was no
buffering, so it could just immediately get the result. Now
you need to first flush the FastPrintWriter.
Also added some new constructors to specify the size of buffer
that FastPrintWriter should use.
Change-Id: If48cd28d7be0b6b3278bbb69a8357e6ce88cf54a
* Working streaming preview requests only
* Almost everything else returns empty objects that don't do anything
Bug: 9213377
Change-Id: I183dd47ddd737ec2c3c374e5c3461542a97f09b0
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
